the_duke

Codex CLI was open source from the start.

The reason they open sourced this is because grok-build uploaded entire directories.

No clue, I also vouched.

I was investigating the design a little. Two big questions:

A) You notably don't write a recovery log (WAL/journal) for things not yet flushed, so data can be lost. Do you have plans to add this? I think it would be pretty crucial.

B) the system is single writer. Do you have plans for adding horizontal scalability so a writer can be dynamically selected and routed to, transparent to the client? (Or with client cooperation, but without forcing sharding on the user)

Making something 50-2000x faster is pointless?

Besides that, Rust code is actually much easier to maintain , thanks to type system guarantees.

Does this support using S3 as the backing store?

That would be very powerful for various use cases.

In my opinion cursor actually has one of the best harnesses again at the moment.

Of course they will.

Right now they want to prevent the US labs from gaining any sort of self-reinforcing oligopoly on the space, and to let the ecosystem in China flourish.

That will all die sooner or later.

This is often due to (privacy) extensions disabling canvas/webgl.

In codex CLI /status works just fine during a turn.

Other things don't though.

I exclusively use thinking mode, which is slower but much more likely to double-check things with web search etc.

Config based hooks seem to miss the mark though?

The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something?

So not very useful at all...

I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.

That's in part because many EU countries would like to ship the Syrian refugees back to Syria.

Any recommendations?

You shouldn't be downvoted - LLMs could in theory be deterministic, but they currently are not, due to how models are implemented.

I think many have adopted "spec driven development" in the way you describe.

I found it works very well in once-off scenarios, but the specs often drift from the implementation. Even if you let the model update the spec at the end, the next few work items will make parts of it obsolete.

Maybe that's exactly the goal that "codespeak" is trying to solve, but I'm skeptical this will work well without more formal specifications in the mix.

This doesn't make too much sense to me.

* This isn't a language, it's some tooling to map specs to code and re-generate

* Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes)

* Models are evolving rapidly, this months flavour of Codex/Sonnet/etc would very likely generate different code from last months

* Text specifications are always under-specified, lossy and tend to gloss over a huge amount of details that the code has to make concrete - this is fine in a small example, but in a larger code base?

* Every non-trivial codebase would be made up of of hundreds of specs that interact and influence each other - very hard (and context - heavy) to read all specs that impact functionality and keep it coherent

I do think there are opportunities in this space, but what I'd like to see is:

* write text specifications

* model transforms text into a *formal* specification

* then the formal spec is translated into code which can be verified against the spec

2 and three could be merged into one if there were practical/popular languages that also support verification, in the vain of ADA/Spark.

But you can also get there by generating tests from the formal specification that validate the implementation.

Rust has managed just fine to remain mostly backwards compatible since 1.0 , while still allowing for evolution of the language through editions.

This puts much more work on the compiler development side, but it's a great boon for the ecosystem.

To be fair, zig is pre 1.0, but Zig is also already 8 years old. Rust turned 1.0 at ~ 5 years, I think.

What context length and related performance are you getting out if this setup?

At least 100k context without huge degradation is important for coding tasks. Most "I'm running this locally" reports only cover testing with very small context.

Musk is actually a brilliant marketer. He built his companies around a "vision", used it to attract high quality talent and push that talent to give their best.

For Tesla it was "electrify transport to end dependence on fossil fuels and save the planet", for SpaceX it was "save humanity by becoming a multi-planetary species".

With how much he talked about it, he did probably actually believe in Mars.

But now both of these ideals have come into conflict with his newfound political affiliations, so they have to be dropped.

Good PR moves.

Rust has an interesting crate for this, arc-swap [1].

It's essentially just an atomic pointer that can be swapped out.

[1] https://docs.rs/arc-swap/latest/arc_swap/

Rust has a very strict type system and an ecosystem that often utilizes the type system well.

Many things that would only be caught at runtime in other languages are caught at compile time in Rust, making coding agents iterate until things compile and work well.

Rust also has great error messages, which help the agents in fixing compilation errors.

Even Chrome has started to adopt Rust due to recurring memory vulnerabilities.... that's a big enough reason.

Gemini 3 is pretty good, even Flash is very smart for certain things, and fast!

BUT it is not good at all at tool calling and agentic workflows, especially compared to the recent two mini-generations of models (Codex 5.2/5.3, the last two versions of Anthropic models), and also fell behind a bit in reasoning.

I hope they manage to improve things on that front, because then Flash would be great for many tasks.

An Anthropic safety researcher just recently quit with very cryptic messages , saying "the world is in peril"... [1] (which may mean something, or nothing at all)

Codex quite often refuses to do "unsafe/unethical" things that Anthropic models will happily do without question.

Anthropic just raised 30 bn... OpenAI wants to raise 100bn+.

Thinking any of them will actually be restrained by ethics is foolish.

[1] https://news.ycombinator.com/item?id=46972496

From all indications the big players have healthy margins on inference.

Research and training are the cost sinks.

They claim the opposite, though, saying the chip is designed to tolerate many defects and work around them.

That's because many developers are used to working like this.

With AI, the correct approach is to think more like a software architect.

Learning to plan things out in your head upfront without to figure things out while coding requires a mindset shift, but is important to work effectively with the new tools.

To some this comes naturally, for others it is very hard.

I do not trust the AI benchmarks much, they often do not line up with my experience.

That said ... I do think Codex 5.2 was the best coding model for more complex tasks, albeit quite slow.

So very much looking forward to trying out 5.3.

Do you have a source for that?