When Codex Started Chatting Too Much

AI has been part of my everyday engineering workflow for a while. Over the last few months, a lot of that work has been happening through Codex. Around it, I gradually built a workflow that worked well for me: global and local skills, project memory, small tools, conventions, checks, sub-agents, and orchestration for more complex tasks.

Some things deliberately stayed local to individual projects. That was my testing ground. Try one approach here, another one there, see how they behave under real work, then promote the useful parts to the global level.

As long as the projects mostly lived their own lives, this worked well. Tasks got done. Code got written. Tokens got burned. And the budget was fine, so I barely thought about it.

Then Codex got another update, and the first thing I noticed was that it had become suspiciously chatty.

I was used to short, dry progress updates. What it found. What it was about to do. What happened. A few technical lines along the way were perfectly fine. Now Codex started telling stories: where it was going, why it was going there, what it expected to find, and what it planned to do afterwards. Sometimes it felt like one more update and it would tell me how it felt about the file it had just opened.

It was annoying, but it also looked easy to fix. A few lines in AGENTS.md: less commentary, fewer intermediate updates, more work. I probably would have stopped there.

Then something much more interesting happened. During a completely ordinary working session, Codex stopped and told me that my five-hour limit was gone. After roughly an hour. That was unusual.

I had worked intensively with the same limits before and rarely had to think about them. Now the same budget was disappearing at a ridiculous speed. Suddenly, the verbosity looked different. Maybe it was simply the most visible symptom of something larger.

I took the Markdown logs from several sessions and started looking at what was actually happening. That was where things got interesting: the problem was much bigger than output tokens.

Codex was reading files it had already inspected. It was returning to the same areas of a repository. It repeated discovery. It made additional tool calls. It expanded the search area after the task already had enough context.

And there was another change that bothered me more: some instructions were simply being skipped. My workflow used to give the execution a fairly predictable shape. Now I would sometimes see something closer to this: do a piece of work, move on, later notice a requirement from the instructions, go back, redo part of the work, inspect the context again. Each individual detour was cheap, but an agent can perform hundreds of small actions during a larger task. Once several small inefficiencies start repeating across the entire session, they become expensive very quickly.

At that point, this stopped being a story about a chatty Codex. I started looking at the whole execution path: What gets loaded? When? How many times? How much context does this particular step actually need? What is already known from the previous step? Why are we discovering it again? Where does another executor pass begin?

Those observations gradually became a separate skill that I called Token Efficiency. It collected concrete rules from real sessions: bound discovery, reuse known context, avoid redundant reads, persist useful outcomes between steps, keep execution local. One rule captured the idea particularly well:

Plan globally. Execute locally. Persist outcomes.

Understanding a task can require broad context. Executing one specific step usually requires only a small part of it. And the useful result of that step should become an artifact for the next one, rather than forcing another session to reconstruct the same path. That naturally led to memory.

Each project already had its own project memory. It worked well for local decisions, state, and context. But by then, more and more tasks crossed project boundaries.

A task could start in one project, depend on a decision made in another, and continue in a third. Local experiments that had once been isolated could now meet inside the same execution path. That created a need for a layer above individual project memories, one that could carry useful state and decisions across sessions and projects without dragging all of their history along with it.

And somewhere around here I made one of those engineering mistakes that looks painfully obvious afterwards: I had already solved a very similar problem.

For ADRs, code reviews, and a few other workflows, I was already using sub-agents and orchestration. A larger task was split into specialized parts. Each agent received limited context, did one job, returned an outcome, and the next stage worked from that prepared artifact.

It worked. It worked well. Yet when the same shape of problem appeared at the session and project level, I somehow went off and started building the solution again. A few iterations later came the familiar moment:

Wait. I already do this.

Engineering stories are convenient to retell as a straight line:

problem → analysis → architecture → solution

Mine are usually closer to:

problem → idea → another idea → fix → bigger fix → wait a minute → oh, fuck → architecture

This one was a particularly good example. But the fun was only starting.

Token Efficiency kept growing. Every new session brought another edge case. Find another redundant pass, add a rule. Find a way around the rule, add a check. Hit a new scenario, add another instruction. Every individual change made sense.

The skill became smarter. And larger. Then came probably the funniest moment in the entire story.

I loaded Token Efficiency into another session, and Codex almost immediately started compaction. For a few seconds, I just stared at it. The skill whose job was to reduce context consumption had become large enough to consume the context simply by being loaded.

The monster ate itself.

It would be difficult to invent a better benchmark. In the process of optimizing context consumption, I had gradually built such a detailed system for optimizing context consumption that the cost of the system itself had started eating the benefit it was supposed to provide.

So I disabled the current version of Token Efficiency. That is also part of the experiment. Sometimes the result of an optimization is removing the optimization.

The problem looks much clearer now. A large part of the cost sits around the executor pass. The next version therefore needs to be much slimmer and much more behavioral.

A small core behavior can stay loaded. It decides what a particular task actually needs. Specialized rules, memory, and tools can then be loaded in small pieces, only when the execution path calls for them. Something closer to:

load less → observe → decide → load what is needed → execute → persist

instead of:

load everything we know about efficiency → start working efficiently

The second version sounds especially good now.

This whole story started with a tiny oddity. Codex suddenly started talking too much. Then a five-hour limit disappeared in about an hour. Then the session logs showed repeated passes, unnecessary discovery, and skipped instructions.

That produced a skill. The skill grew into a system. The system started asking for orchestration. And then the system designed to save context consumed enough context to trigger compaction and got switched off.

That is probably why I like this story. There is no clean moment where I immediately saw the problem and built the perfect architecture.

Part of the right architecture was sitting next to me the whole time, already working in other workflows. I still had to arrive at it a second time. And the first serious version of the solution eventually became part of the problem itself.

Right now, Token Efficiency is disabled. The next experiment is a slim version built around behavioral execution and loading only what the current executor pass needs. At least, that is the plan. After watching a context-efficiency skill trigger compaction simply by loading itself, I am making predictions about this optimization a little more carefully.