\
I run nine AI personas on my machine. Hannibal orchestrates. He routes work to specialists: Cutter for video, Ink for design, Templeton for research, a few others for content and project management. Most days this setup does real work while I do something else. But for a while, two of those nine were running blind, and I didn’t notice until the work started coming back wrong.
This is the story of what broke, what I changed, and what it costs to add a second, much cheaper model into the loop as an independent reviewer.
The old way, and why it broke
Every team member used to run the same way: as a claude -p headless process, launched through a model-router proxy that sat between my orchestrator and the model. For most of the team, this was fine. The proxy did its job, the pane showed live output, I could see the agent working.
Cutter and Ink went through the same proxy, because at the time it was the only mechanism available to route them. It turned out that proxy eats stream-json events. That’s the format my harness uses to render an agent’s live output in a terminal pane. So the two panes doing video and design work rendered blank while the agent was actually working. No live report. No partial output. Nothing to look at until the process finished. I did try using herdr, but the 2nd window wasn’t working for me.
The result: I was getting video renders and design assets back with no visibility into how they got there. I wouldn’t know if it took the right path to get there, whether it touched files it shouldn’t have, or whether a mid-run decision quietly changed the brief. The tool that was supposed to show me progress was silently dieing, and I only found out because the outputs eventually told on themselves.
The proxy itself wasn’t broken for its actual job, which is OpenAI/Codex model routing. It just wasn’t built to carry stream-json, and nothing forced me to notice that until two specific panes went dark.
Getting handoff back, without losing visibility
The new pipeline is three stages, and each one runs in its own visible Orca pane: Claude plans, Codex builds, opencode running DeepSeek verifies. No proxy sits in the path for any of these three stages, so there’s nothing left to eat the events. I can watch Codex build the same way I’d watch a colleague’s screen share. I can watch DeepSeek review a diff line by line. Cutter and Ink both moved onto this pipeline specifically because it solved the blank-pane problem, and the rest of the content and PM roster stayed on the old delegate path, which was never broken.
A few things make this more than “now I can see a terminal”:
The orchestrator blocks on real events, not a sleep loop. It waits for a worker_done, an escalation, or a question, and reacts when one actually arrives, instead of polling on a timer and hoping something changed.
When a worker reports done. The coordinator independently runs a git diff against the commit from before the task was dispatched, and reads the worker’s full transcript. If the modified-files list goes beyond what the task spec authorized, that worker_done gets rejected, not accepted and filed away.
The verify stage is a second, independent reviewer, not a rubber stamp. DeepSeek looks at Codex’s diff with explicit instructions to review only and not edit. It reports findings. Any fix it identifies gets dispatched back to Codex as its own new task, rather than DeepSeek quietly patching things itself. I built it this way on purpose: the verifier can also be wrong, and I want two independent reads on anything that ships.
And a failed verification actually stops the pipeline. Downstream tasks are gated on the verify result, so a “fail” halts things rather than letting a broken build roll forward because nobody was watching that particular checkpoint.
Handoff stopped meaning “I’ll find out what happened when it’s done” and started meaning “I can watch it happen, and check it myself when it says it’s finished.”
What adding DeepSeek costs
Adding a second model into a pipeline invites an obvious question: does the extra step cost more than it’s worth? For the verify leg specifically, the answer is no, and the gap is large enough to be worth stating with real numbers instead of a shrug and “it’s cheaper.”
DeepSeek and Claude use different tokenizers, so comparing raw token counts between them doesn’t mean much. What’s comparable is what it costs to run the same review pass on either model, using published API pricing.
As of this writing, per million tokens: Claude Sonnet 5 runs $3.00 input and $15.00 output (an intro rate of $2.00 and $10.00 through the end of August). Claude Opus 5 runs $5.00 input and $25.00 output. DeepSeek V4 Pro, run through opencode, runs $0.435 input and $0.87 output.
If the verify leg had stayed on Claude, which is the natural default since that’s what most of the team runs on, the gap looks like this: against Sonnet 5, DeepSeek runs roughly 7x cheaper on input and 17x cheaper on output. Against Opus 5, it’s closer to 11x cheaper on input and 29x cheaper on output. Put together, moving that one stage to DeepSeek V4 Pro cuts its cost by somewhere around 85 to 95 percent compared to running the identical review on Claude, depending on which model you’re comparing against and whether you’re weighting input or output tokens more heavily.
It did take me a bit to get use to Orca but I am loving it now.