We built a BCC plugin which should save your tokens and unstuck goals in Codex

[IPFSae]

Better Codex Context (BCC) is a plugin that changes how Codex manages context, aiming to fix some of the biggest headaches we've run into with large projects and long-running coding tasks.

So we've been using Codex pretty much nonstop lately, mostly on bigger projects, and honestly, the context situation was getting ridiculous lol.

You start with a simple task, Codex does great for a while, then the context gets huge, compaction takes forever, and suddenly it's reading the same files again, forgetting stuff you told it hours ago, or trying to fix the same bug for the 10th time.

And my favorite part... instead of fixing the actual problem, it adds another fallback, another wrapper, another 200 lines of code 💀

We got tired of this and ended up building BCC (Better Codex Context).

The idea is pretty simple: why are we forcing Codex to carry its entire conversation around all the time?

So here's what we did

• Your instructions don't just vanish. We store the original user requests separately, not just some AI-generated summary. Even after multiple context resets, Codex can still look up exactly what you asked for.

• No more waiting forever for compaction. BCC uses Codex's native context reset and restores a smaller shadow context. The old conversation gets compressed in the background, so you don't have to sit there watching Codex think about its own history lol.

• It remembers WHY code was changed. This one is probably my favorite. Every time Codex changes code, it records why it made that change, what task it was for, what could break, and what still needs testing. So after a context reset, it doesn't have to guess what the previous Codex was thinking.

• It tries to stop those stupid coding loops. Same test failing over and over? Code going A → B → A → B? BCC notices some of these patterns and tells Codex to stop patching random stuff and rethink the root cause.

• Important architecture docs stay tracked. Instead of stuffing huge docs into every new context, it remembers which ones matter, whether they've changed, and where to find them.

Less patching, more actual problem-solving

We also added some rules to push Codex away from its usual "just add another patch" behavior.

You know, actually investigate the root cause, reuse existing code, and delete unnecessary stuff instead of endlessly piling more on top.

And no, we didn't build some crazy multi-agent memory system with 5 vector databases lol.

Most of it is just Python, SQLite, hooks, and a separate background compression process.

Does it actually help?

So far, it's been pretty nice for our long coding sessions. Codex feels less sluggish and seems to stay focused on the actual goal a lot better.

We've got some initial token measurements, but still need more proper testing before claiming any massive savings or improvement in coding success rates.

Give it a try 👀

GitHub repo: https://github.com/mathline-io/better-codex-context

If you're using Codex CLI or the VS Code extension, especially on projects where your sessions get stupidly long, give it a try.

Really wanna know how it behaves outside our own setup.

Does it actually save you tokens? Does Codex stop going in circles? Does anything get lost after a reset? Or does it break something completely unexpected? 😂

Feel free to roast the code too. Bugs, weird edge cases, bad design decisions, whatever. That's kinda why we're putting it out there.

Would love to hear what you guys think.

[ryanroundhouse]

One measurement edge case I'd test before treating latency_s_by_context_k as request latency:

In analyze(), each usage record gets when - last_input. The anchor advances on task start, a user-message event or tool output, but not on a usage record. Consecutive usage records without one of those intervening events can therefore share the same anchor.

A small synthetic fixture would make this visible: emit a task_started event at a nonzero timestamp, then emit five usage records at +5, +10, +15, +20 and +25 seconds, all with 10,000 input tokens and 100 output tokens, with no intervening input event. By inspection, the current aggregation would report a 15-second median for that bucket. Those timestamps alone don't establish five individually timed requests.

I'd label this “time since the last recognized input event,” or use matched request-start/end evidence for request latency and report unmatched cases separately. Simply advancing the anchor on usage records would measure completion-to-completion spacing, which isn't necessarily request duration either.

I haven't run BCC or inspected the original measurement logs, so this doesn't establish whether that event pattern occurs in the published sample or changes its conclusions. It's a focused fixture suggestion for the measurement script.

Disclosure: I build Zozo HQ, a coding-agent harness. Written with AI assistance.