Two beautiful visions for working with AI models, a day of architecture and patches, and the one question a small model could not answer: who are you talking to?
Abstract. I wanted two things from AI-assisted engineering. An Economy mode: when my Claude quota runs low, the work keeps going on a cheap model and Claude costs almost nothing. A Stable Engineering mode: the strong model (Claude Opus) spends itself only on judgment — specs and final review — while a cheap model (DeepSeek) does the labor. We designed a layered architecture for both, tested every piece, and found problems everywhere. Each problem got a new mechanism; each mechanism got a patch. Within one day the dispatch rule went through six versions; about 36 mechanisms came and went, with up to 22 alive at once. What finally broke it was simple: the small model at the front door (Claude Haiku) could not tell whether I was talking to it or wanted my words passed on to Opus — and no rule could fix that, because deciding is exactly what it was forbidden to do. We tore the architecture down. What is left is a few lines of rules, one script and three mechanisms.
The core idea: don't over-think the architecture. With strong models it quite likely gets in the way, and a process design, however sensible on paper, is quite likely untested speculation.
I do engineering in the Claude Code desktop app. Opus is excellent but quota-limited. DeepSeek offers an Anthropic-compatible API, so the very same Claude Code command line can run on DeepSeek at almost no cost to my Claude quota. Haiku is cheap and fast. That suggests two modes.
Both visions share an assumption that felt obviously right: if we draw the right boxes and arrows, we can route each kind of work to the cheapest model that can handle it. The rest of this report is what happened to that assumption.
The design (“V2”) borrowed from two respectable sources: DeepSeek Harness's super-agent pattern (a light router in front, strong workers behind, async events, a watchdog) and Anthropic's orchestrator–worker pattern (a strong model supervises big tasks). Click a layer to see what each mode put there — and what became of it.
On top of the layers sat the mode switch itself: read the quota with a tool that only reports whole percentages, pick a tier, allow manual overrides with an expiry date, and print the current tier on the first line of every plan — enforced by a hook that would reject a plan whose first line didn't match the format.
To the design's credit, we tested. Seven experiments (T0–T6) in a day. Every number below comes from that day's logs, ledgers and data tables.
| Test | Question | Result |
|---|---|---|
| T0 | Can a DeepSeek agent spawn its own subagents? | Pass |
| T1 | Can a hook stop the main chat from editing files itself (a “structural router”)? | Pass |
| T2 | Do the ledger and the completion gate work? | Pass |
| T3 | Can a hook push a subagent back until it finishes? | Pass |
One real task (finalization logic in a task queue), two routes. A: DeepSeek Pro writes the spec. B: Opus writes the spec from a Flash summary. Both: Flash executes, Flash reviews, Opus does the final review. Five hidden acceptance tests were written separately.
Planning and “grilling” (interviewing me about requirements) ran in the main chat — which in Economy mode is Haiku, so design judgment got weaker exactly where it mattered. The fix was another layer: Haiku relays, while an Opus subagent or DeepSeek asks the questions.
Each test exposed a problem. Each problem was answered the same way: with a new mechanism. Step through the patch log.
Pick a version. Struck-through items have been removed; outlined items are new in that version; a red mark means the mechanism was never tested on a real task or never shipped.
By v0.5 the main chat was reduced to a pure relay. Its whole job: pass my words to a freshly spawned Opus supervisor, pass the supervisor's answer back, and never think for itself. Any engineering or project request — even just a question — had to be forwarded. No exceptions for “small things” (an earlier exception had let Haiku quietly do work itself).
It failed for a reason that sounds trivial and turned out to be fatal. Try being the relay. Each message below is one I might send; two are real messages I sent to a Haiku session.
The rule said “don't judge”, but “should I forward this?” is a judgment — and the rule handed it to the weakest model in the system. A hook can stop a model from doing something (T1 proved that); it cannot stop a model from failing to forward, or from losing meaning while compressing. Nor did the relay save anything: every fresh supervisor re-read the context, and when the main chat was already Opus, spawning an Opus supervisor was pure duplication. After using it, my verdict was blunt: Haiku was not good enough for this job. But a stronger relay would only have hidden the flaw: the architecture had made the front door the router of intent, and intent is the hardest thing in the whole conversation.
v1.0 tried one more time with less: tier by whichever model the main chat is running; Haiku only has to sort messages into three bins (change code / ask about the project / chat); a script writes the task card, runs a gate, and stops after three rounds. It had 30 unit tests, all green.
sub function. The card-writing model copied a test command that needs tests/__init__.py; the same card forbade adding __init__.py. Round 1: acceptance failed. Round 2: the file was added, acceptance passed, the gate flagged it as out of scope. Round 3: stalled, killed by hand. Two checks contradicted each other, and no executor, however capable, could satisfy both.That was the end of the architecture. v2.0 deleted the gate, the acceptance commands, the rework rounds, the card writer, the ledger, the templates, the tests and the relay layer. The same task then took 7 turns and 11 seconds.
| Economy: promised | Economy: now | |
|---|---|---|
| Main chat | Haiku relays to a DeepSeek Pro supervisor | Haiku chats; for engineering it copies my words verbatim into one command and relays the reply unchanged |
| Checks | Gate + Flash review + Pro final review | None — I read the result |
| Stable: promised | Stable: now | |
| Opus | Short calls for spec and review; never reads code | Works directly; hands off to DeepSeek whatever it can; reads the diff itself |
| Execution | Flash, inside a gated, sandboxed pipeline | Flash, with its full toolset and one 80-turn cap |
| Saving | 80–90% (estimated) | Unknown (the meter can't show it) |
A last irony. The script that survived still launched DeepSeek with a --bare “isolation” flag, which silently strips the agent down to three tools and takes away its ability to spawn subagents. T0 had already discovered this, and it had been written into two notes. Nobody re-read them; the limitation was recorded as a fact about DeepSeek. It was fixed only after I asked why. Even the simplification inherited a piece of the old architecture that was getting in the model's way.
Rich Sutton's The Bitter Lesson observes that, in the long run, general methods that leverage computation beat methods that encode human knowledge by hand. This was a one-day, one-person miniature of the same thing.