So a couple of days ago EF-Map gained its biggest Intelligence feature yet, a tool that lets subscribers build their own dashboards over live EVE Frontier chain data. Custom panels, an AI drafter, preset recipes, cross-device sync, share links, the lot. I'll do a proper post about the tool itself with a video once I've had a play with it in anger. This post is about something I think is more interesting, which is how it got built. Because most of it got built while I was asleep.
I've written before about how one of these features comes together in a day and about what a year of this looks like read back from the project's own decision log. The short version of those posts is that I'm a vibe coder. I dictate what I want, an LLM writes the code, I test it, then round again. What's changed this month is the shape of that loop, and I've got the numbers to show it, so I thought they were worth writing down before I forget how this felt.
How this used to work
When I started EF-Map the models had tiny context windows. If you look at the early git history the commits are minutes apart, because that was the size of change a model could hold in its head. My job was to be the memory. Feed it a small task, check the output, feed it the next one. It worked, obviously, the map exists. But I was the bottleneck and the loop was me.
More recently the loop got longer but I was still in it. The pattern for a big feature was a planning document broken into phases, and I'd kick off a phase, wait for the agent to finish, smoke test it in the browser, then kick off the next one. Better, but a phase was maybe an hour, so a five phase feature was an evening of me hovering. The agent did the work but I did the sequencing, and if I walked away the whole thing just stopped.
What changed
Two things. The first is Claude Fable 5, which is Anthropic's new model tier that sits above Opus. The honest one line description is that it's the same kind of model but it holds a very long train of thought without losing the plot, which turns out to be exactly what an orchestrator needs. The second is subagents, which have been around for a while, but I'd not leaned on them like this before. The idea is the orchestrator never reads a single source file itself. It writes a detailed brief, hands it to a fresh Claude Opus 5 agent with its own clean context, and gets back a report. The file dumps, the test output, the twenty rounds of edit and retry all stay in the subagent's context and get thrown away. The orchestrator only ever accumulates the distilled summaries.
The reason that matters is context rot. The internet says, and my own experience agrees, that agents get less accurate as their input context fills up. Compaction, where the harness summarises old context to make room, is where subtle mistakes creep in. So the goal was one Fable orchestrator that never compacts, spending its context only on decisions, and a stream of disposable Opus agents doing the actual reading and writing. After the overnight run and four follow-up sessions, call it fourteen hours of orchestration, the Fable context is still only a bit over half used. No compaction ever happened. That's the whole trick.
So the experiment was this. I had a planning document for the custom panels feature with five phases in it. Phase 1 I did the old way, present and testing. Then I wrote a contract section into the plan that said, in effect, here are all the decisions pre-made, here are the defaults for every open question, do phases 2 through 5 to completion, deploy a preview, don't merge, don't ask me anything. I started a fresh Fable chat, pointed it at the document, and went to bed.
The night, and the days after, in numbers
I woke up to a pushed branch, a preview URL and a closeout report. Four phases built, which included a query language extension deployed to the live database API on my VPS, the whole custom panels system, an AI panel drafter, and encrypted cross-device sync. Every phase had been through an adversarial code review by a separate agent before the next phase started, and the review findings had been fixed, not just noted. Since then there have been four daytime polish passes, each one driven by pasting the closeout into GPT-5.6 Sol, OpenAI's model in ChatGPT, for an external review and feeding what came back into the next session. Here's the whole initiative as it was recorded in the planning document.
| Pass | Wall clock | Agents used | Agent compute | Subagent output tokens |
|---|---|---|---|---|
| Overnight run, phases 2 to 5, unattended | ~5h 35m | 17 (15 Opus, 2 Fable) | ~5h 06m | ~3.71M |
| Pass 1: external review fixes, header UX, briefing file | ~1h 15m | 4 Opus | ~52m | ~0.62M |
| Pass 2: Panel Creator split into its own tool | ~1h 55m | 7 Opus | ~1h 46m | ~1.39M |
| Pass 3: manual widget builder, one shared draft | ~3h 05m | 6 Opus | ~1h 54m | ~1.29M |
| Pass 4: release readiness, add widget to existing panels | ~1h 50m | 4 Opus | ~1h 24m | ~0.99M |
| Total | ~13h 40m | 38 | ~11h 02m | ~8.0M |
A few things in that table are worth pulling out. Agent compute is close to wall clock because the phases were deliberately sequential, each one builds on the last, so there wasn't much to parallelise. The orchestrator filled the gaps itself doing deploys, commits and smoke tests. Those 38 subagents made about 1,600 tool calls and produced 8 million output tokens of work, and almost none of that ever touched the orchestrator's context. And the overnight run included two deployments to a live server, done by the orchestrator over SSH with backups and a change log, which is the bit I'd have bet against working unattended.
The bit I find genuinely reassuring is the reviews. Every single pass ended with an adversarial review agent whose brief was to assume the implementers made mistakes and find them. Every single pass, it did. The overnight run alone surfaced one blocker and twelve majors, all fixed before I saw the branch. One review agent went as far as querying the live database and found that four of the "known good" preset dashboards were silently ranking only 1.3% of the data because of a null column, which is the kind of thing that looks fine in every test and is just wrong in production. A different agent proved a refactor was safe by rendering the UI before and after and diffing the bytes. I didn't ask for either of those specifically. The briefs said be adversarial, and Opus 5 agents are good enough now to decide what that means for the code in front of them.
There's also a browser testing trick that fell out of this which I'll probably keep forever. The paid features sit behind an entitlement check, so an agent can't normally test them. The verification agents worked out they could run the production build locally, intercept the one network call that checks entitlement, and mock it. So every workflow, building a panel by hand, AI drafting, sharing, syncing, got clicked through by an agent in a real browser against a production build before I ever saw a preview. My job when I wake up is taste, not correctness. That's a real change from a year ago when my smoke testing was the only testing.
What it cost
I checked my usage before the first session and after the last one. The whole thing, fourteen odd hours of orchestration producing a shippable feature branch of about 18,000 added lines plus reviews and documentation, moved my weekly usage on the Claude Max $200 plan from 5% to 18%. So 13% of one week's allowance. The Fable share moved from 8% to 18% against a cap that lets Fable be up to half your weekly usage. Call it a seventh of a week, on a plan that allows this every week. I don't know the exact dollar equivalence and I'd be suspicious of anyone who claimed one, because subscription allowances aren't API tokens. But as a sanity check, the 8 million subagent output tokens alone would be about $200 at Opus 5's API output rate of $25 per million, before counting input tokens or the Fable orchestrator on top, and Anthropic publishes Fable output at $50 per million. However you squint at it, the subscription is doing a lot of heavy lifting.
| Model | API input, per M tokens | API output, per M tokens |
|---|---|---|
| Claude Fable 5 | $10 | $50 |
| Claude Opus 5 | $5 | $25 |
| Claude Sonnet 5 | $3 ($2 until Aug 31) | $15 ($10 until Aug 31) |
Why Opus for the subagents rather than something cheaper? Mostly because the briefs are long and precise, and a stronger model wrings more out of a good brief. The pattern that worked was the orchestrator spending real effort writing each brief, sometimes 500 words of context, constraints and traps, and Opus 5 actioning it more or less exactly. I suspect Sonnet would manage a good chunk of these tasks for less, and that's an experiment for another feature. But when the failure mode is a subtle bug shipping to paying subscribers, the price gap between Opus and Sonnet subagents is not where I want to economise yet.
What I'd tell you to steal
The thing that made the unattended run work wasn't the model, or not only the model. It was that the plan document had every decision already made. Locked decisions with reasons, and every open question resolved with a stated default so the run could never stall waiting for me. The contract even had a fallback for the thing I expected to fail, the SSH deploy, with instructions to keep the client capability-gated and move on if it got blocked. It didn't get blocked, but the point is the agent never had to guess what I'd want. If you're going to try this, the hours you spend on that document before bed are the run.
The second thing is putting the checking inside the loop. An implementation agent, then a separate adversarial review agent, then a fix pass, then an independent verification agent in a real browser, per phase, before moving on. It sounds expensive and it is maybe a third of the token spend. It's also why five passes of external review by GPT-5.6 Sol, a different vendor's model looking at the same code, found progressively less each time. The reason that job goes to ChatGPT specifically is its GitHub connector, which I can't recommend enough for code reviews. It reads the repo live from the web, so I can just say look at the diff on this feature branch and it does, no picking files, no import button, no pasting code. For my purposes it's far ahead of what Gemini or Anthropic offer on the web for this at the moment. Nothing it found was ever nothing, mind. Every externally reported issue, once verified against the code, turned out to be real, which was humbling, and is why the process keeps a second set of eyes from outside the Anthropic family.
And the third thing is knowing when not to use this. This worked because it was a well-specified feature on an established codebase with strong guardrails, agent instruction files, gates that must pass, documented conventions. The internet is full of talk about agents that prompt themselves in a loop until the job is done, and for greenfield feature work I still don't quite believe it. What I believe in is a human making the decisions in advance, in writing, and then getting out of the way.
But yeah, the experiment worked, so this is how EF-Map gets built now. Overnight for the heavy lifting, short daytime passes for the polish, and me doing taste, testing and decisions rather than sequencing. The panel tool itself ships to everyone shortly and I'll do a proper walkthrough post with a video then. If you've tried something similar, or you think the numbers above hide a catch I've not spotted, let me know, I'm genuinely curious whether this holds up for anyone else.
Related Posts
- Three apps in one day, dictated from inside a video game - the same loop before the orchestrator pattern, with me still doing the sequencing
- A year of EF-Map, read back from its own decision log - where the guardrails these agents rely on came from
- Half a million light-years saved: eleven months of EF-Map usage data - what the people on the other end of all this actually use
- Transparency report: how every feature works under the hood - what runs where, for anyone wondering what the agents were touching