We Built a Parachute for Claude Code. It Became a Harness.

Six months ago, a colleague told me about Claude Code as the answer to a project I was stuck on, so I decided to give it a try. Today I'm still a little surprised: "we," Claude Code and I, became a team. We run planning and review sessions, sprints, and retrospectives, the same rituals and cadence I've experienced on every human team I've been part of. I've written before about that operating model and the context it depends on. This is the story of the harness underneath it, the part I never set out to build.

The teammate that kept vanishing

One night I queued three tasks for my agents and went to sleep. Around 3am, all three hit the rate limit at once. The reset was five hours away, and two hours of their analysis was gone, trapped in logs I couldn't recover. That's the part people underestimate: when a limit lands on a coordinator running three agents, you don't lose one thing. You lose all of it, the context rots before it can be saved, and you pay the tokens again to rebuild it.

We wanted a teammate that didn't just stop. But a fixed monthly plan, chosen for predictable cost, has a hard edge: hit the cap and you're done, usually mid-experiment, usually late on a Friday.

So we built a parachute.

The parachute: a transparent proxy

We called it the Anthropic Failover Proxy, or AFP. It started as a way to cut token cost: send part of the work to a free local model and keep the rest on the official API. It's a transparent reverse proxy that sits between Claude Code and the Anthropic API. You point one environment variable at it:

ANTHROPIC_BASE_URL=http://localhost:8100

The catch showed up immediately. A Claude Code session can't be split mid-conversation, and once the REPL launches against a backend, that's the backend for the whole session, no swapping midstream. So the choice had to be made upfront, every time.

Ollama had just shipped a native way to point Claude Code straight at local models, and I tried it directly first. I couldn't get it to hold up reliably. The next option was a platform that lets you use different LLM models through one API, one I'd bought into a year earlier and barely touched, which actually hosts the real Anthropic models, so in theory the full capability should have been there too. It wasn't: its API has its own proprietary shape, it follows neither the OpenAI standard nor the Anthropic one, so even the right model underneath couldn't get through the REPL cleanly. When I asked Claude Code whether we could make this work, the answer reframed the problem: it wasn't which model answered, it was how that model's backend talked to the harness and the REPL, the tool-call protocol underneath. A thin wrapper wouldn't cover that.

I didn't start by comparing AFP to something like LiteLLM or OpenRouter either. Around the same time, LiteLLM's PyPI package was compromised through a poisoned CI dependency that exfiltrated a maintainer's publish token, harvesting credentials on install. That put it in context: this was a security concern too. AFP had to translate both ways: responses into a shape the REPL understands, and the REPL's expectations back into something the model actually driving the session could use.

When Anthropic is healthy, AFP is invisible. It forwards the request, streams the answer back, and gets out of the way. On a rate limit or an overload it doesn't surface the error; it reroutes down a ladder of fallbacks and translates the answer back into the shape Claude Code expects, so the tool never knows it left home.

The first rung below Anthropic was that same platform, sitting on a pool of free credits I'd never gotten around to using. So when my subscription hit its cap, AFP could route there and keep the same models answering, spending those idle credits instead of paying Anthropic's own overage rate.

The fallback ladder: Anthropic first, a hosted fallback next, a local model on our own hardware after that, and an honest 503 if everything is gone.

Making a fallback invisible is harder than it looks. Each backend speaks its own dialect, and Claude Code leans hard on tool calls, which is exactly where naive fallbacks break. One runtime returned tool arguments as a raw string where the validator expected a parsed object, and the call failed silently. Once a fallback has to be drop-in compatible, "it mostly works" is not good enough.

We got resilience. But the free credits that came with it ran out fast too, and a hosted fallback is still someone else's cloud.

Going local, and finding sovereignty

So we added another rung: a model running locally, on the same MacBook I work on. That fixed the credits problem. What I didn't expect was the second problem it solved.

A pattern runs through this whole story. Six months in, most of my project ideas were still in progress, yet I had shipped a steady stream of other things: hooks, gates, routers, fallbacks. Every one was a side quest that built the infrastructure the real work needed. Going local was one. So was the scare that came next.

Testing an app, Claude leaked a token into the chat, and now it was in the context, the history, on its way to Anthropic. That's when it clicked: we have to limit what we expose to the agents while still letting them work. That side quest became our hooks and hard gates, an encrypted secrets vault (now replaced by the open-source Infisical), and rules to keep secrets out of the conversation in the first place.

Then, almost at once, three things pulled me toward data sovereignty. A colleague's talk on sovereign data platforms got me thinking about who actually controls where data lives and is processed. A conversation with NVIDIA's Brev team landed a sharp point: for most companies the ceiling on self-hosting AI isn't the model or the budget, it's energy, whether your building can power the GPUs. And the Dutch government had just blocked the sale of Solvinity, which runs DigiD, over exactly this: data on US-owned infrastructure is reachable under the US CLOUD Act.

The loud version of sovereignty is data centers and national capacity. The practical version sits on my desk: can my workflow keep sensitive data on hardware I control, and degrade gracefully when it must?

Sovereignty, the practical version: keep the sensitive data home, and let only what is allowed leave.

That reordered the ladder, local first and cloud as backup, and added a rule: sensitive data is sanitized before anything is sent, or kept out of the chat entirely. That last part is the hard one. Transcripts and internal documents are full of PII, and a name can't be hard-gated. I can't claim it's perfect, or that nothing ever reaches a third party. But it's far better than where we started, and still improving.

