I Used 50% of my Codex Sub in 36 Hours

I used about half my Codex subscription in a day and a half.

Not because I suddenly learned to type faster. Not some magic prompt either. I burned through it because I stopped juggling every Codex session by hand. Claude started launching Codex for me, in groups, and went and checked on the work while I did something else.

My Claude terminal wasn't tied up anymore. It was free to just talk through what we were building next, or queue up more work while the swarm ran. I could sit there planning out loud, or go work on something else on another monitor and just check back in.

Sounds like a story about hitting a usage limit. It's really a story about where the bottleneck moved.

Gabe and I have had this thesis for a while now, the one underneath AgentShelf. The monolithic model isn't the thing that wins. One giant brilliant model matters, sure, but the bigger jump is multiple agents that get assigned work, bounded, checked on, and synthesized back into one thing. We've said some version of that sentence to each other probably a hundred times. What changed this month is I finally felt it happen to my own workflow instead of just believing it as a product thesis.

AgentShelf doesn't do this exact thing today. I want to say that plainly. This was me, in Claude Code, with a plugin I forked myself. But it's the clearest personal proof I've had yet that the fleet idea is the right one to keep chasing.

The Handoff

The first Codex for Claude plugin, I liked right away. Claude could look at a problem, decide part of it belonged to Codex, hand that piece off. Useful. Saved me from opening a second terminal and re-explaining myself.

But it was still a handoff. One task, one worker, wait for it to come back. Didn't change how I thought about the work. Just moved who typed the command.

Fable

Fable is the model that made the shape of something different visible to me, even though it isn't the model that ended up doing the heavy lifting.

I'd send it a normal message and it would go launch subagents. Sometimes too many, honestly, more than the task needed, and I'd sit there watching a pile of them spin up wondering if I'd asked for that. It broke the prompt, wait, read the answer rhythm I was used to. At first that just felt like a bug in my expectations. But underneath the overshoot was a pattern I couldn't unsee once I saw it - launch a batch of investigators, let them go, wait, synthesize what comes back instead of carrying every step yourself.

Fable didn't give me the finished workflow. It gave me the shape of one.

The Fork

So I forked the Codex for Claude plugin and started building toward that shape on purpose.

The goal wasn't "make Codex smarter." Codex is already good at what it's good at - poking around a repo, running commands, editing files, telling me what it found. The goal was letting Claude treat a pool of Codex sessions the way a foreman treats a crew, instead of the way I'd been doing it, which was calling one contractor at a time and standing over their shoulder the whole time they worked.

What the fork ended up with: a swarm command that breaks independent subtasks into a group, a way to launch each piece as a background job tagged to that group, a status check that waits on the whole group instead of one job at a time, a result command that pulls every piece's output back together, a limit so I'm not accidentally opening forty sessions at once, worktree isolation for anything actually writing files, and a few typed job modes - discovery, spec-to-test, implementation, review, integrator - so a leg isn't just a prompt, it's more like a role.

None of that is exotic, honestly. What changed is Claude could dispatch, wait, collect, and hand me one synthesized answer, instead of me standing in the middle of five Codex windows trying to hold the whole picture in my head.

The Job Site

Here's the part that matters more than the plugin, and it took me a minute to name it right.

The swarm didn't work just because Claude could launch Codex in groups. It worked because Codex was landing in a repo I'd already spent months preparing for exactly this. agentshelf isn't a blank folder Codex meets for the first time in a prompt. It's got repo-local instructions, .codex config, skills and skill routing, conventions, known commands, verification habits, scripts, and honestly a small mountain of accumulated context from me chatting with Codex in that repo for months without really meaning to, slowly teaching it how to explain itself to an agent.

So the more accurate version isn't "Claude told Codex what to do." It's that Claude dispatched Codex into a job site I'd already built. That's why I could stop juggling those sessions by hand and it actually worked, instead of just producing five confidently wrong Codex sessions running side by side. A lot of what Claude would've otherwise had to cram into every swarm prompt already lived in the workspace.

