Entries for August 4, 2026

People reacting to this also forget that the first deployment of codex was codex web, and it took many months for local codex to arrive I guess we are going full circle What is next? Use code-davinci-002 in VS Code? 😜

LFM 2.5-2.6B by @liquidai just launched and it punches above its weight! It can run 32 sessions (and more) in parallel with hundreds of output tokens per second aggregate throughput, on the DGX Spark! And this is just the base vLLM config on release date, I expect it to be optimized a lot more!

Btw it might just be the subjective feeling with the codex resets becoming less frequent

Shrinkflation in codex pro plan?

@natebrake @lumendriada @MozillaAI hmmm github.com/mozilla-ai/ota…

I'm having this paranoia now after blasting through my weekly usage in 2 days Need a gateway to keep track of my API calls to see whether openai is squeezing the tap, or it is just me using up more tokens

To be clear: - Codex desktop app can call list_threads and read_thread, but don't get a "search_in_thread" tool yet - Codex CLI gets neither of these, even though sessions are just sqlite and there is no good reason that I know to not provide them to the CLI too... Here, I vibeslopped my own codex session reader/search for example:

We are well into the agentic era, and the two big token harnesses Codex and Claude Code still do not give a search_session tool/CLI to agents by default? For it to search back in its session for stuff that got lost after compaction? Harnesses not produced by the big labs on the other hand might have this, like @AmpCode (read_thread, find_thread) and @goose_oss (Chatrecall) Which could either mean... a) Anthropic and OpenAI are being laggard b) They are intentionally keeping the base harness simple, because it hasn't been requested by enough people c) They have evidence that adding that complexity does not improve performance or even hurts it d) They bet that compaction will be so good, that it won't be necessary --- I don't believe (a) is true for either company (b) and (c) are more likely, (c) especially if they noticed a tendency for the model to call search_session unnecessarily (though imo this can be solved by limiting the number of times that the model can call that) (d) is logically false at the limit, but may be true in practice for >90% of the cases It is false because LLMs compress lossily, and "lossy" by definition implies: there exists at least one case where the session gets so big, that the model will not be able to compress every relevant info into the allotted summary size But I have seen that a considerable amount of people (including me or those at openai, see @reach_vb's quoted tweet) just keep using the same session for stuff. So a session being used for months straight will definitely not going to contain everything that happened in the summary Just that fact alone necessitates search_session IMO, should the model learn to use it sparingly in the lossy edge cases x.com/reach_vb/status/2068422255470579724

I have fixed German in alman.ai and almanpedia.org Should I fix AI’s english next? Train models to detect and translate AI word salad? Like this tweet if you want me to work on this

Also relevant, here is the potential reduction in tool call outputs, if you were to change that hard cap to other values For example, if you changed the hard cap from 40-50 kB to 1-2 kB, then overall you would have your tool calls have 80-85% less characters and hence tokens The graph is of course skewed due to the existing 40-50 kB hard caps from codex and pi Leaving here as a reference for people who might want to optimize their harness limits

Here is a distribution graph over character counts (x-axis) for all the tool calls I have accumulated on my DGX Spark, around 720k tool calls. Extracted from saved sessions Roughly 84% of all tool calls came from Codex, 12% from Pi, 2% from Claude Code, and 2% from Cursor Codex truncates tool output around 40 kB and pi at 50 kB natively. So you see the long tail of tool call outputs cluster around that point instead of continuing with a more expected pattern (what distribution should we expect from this?) It also seems that tool call outputs around 9k-12k unicode characters contribute the largest share of total characters, excluding the clustering around 40-50 kB All textual outputs: every tool result with text Shell outputs: results from that same set whose recorded tool was bash, exec_command, run_terminal_cmd, or another shell-named tool with a command input

OpenClaw support also coming soon as well!

I am trying to do something naughty GPT 5.6 Sol said "I'm sorry Dave, I'm afraid I can't do that" Kimi K3 happily obliged