When something truly can't leave the client or Xebia, I don't let it into the chat at all, not even locally, because the memory can be read back later. Most people badly underestimate how much they hand their agents every day.

Running a 35-billion-parameter model on a laptop you also work on is its own problem: offloading the experts so only the active parameters sit in GPU memory, and caching Claude Code's enormous, constant preamble so it isn't reprocessed on every turn. That deserves its own post, and I wrote the setup up separately; a companion piece, Running a local LLM tier for Claude Code on your Mac, is coming soon.

We had a first draft of sovereignty. But by now every request already flowed through this one small proxy, which raised a different question. What else belongs here?

The turn: one seam becomes a harness

The rate limit had taught me where work survives: a helper agent loses its context the moment it's interrupted, while a full session keeps its history and memory. So I wanted two full sessions coordinating, not one spawning fragile helpers. The naive version hit two walls, and Claude was blunt about both: it can't launch another Claude Code session from inside itself, and by design it only acts on instructions from me, the human in its session, not on messages from another process.

Then I read about a feature Anthropic had shipped, channels: a way for a server to push messages into a running Claude Code session as events it can act on. That was the missing half. Another side quest: we built a server, Claude-Nexus. Then it hit us: AFP is already the layer every request passes through, so make it the broker. Only an authorized server may inject messages, behind HMAC-signed authentication, and a human still confirms, per session, that a channel is trusted before acting on its messages. The safety rule isn't bypassed; it's kept.

That turned the parachute into a hub. Sessions on different machines on my LAN can talk now; I've used it to fix a config problem on one machine from another. Other tools, Codex, Antigravity, and copilot-cli, can join the same conversation. And when I wanted Claude on stage for a talk, I didn't give the avatar (Amica) its own model and one more thing to secure. I routed Claude through it instead. Same guardrails, same memory, just a new face.

One seam, many surfaces. Every surface reaches the models, the shared memory, and the guardrails through the same layer, so access is governed in one place.

We got a harness: one seam, many surfaces, one place to govern access. But if the valuable part is the layer I built, the routing, the local-first handling, the governance, the connections, what does that make the model?

What this actually is: harness engineering

Here's the honest part: I wasn't trying to do "harness engineering." Every piece was a side quest forced by a real project, and I just wanted to keep working. Six months in, most of my original ideas were still in progress, yet I had built and shipped all of this scaffolding around them. It was only when I wrote about it in my newsletter that the side quests turned out to have a name, that I'd been doing harness engineering empirically the whole time, and that the big labs are now racing to build the same thing.

Nate B Jones puts it well in a recent video, "GLM 5.2 is free and beats Claude on most work, so why can't companies switch?": a model is "a brain in a jar" without a harness, and the bottleneck now is "the last mile," not the model call. I'd add one inversion. For a frontier lab, the harness is a moat: your context, locked to their platform. Mine does the opposite. Because it can fail over to a local model or another provider, it's what keeps me from being captive to any one of them. Same word, opposite purpose.

And none of this is a hobby. My homelab is a sandbox, but the requirements come from real client work, like the client who needs their sensitive stream routed to a local, governed model and everything else sent to a cheaper cloud one. I would rather have worked that out before the question lands. Once I know what's safe and what holds up, the pieces move into real work: the way of working, the agents, the review gates, and the parachute are all in a real project now.

The trade-offs, honestly

The local tier is genuinely degraded: a quantized 35B keeps you moving through a limit window, it doesn't replace Opus. AFP is single-process by design, which keeps the machine alive but doesn't scale sideways without rethinking where the shared state lives. And you are now running infrastructure.

There's even a small absurdity to it. When the proxy itself needs a fix, I can't always fix it from inside. If Claude tries to repair AFP while its own traffic is routed through AFP, it kicks itself out mid-change. So I keep a plain session, outside the proxy, just to repair the proxy and let us back in. I still watch every terminal when the multi-agent setup is live, because I haven't trusted it enough to let it run free.

So should you build one?

I have mixed feelings about this one. I spent a big chunk of six months on what was supposed to be a quick win, so here's my honest answer: mostly, no. For most people, the harness Claude Code ships out of the box, and the new functionality the big labs push out almost every week, is plenty. If you run to an SLA and have to maintain what you ship, rolling your own is a bad trade; it's more convenient to buy it. If you're a builder, or looking to move up in tech, maybe even change careers into it, it's still worth learning the concepts, you don't necessarily have to build the infrastructure yourself.

And if you do build: know the bill. Every hour I spent on the harness was an hour not spent on the project that needed it. It isn't free, and it isn't always the right call, so choose your battles. But when you have the time to spend, it compounds.

We've seen this movie. First only the big labs had a decent model; then open source caught up fast; now there are many, and the question stops being "whose model" and becomes "how useful is it, what can it do for my case?" Increasingly, a specific harness is what answers that, which is why the big labs are racing to build their own.

One core, many shells. Different jobs call for different rigs; you choose the harness the work needs, and the intelligence inside stays the same.

The model is becoming a commodity. The harness, the part you build, govern, and keep on your own terms, is the part that is actually yours. Take Claude Design: none of Anthropic's models generate images on their own, the harness is what gives them the reach to act like one. If you want that same reach for your own tools, it's worth building on purpose.