I keep coming back to what that means for anyone who isn't me. Most people aren't going to spend months hand-teaching a repo how to cooperate with an agent, the way I did without really planning to. That setup shouldn't be the tax you pay before a fleet workflow becomes useful. That's the layer AgentShelf is actually trying to make ordinary - not one more chat box, the prepared job site and the crew that already knows how to work inside it.

Checking If It Was Real

I pulled this from the unified database I run across my machines, read-only, the session_aggregator schema. Wanted to know if this actually happened or just felt like it did.

Five days leading up to writing this: 1,172 sessions across Claude and Codex combined, 701 Claude, 471 Codex, 83,423 messages total. Two weeks earlier, a comparable window had 125 sessions. Three weeks earlier, 365. So yes, more activity. But the number that actually convinced me something structurally different was happening was narrower than that.

The first background Codex task the fork ever launched shows up in the trace July 3rd, 2:27am. I pulled the 36 hours starting right there and compared it to the same 36-hour window two and three weeks earlier. Swarm window: 579 sessions. Two weeks before that: 35. Three weeks before: 69. Not a gradual ramp. A step function, and it lines up almost exactly with the first time the background group commands show up at all.

Claude's bash commands mentioning Codex went from something like 47-58 a window to 1,309 in the last five days. Companion background launches, 153 in that span. Status checks and result pulls stacked on top - 171 status checks, 51 result pulls against those 153 launches, something like one and a half check-ins for every job I actually kicked off. I wasn't just launching work and walking away. Launch, check, collect, decide, launch again.

The cost numbers are directional, not a real invoice - a lot of it is subscription-attributed, not metered, and I don't want to pretend otherwise. But the API-equivalent estimate for that 36-hour window was around $648, against $244 and $461 for the earlier matched windows. Not actually a huge jump in dollar terms. What startled me wasn't the number. It was how fast a subscription starts to feel like infrastructure instead of a plan you bought. Once agents are driving other agents, the thing you watch isn't your monthly bill. It's throughput and rate limits.

And since it needs saying honestly - Fable wasn't the one doing most of this. Sonnet 5 carried the bulk of the actual launching once I built the thing, 962 of those bash commands, 126 of the background tasks. Fable had a real usage spike a few weeks earlier, 243 sessions and about 7,500 messages in one day, and that's genuinely where the pattern clicked for me. But the spark and the thing that actually ran with it weren't the same model. Fable showed me the shape. Sonnet is what I ran it through.

The Work Stopped Being A Line

The clearest version of this happened while I was setting up local LLM models.

One Claude thread running that work. While a set of experimental tests ran in the background, I launched a Codex swarm to research a related idea I wasn't sure was worth chasing. The research came back, I folded it into the local LLM work. Then the test results landed, changed the shape of things again, which led to another idea, which meant another swarm, this time for another round of tests. While those ran, I kicked off a scaffolding swarm for a different part of the system that needed to exist no matter how the previous local LLM question resolved.

Old way, that's a queue I'd have walked through one item at a time. Run the test, wait, go research, wait, come back, read it, decide, go scaffold, wait some more. Looked something like this:

old way, one line

run test -> wait -> read result -> go research -> wait -> read result
         -> decide -> go scaffold -> wait -> read result -> next idea

New way, several queues running at once, and I read whichever one finished first instead of waiting on all of them in order:

new way, a set of queues

test swarm       ----[running]----[done]
research swarm      ----[running]----[done]
scaffold swarm          ----[running]--------[done]

me: launch, launch, check test, keep thinking, check research,
    fold it in, launch again, check scaffold, decide

I wasn't waiting on the model anymore. I was waiting on the system. There's a real difference in what that does to your afternoon.

The database backs this up a little, though I think it's still an undercount since not every group gets tagged cleanly, and the count keeps climbing the longer I wait to check. 56 parsed swarm groups in that same five days, 42 with actual launches, one hour where eight distinct groups were live at once. Busiest single hour: 13 background launches, 15 status checks, 9 result pulls, inside sixty minutes. That's not chat. That's closer to running a small ops desk.

None of this works if the pieces aren't actually independent, worth saying plainly. Research can run while implementation runs. Review can run while a fix runs. Two swarms editing the same files at the same time is just a slower, more expensive way to make a merge conflict, and the worktree isolation in the fork exists specifically because I found that out the annoying way early on.

Plus, Not Versus

I don't think the lesson is Claude is better than Codex, or the other way around. The useful thing was never one model beating the other. It was what happened putting them together with a real split - Claude figuring out what I actually wanted, breaking it into pieces, launching the group, watching it, handing me back one synthesized answer instead of five raw transcripts. Codex doing the narrower thing it's good at inside each piece - poking around a repo, running commands, editing files when I'd let it, checking its own work, reporting back with evidence instead of vibes.

And me doing the thing that didn't go away. Deciding what's actually worth fanning out. Drawing the boundaries so the pieces don't step on each other. Reading the synthesized result with some skepticism instead of just accepting it. Deciding what's worth turning into a permanent pattern versus what was a one-off. I didn't remove myself from the loop. I moved from the keyboard layer to the judgment layer, and those aren't the same job, even though from the outside it might look like I did less.

me       -- sets intent, approves direction, decides what matters
            |
Claude   -- decomposes, launches, waits, synthesizes
            |
Codex    -- inspects, edits, verifies, reports

AgentShelf

I keep saying this isn't AgentShelf doing this yet, and I mean it. This was me and a fork of a plugin, run out of Claude Code, on a repo I've been quietly hand-teaching for months. But it's exactly the kind of thing I think the platform is supposed to make ordinary for people who aren't going to spend months building their own version of this by hand.

Not one more place to chat with a model. A prepared job site. A crew that already knows how to work inside it. Queues you can actually see instead of a black box. A human still sitting at the layer where the real decisions get made. I don't have a clean bow to tie on this one yet. I just know that for the first time, the fleet mindset stopped being a thesis Gabe and I repeat to each other and started being something I watched happen on my own machine, one background job at a time.

Not Just Me

Didn't want this to just be me and Gabe convincing ourselves of something in a vacuum, so I went looking for who else has run into the same shape of thing.

Anthropic's own writeup on how they built their multi-agent research system is the closest first-party confirmation I found - a lead Claude agent planning and spawning subagents beat a single Claude agent by 90% on their internal eval. Basically the same foreman-and-crew pattern, just for research instead of Codex jobs.

On the specific Claude-Code-driving-Codex angle, there's an actual paper, Glite ARF, running Claude Code and Codex CLI agents in parallel over isolated worktrees with verifiers checking the output. Close enough to what I built that it made me feel less like I'd invented something and more like I'd rediscovered something. Boris Cherny, who created Claude Code, told Business Insider he runs 5-10 concurrent sessions with overnight loops. Same move, different scale - stop juggling every session yourself.

The subscription-as-infrastructure feeling isn't just me either. Tom's Guide covered Anthropic adding weekly limits after people ran Claude Code around the clock, and the OpenClaw team reportedly burned through $1.3 million in tokens in a month running about a hundred parallel Codex instances. Different scale than my 36 hours. Same underlying thing. Once agents run agents, the subscription stops behaving like a subscription.

On the "prepared job site matters more than the prompt" piece, Philipp Schmid's context engineering post makes the case that agent reliability is mostly a context problem, not a prompting problem. Same thing I was trying to say about agentshelf already knowing how to be worked on.

I'll flag the pushback too, because I don't think the multi-agent thesis is free. Cognition's Don't Build Multi-Agents argues naive task decomposition across agents breaks down without shared context and careful tracing. Basically the same warning as the job-site point above, aimed the other direction. Fan work out carelessly and you don't get a crew. You get five workers who don't know what each other are doing.