Orchestration is exhausting

The shift from single agents to multiple agents working in parallel is already here. Many engineers have figured it out and they’re more productive because of it.

What you only discover later is the fatigue. A senior engineer last week described it as “running four projects at the same time and context-switching between them every minute.” That’s not a tooling problem. It’s what coordinating parallel agents actually feels like in practice.

The next thing we’ll learn, I think, is how to tell an agent when it’s done. Not just “the tests pass” but “the work matches what was asked, the verification ran, the guardrails held, stop.” Right now most of us are doing that verification ourselves. The whole process becomes less stressful when the agent learns to continue until it can verify and close it too.

Enable the company, or lose the people

This is the one I was too optimistic on. I expected the bottleneck to be vendor selection. It’s not. The bottleneck is that most enterprise AI tools aren’t enterprise ready, and the gap between what your people can do with AI at home and what IT will let them do at work is widening every week.

That’s the talent risk nobody’s putting on slides. The best people aren’t waiting for IT to catch up. They’re updating their CVs and asking whether the next company has figured this out yet. The window for closing the gap safely is shorter than most CTOs think.

What is different in six months

The AI technology moved as fast as I expected but the enterprise tooling and the organisation moved slower, and the gap between the two is where the actual challenge is now. None of the three bets are wrong. They’re just harder, slower, and more dependent on each other than the December version of me was willing to admit.

I’m starting to think we got it backwards.

The customisation is encoding yesterday’s model

Every skill, every prompt, every workaround, every behavioural rule encodes an assumption about a limitation in a specific generation of AI. We find a weakness, build a process around it, and congratulate ourselves for making the agent more reliable. Then six months later the model no longer has that weakness, and our harness is still forcing yesterday’s behaviour.

A concrete example from my own setup: I had a custom skill that told the model to “always run npm test before claiming a fix worked.” It was good advice for an older model that would confidently hallucinate green checkmarks. Newer models actually run the tests themselves, read the output, and fix the real failure. The skill now just slows things down, because every prompt pays for a rule the model has internalised.

The effort does not seem worth it

The uncomfortable fact is that a lot of carefully crafted harnesses are turning into a new form of technical debt. Not because they’re wrong, but because the model improves faster than the configuration does.

Every layer of instruction the model has to read is tokens paid before it does any real work. A prompt that says “be careful, double-check, never do X” is teaching the model the wrong thing if X stopped being a problem six months ago — you’ve capped its ceiling. And you’re now maintaining a system whose capabilities double every few months, which no software framework has ever evolved at this pace.

CTOs and engineering leads have never had to manage assets that age out faster than they can be documented.

Treat the harness like code, not furniture

The shape of the fix is the same shape as the fix for any kind of accumulation:

• Delete by default. If a skill, prompt, or rule can’t justify itself in the current model, it goes. No “but it was useful in March.”
• Retest on every model upgrade. When you swap models, you re-evaluate the whole configuration, not just the bits that broke.
• Treat every customisation as having an expiration date. When you add something, write down what it’s compensating for. When the compensation is no longer needed, the customisation follows.

The emerging question is whether the optimal harness is the most sophisticated one, or the thinnest one that still does the job.

The risk

The biggest risk in this space right now might be believing that your six-month-old AI setup is still helping. It might be the thing holding you back — a set of guardrails for a model that’s already grown past them, paid for in tokens and capped behaviour on every run.

The fix isn’t more cleverness in the harness. It’s treating customisations like code with an expiration date: delete what the model no longer needs, retest what you keep, and assume the rest will follow.

That’s the post. The rest is how I got there.

What landed

Chrome 13.2 put the code in on 1 May. 13.3 turned it on by default six days later. PageSpeed Insights now shows a fifth card next to Performance, Accessibility, Best Practices and SEO. Six audits in the new category: WebMCP tool registration, agent-centric accessibility (axe rules in a fresh hat), CLS, and llms.txt. Two of those audits — CLS and the accessibility rules — already existed under different names. WebMCP and llms.txt are new.

The scoring is a fraction, not a 0–100 number. You see something like 3/4, which looks meaningful until you read the code that produces it.

How the score is actually built

calculateCategoryFraction() skips anything marked notApplicable, manual or informative before it counts. Not enrolled in the WebMCP origin trial? Those three audits get skipped, and you’re scored out of 3, not out of 6. The number changes based on which experimental flags are flipped on. That’s not a property of the category — it’s a property of how the audit was bolted together.

Then there’s the llms.txt audit itself. No file at /llms.txt returns 404, which Lighthouse marks as Not Applicable, and your score doesn’t move. A malformed file fails. llms-txt.js wants an H1, at least one real Markdown link, and 50 characters of content. A tidy plain-text list of URLs fails. Twenty guides out there explain how to hit 3/3. The denominator isn’t 3, and anyone who wrote those guides didn’t open the source.

What crawlers are actually doing

Agents are showing up. HUMAN put browser-based agents at roughly 71% of agent traffic in April, with SaaS growing 41.5% month over month. Real number, real direction.

Not for this stuff. Seekio watched ~900 domains for 191 days and logged 1,227 requests for llms.txt against 44,996,657 AI-bot requests in the same window. None came from GPTBot, ClaudeBot, PerplexityBot or Google-Extended. Ahrefs found 97% of llms.txt files across 137,210 domains were never fetched at all. SE Ranking modeled 300,000 domains and their AI-citation predictions got better when they deleted the feature.

WebMCP is starker. A scan of 111,076 of the top 200,000 sites found zero implementations. No mainstream agent calls modelContext yet. They all still parse the DOM.

Two of the new audits (CLS, accessibility) are things you should be doing anyway. The other two — WebMCP and llms.txt — audit for the file nobody requests and the API nobody calls.

The caveats

This can flip. Google says Gemini in Chrome will be the first consumer of WebMCP tools, and the origin trial runs through Chrome 156, so registering tools today is a cheap forward bet. Buys you nothing now, isn’t stupid.

The category is experimental, doesn’t touch your other scores, isn’t a ranking factor. Issue #17082 has PageSpeed Insights running Chrome 146 against docs that require 150, open since June. Take the number accordingly.

What to do

Fix the CLS. Fix the accessibility tree. If you publish an llms.txt, write it with real Markdown links — because a broken one costs you a point an absent one doesn’t. Then move on to the parts of your site that real agents are actually hitting today.

Links:

• Lighthouse agentic browsing audits (source)
• core/audits/agentic/llms-txt.js
• Google’s AI features guide
• AI bots ignore llms.txt — Seekio
• llms.txt study — Ahrefs
• llms.txt and AI citations — SE Ranking
• A Developer’s Guide to WebMCP — freeCodeCamp
• State of Agentic Traffic, April 2026 — HUMAN
• Google Lighthouse Has A New Agentic Browsing Category — DebugBear

My first reaction wasn’t shock. It was: hang on, I already built most of that.

The non-evil version was already running here

Every post here has a raw-markdown twin published next to the HTML — the header image of this post is the twin of my wasm-not-docker post, exactly as ClaudeBot receives it. Add llms.txt, a <link rel="alternate" type="text/markdown"> on every post, and a robots.txt that welcomes the AI crawlers instead of fighting them. A Jekyll plugin generates it all at build time.

But TIME’s experiment exposed my one gap: discovery. My twins lived at .md URLs a bot had to know about. Most crawlers just fetch the canonical URL and take what comes back. The negotiation has to happen at the canonical URL. Fifteen lines of Apache fix it:

RewriteCond %{HTTP_USER_AGENT} (GPTBot|OAI-SearchBot|ClaudeBot|PerplexityBot|CCBot|Amazonbot|...) [NC]
RewriteCond %{DOCUMENT_ROOT}/$1.md -f
RewriteRule ^(.+)\.html$ /$1.md [L]

Known AI crawlers now get the twin at the article’s normal URL, as text/markdown, at about a fifth of the size. Humans, Googlebot, and Bingbot get the identical HTML they always got — same split TIME uses, so it’s not cloaking — plus a Link: rel="alternate" header, with Vary: User-Agent so caches key correctly.

Why bother?

Because AI answers are becoming a distribution channel, and this is how you optimize for it. A model reading my page now spends its context window on my actual words instead of burning four-fifths of it on navigation and markup — which means more of the article survives into whatever ChatGPT, Claude, or Perplexity tells the person who asked. Cleaner input, better odds of being quoted correctly and cited as the source. That’s SEO for the agent era, and it costs me a fifth of the bandwidth per crawl.

What I’m not copying

The ad half. no-store plus per-request impression UUIDs exists only to make every bot fetch a billable event, and sponsor copy phrased as chatbot answers — injected where no human editor will ever see it — is a trust problem wearing a disclosure label. TIME is probably right that when most of your readers are models, someone will sell that audience. I’d rather my machine readers get the same deal my human readers get: the actual content, nothing else.

The forked web is coming either way. The only decision left is whether the version you serve the machines is your content — or somebody’s ad inventory.

The entire “server” is about 80 lines of Rust, compiled to wasm. Gzipped, the binary is 145 KB. It handles everything my Apache .htaccess used to do: the canonical-host 301 redirect, six security headers on every response, DirectoryIndex resolution, trailing-slash redirects, and the 404 page. The images and CSS never touch the wasm at all — Cloudflare’s static assets binding serves them straight from the CDN, free and unlimited.

I went in expecting a fun toy. I came out convinced this is how I want to deploy a whole class of services. Five reasons.

1. The artifact is absurdly small

The deployable unit is 145 KB gzipped — smaller than most header images on this blog. A Docker image shipping the same routing logic drags along a base image, a distro, and a web server: tens to hundreds of megabytes that aren’t your code. A wasm module is just compiled logic against a standard runtime interface; the runtime is the platform’s problem.

2. You test the exact artifact you ship

wrangler dev runs the same workerd runtime locally that Cloudflare runs at the edge — same wasm binary, same bindings, up in milliseconds. My acceptance script (twelve curl checks: header parity, byte-identical HTML, redirect status codes) runs unchanged against localhost and the deployed URL. No image build, no registry round-trip, no environment drift.

3. The CDN does the heavy lifting — for free

The 10 MB worker limit forces the right architecture anyway: logic in the binary, bytes on the CDN. This blog’s ~74 MB of images, CSS, and fonts are served by Cloudflare’s static assets binding — edge-cached, zero egress fees, not counted against the worker’s request quota. The wasm only wakes up for redirects, headers, and 404s.

4. The economics are embarrassing

$0 per month: 100,000 worker requests/day free, static assets unlimited, no bandwidth charges; $5/month past that. And because wasm instantiates in milliseconds, scale-to-zero has no cold-start penalty — the problem you engineer around with containers doesn’t exist here.

5. It’s real server logic, not a static-hosting hack

The worker does what Apache did via mod_rewrite and mod_headers — canonical 301s, security headers, 404s — in 80 lines of typed, testable Rust instead of .htaccess regex. The same shape carries a real backend: routing, auth, database and upstream calls in one small binary. And with WASI it isn’t vendor-locked — the same module runs on wasmtime, Fastly, or Spin.

The honest caveats

It wasn’t friction-free, and I’d rather you hit these in this paragraph than at midnight:

• Toolchain sharp edges. worker-build silently requires a recent worker crate version; enabling LTO in the release profile broke wasm-bindgen with a cryptic “externref table” error. Both fixable in minutes once diagnosed, both annoying to diagnose.
• Platform defaults fight parity. Cloudflare’s default URL handling 307-redirects .html URLs to extensionless ones — nice for a new site, wrong when you need byte-parity with an existing Apache setup. One config line (html_handling = "none") and a few lines of Rust fixed it.
• The 10 MB limit is real. Wasm-on-Workers is for logic, not payloads. If your service is mostly moving large files, this isn’t your architecture.

Takeaway

A container ships a machine; a wasm module ships a function. For services whose job is logic rather than bulk data — redirects today, APIs tomorrow — the wasm version is orders of magnitude smaller, tests as the identical artifact you deploy, starts in milliseconds, and rides a free CDN for everything heavy.

The blog was the toy problem. Over the next weeks I want to push actual backend logic through this pipeline — a real service with state and upstream calls — and see where the model bends. If it holds, I struggle to justify a Dockerfile for small services again.

Then I installed Hallmark as a Claude Code skill and told it to redesign my blog and homepage. What came out was so much better it made the old version look embarrassing.

Here’s how it actually went.

It asked before it assumed

The first thing Hallmark did wasn’t generate anything. It asked about scope: just the blog, or everything? That one question already put it ahead of the usual “here’s 12 layouts, pick one” slot-machine approach. It wanted to know what it was working on before it started working.

Then it went quiet and analyzed. Not for show—when it came back, it came back with four distinct design directions. Not four variations of the same idea. Four genuinely different takes, each with a rationale.

I picked a direction, then it offered variations

Once I chose a direction, it didn’t just run. It surfaced a second round of decisions—variations within that direction, including whether I wanted dark mode. Small thing, but it’s the difference between a tool that designs for you and one that designs with you. I got to steer twice: once on the big direction, once on the details.

Then it worked. For 40+ minutes.

This is the part that sold me.

Hallmark didn’t spit out HTML and call it done. It drove a headless browser, took screenshots, and checked its own work—desktop and mobile, because I’d asked for both. It iterated. Rendered, looked, adjusted, rendered again. For over forty minutes it did the loop that I always skip when I’m rushing: actually looking at the thing on a real screen at real breakpoints and fixing what’s off.

That’s not prompt-and-pray design generation. That’s the workflow a careful front-end engineer follows—verify against the running page, not the mental model of it.

The result

Here’s the honest comparison. First, the old design—hand-wired from Google Stitch and Claude Design:

And here’s what Hallmark produced:

Compare the two—there’s no contest. Hallmark’s version is tighter, more coherent, and it just feels considered in a way the old one never did.

Takeaway

If you’re building a web page or want a redesign, go look at the Hallmark skills. The magic isn’t that it generates designs—everything generates designs now. It’s that it interrogates scope first, gives you real choices instead of noise, and then verifies its own work in a real browser until it’s right.

For someone who isn’t a designer, that’s the whole game. It doesn’t just hand me pixels. It does the part I’d skip.

That sounded great. Pi isn’t a sealed product — if you need a command, a tool, a provider, a workflow, or a UI tweak, you just ask Pi to build it, and it customizes itself on the fly. It ships powerful defaults but deliberately skips things like sub-agents and plan mode, on the theory that you’ll add them if you actually want them. Customizations bundle as Pi packages and ship over npm or git.

The catch: I wasn’t sure I was ready to build up all that judgment myself, skill by skill. A blank harness is only as good as what you teach it. Then I remembered agent-skills — the 77k-star pack of engineering process from Addy Osmani, a senior engineering leader at Google — that I’d already been testing inside Claude Code. Someone had ported it to Pi. So the test wrote itself: take the bare harness, drop in those skills, point it at a model, and see how far it gets.

The setup

Three moving parts.

The harness: Pi, out of the box, minimal.

The brain: @chankov/agent-skills, a Pi port of Addy Osmani’s agent-skills. The original bills itself as “production-grade engineering skills for AI coding agents,” and it’s cleared 77k stars on GitHub — Osmani is a senior engineering leader on Google Chrome, so this isn’t hobby advice. The skills are organized by phase: idea → spec → plan → implement → test → review → ship. Each one encodes the process a good engineer actually follows instead of just “write the code.”

install pi.dev/packages/@chankov/agent-skills

The model: I connected Pi to my OpenCode Go subscription and ran everything on kimi-k2.7-code at medium effort.

The test: spec, then build

My prompt was specific: a playable snake game in the terminal, styled to look like The Matrix — green digital rain falling behind the board. Not “write snake” — I let the skills drive. It ran the spec skill first, asked me a few clarifying questions the way Claude Code does, and only then started writing code. That ordering matters. The spec-first workflow is exactly what stops a model from confidently building the wrong thing.

The output was clean Python: a pure game-logic core with no curses imports, a separate renderer for terminal I/O, an input handler, and the Matrix rain effect cascading behind the play area. The interesting part was what happened when I asked it to grade its own work.

Running /review

I ran the installed /review skill on the finished game. What came back wasn’t a rubber stamp — a genuine five-axis review (correctness, readability, architecture, security, performance) that caught the things a good reviewer would: a spot where the renderer was quietly mutating game state, a bloated main() worth splitting, an unhandled edge case nobody asked about, and a correct nothing critical on security instead of invented risk.

That’s the tell. A weak reviewer pads the list. This one separated what’s good from what to fix, ranked it, and knew when to stop. Reading it back, I couldn’t tell it apart from a review I’d get out of Claude Code or any of the other agent harnesses I run day to day.

One note: it just runs

The skills asked me clarifying questions like Claude Code — but they never stopped to ask permission before acting. Pi read files, wrote code, and ran the review on its own. Honestly, I liked it: no clicking “yes” on every step, it just moved.

The clean way to get that speed is to run Pi in a container. Sandbox the workspace, let it go, and autonomy stops being something to worry about — a mistake can’t reach anything outside the box.

Takeaway

A minimalist harness plus a best-practice skills package added up to something that specced deliberately, built cleanly, and produced code and reviews I couldn’t distinguish from what Claude Code or any other harness I already use hands me. The harness stayed out of the way; the skills supplied the judgment.

If you’ve been curious about Pi, this is the fast way in: install @chankov/agent-skills, point it at a model, and ask it to review something you wrote. Then decide who the senior engineer in the room actually is.

So I decided to fix it in one sitting—and I used Fable 5 running inside Claude Code to do the heavy lifting, pointed at the specification checklist over at https://specification.website. Here’s the exact workflow, and why I did it now instead of later.

The setup: point an agent at a spec

There’s a site at https://specification.website—”What a good website does.” It’s a checklist of what a well-built site should ship: Foundations, SEO, Accessibility, Security, Well-Known URIs, Agent Readiness, Performance, Privacy, Resilience, Internationalisation. Each topic is tagged Required or Recommended, from the boring-but-essential (<!doctype html>, <meta charset>, a real <title>) to the modern stuff (canonical URLs, theme-color, agent-readable metadata).

My instruction to the agent was deliberately simple:

Analyze my website against https://specification.website. Find everything I’m missing—required and recommended. Make a plan. Then fix it all.

That’s it. No hand-holding. I wanted to see how far an agent could get when the “spec” is an external source of truth instead of a vague “make my site better.”

It planned first, then let me decide

It didn’t just start editing files. It checked my pages against the spec and came back with a plan—a grouped list of what was missing across Foundations, SEO, Agent Readiness, Performance, and the rest. Standard agent behaviour; you’ve seen it.

The part that mattered was what came next.

I made a few decisions, then let it run

An agent shouldn’t get to decide everything. A handful of items needed a human call—things like which canonical form to standardize on, what to put in the metadata that’s genuinely mine, and how far to go on the recommended-but-optional items.

So I answered those few questions, and then it did the work: updated the files, wired in the missing pieces, and—this is the part people skip—tested it. It didn’t just claim the fixes were done. It verified the build and checked the changes held together before calling it finished.

Plan → decide → fix → verify. That loop is the whole game.

Why I did this now

Here’s the honest reason for the timing: this is a fantastic use of Fable 5 while it’s still cheap.

Right now, having an agent audit a whole site and ship the fixes fits inside a normal Claude subscription. That won’t last—these capabilities get more expensive as they get more valuable.

So do the one-off, high-leverage cleanup while it’s cheap. You only do it once per site, and the payoff lasts every time a crawler, search engine, or AI agent reads the site correctly from now on.

Takeaway

You don’t need to be an expert on any spec to hold your app or blog to one. Point a capable agent at a good external standard, make it plan before it edits, keep the few decisions that are actually yours, and demand it verify its own work. It applies to any codebase, not just an old one.

I did it in one sitting. And I did it now, on purpose—because getting an agent to bring something up to a standard is cheap today, and that’s exactly when you should spend it.

That split is the whole opportunity. The reasoning is where you want a strong model. The grunt work is where you want fast and cheap. There’s no rule that says both have to come from the same vendor — or from Anthropic at all.

So I put a LiteLLM proxy in the middle. The planning tier routes to a fast GLM 5.2 on Baseten. The coding, background, and subagent tiers route to cheap budget models on OpenCode Go. Claude Code stays completely stock — it thinks it’s talking to Anthropic, sends normal Anthropic requests, and LiteLLM translates each one to whatever backend I mapped that tier to.

This is a writeup of an actual setup — real config shape and ports, placeholder secrets. Substitute your own keys and model ids; provider catalogs change often, so don’t copy the model strings blind.

Why this shape

• One proxy, many backends. Claude Code only knows how to talk to a single Anthropic-shaped endpoint. LiteLLM fronts that endpoint and fans out per tier.
• Cheapest capable model per tier. Heavy turns go to GLM 5.2. Background and quick turns go to a cheap, fast model. You pay for thinking where you need it and almost nothing where you don’t.
• Claude Code stays stock. No patches, no forks, no flags. Point two env vars at the proxy and you’re done.

1. Install LiteLLM

Use a venv so the proxy is isolated. uv is fast; plain python -m venv works too.

uv venv .venv
uv pip install --python .venv 'litellm[proxy]'

The [proxy] extra pulls in the proxy server (the litellm --config … mode). Without it you only get the Python library.

Security — pin your version. LiteLLM’s PyPI releases 1.82.7 and 1.82.8 shipped credential-stealing malware. Pin away from those two. This setup uses 1.90.0. Do not downgrade into the bad pair.

2. Drop your keys in .env

The launcher sources .env, so provider keys live there:

BASETEN_API_KEY=baseten-XXXXXXXX
OPENCODE_API_KEY=opencode-XXXXXXXX      # works for both Zen and Go plans
LITELLM_MASTER_KEY=sk-litellm-local     # the proxy's OWN auth (not a provider key)

# Critical for OpenCode Go — see the gotchas section.
LITELLM_USE_CHAT_COMPLETIONS_URL_FOR_ANTHROPIC_MESSAGES=True

LITELLM_MASTER_KEY is how the proxy authenticates you. Claude Code sends it as ANTHROPIC_AUTH_TOKEN, and the two values have to match (default sk-litellm-local). That last env var isn’t optional if you use OpenCode Go — skip ahead to the gotchas if you want to know why before you trust it.

3. Write the routing config — this is the whole idea

litellm.config.yaml is a list of model_name → backend mappings. The model_name is the tier Claude Code asks for; litellm_params.model is the real backend, prefixed with the provider so LiteLLM knows how to talk to it (baseten/… for Baseten, openai/… for any OpenAI-compatible endpoint).

This is where the brain/hands split lives:

model_list:
  # THINKING TIER → fast GLM 5.2 on Baseten. This is the model that plans.
  - model_name: claude-opus-4-8
    litellm_params:
      model: baseten/zai-org/GLM-5.2
      api_key: os.environ/BASETEN_API_KEY

  # MID TIER → OpenCode Zen (OpenAI-compatible)
  - model_name: claude-sonnet-4-6
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://opencode.ai/zen/v1
      api_key: os.environ/OPENCODE_API_KEY

  # FAST / BACKGROUND TIER → OpenCode Go (OpenAI-compatible, cheap)
  - model_name: claude-haiku-4-5
    litellm_params:
      model: openai/kimi-k2.7-code
      api_base: https://opencode.ai/zen/go/v1
      api_key: os.environ/OPENCODE_API_KEY

  # SUBAGENTS (Claude Code's Task tool) → cheap model on Go.
  # Claude Code sends CLAUDE_CODE_SUBAGENT_MODEL's value as `model`; map it here.
  - model_name: subagent
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://opencode.ai/zen/go/v1
      api_key: os.environ/OPENCODE_API_KEY

litellm_settings:
  drop_params: true   # silently drop Anthropic params the OpenAI backends reject

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

A few things that bite people:

• drop_params: true matters because Claude Code sends Anthropic-only params the OpenAI backends will reject. This strips them silently.
• The openai/ / baseten/ prefix on model: is not optional. LiteLLM reads the provider from that prefix. Leave it off and you get LLM Provider NOT provided at startup — and the deployment is silently skipped, so every later request for that tier 404s with “no healthy deployments.”
• The separate subagent entry exists because Claude Code’s Task tool sends CLAUDE_CODE_SUBAGENT_MODEL’s value verbatim as the model field. Point that env var at the literal string subagent (step 5) and the proxy routes every subagent wherever you want — here, a cheap model on Go.

Want it even cheaper? Make a second config — litellm.config.go.yaml — where every tier goes through OpenCode Go (no Baseten, no Zen), using Go-catalog model ids. Run it on a different port (e.g. 30181) so it sits alongside the main proxy. Now you can flip between “GLM 5.2 brain” and “all-cheap” with a single alias.

4. Start the proxy

A tiny launcher that loads keys and runs the proxy:

#!/usr/bin/env bash
set -euo pipefail
cd "$(dirname "$0")"
set -a; source .env; set +a
exec .venv/bin/litellm --config litellm.config.yaml --port 30180

Save it as start-proxy.sh, chmod +x, run it, leave it running:

./start-proxy.sh   # listens on http://localhost:30180

The set -a; source .env; set +a dance exports every var from .env so the proxy actually sees the keys, then flips export back off to keep your shell clean.

Startup prints register_model: … not in built-in cost map warnings for your custom model strings. Harmless — LiteLLM just has no pricing table for them, so its cost tracking shows 0.

5. Point Claude Code at the proxy

Two ways in. The first is file-driven and tied to the repo dir; the second works from anywhere.

Settings file — .claude/settings.json, read once at startup:

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:30180",
    "ANTHROPIC_AUTH_TOKEN": "sk-litellm-local",
    "ANTHROPIC_MODEL": "claude-opus-4-8",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-6",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-haiku-4-5",
    "CLAUDE_CODE_SUBAGENT_MODEL": "subagent"
  }
}

Then cd into the repo and run claude. Restart Claude after editing this file. Those ANTHROPIC_DEFAULT_* vars pin each Claude Code tier to a model_name the proxy actually knows, so the /model picker always lands on something routable. Skip them and you risk sending an id the proxy can’t map.

Inline env — works from any directory, overrides settings.json for that one run:

ANTHROPIC_BASE_URL=http://localhost:30180 \
ANTHROPIC_AUTH_TOKEN=sk-litellm-local \
ANTHROPIC_MODEL=claude-opus-4-8 \
ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-4-6 \
ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5 \
CLAUDE_CODE_SUBAGENT_MODEL=subagent \
claude

For something repeatable, alias it in ~/.zshrc:

alias ccgo='ANTHROPIC_BASE_URL=http://localhost:30181 ANTHROPIC_AUTH_TOKEN=sk-litellm-local ANTHROPIC_MODEL=claude-opus-4-8 ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-4-6 ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5 CLAUDE_CODE_SUBAGENT_MODEL=subagent claude'

(Swap the port to 30180 for the Zen/Baseten proxy, 30181 for the all-Go one.)

6. Verify it works

With the proxy running, hit it directly with an Anthropic-shaped request:

.venv/bin/python - <<'PY'
import json, urllib.request
body = json.dumps({"model": "claude-opus-4-8", "max_tokens": 16,
    "messages": [{"role": "user", "content": "reply with OK"}]}).encode()
req = urllib.request.Request("http://localhost:30180/v1/messages", data=body,
    headers={"x-api-key": "sk-litellm-local", "anthropic-version": "2023-06-01",
             "content-type": "application/json"})
print(urllib.request.urlopen(req, timeout=30).read().decode())
PY

Expect a 200 with an Anthropic-shaped content block. Swap the model for claude-sonnet-4-6, claude-haiku-4-5, or subagent to prove each tier independently.

Using the split in practice

Once it’s wired up, the brain/hands split isn’t just a config diagram — it changes how a session feels.

The heavy reasoning rides on GLM 5.2. That’s the Opus tier, which is what Claude Code leans on when it’s actually thinking — working through Plan mode, holding the shape of a change in its head, deciding what to do. The cheap models carry the volume: the Haiku tier’s background chores and every subagent your Task tool fans out. You’re paying for a strong reasoner on the turns that need one and pennies on the turns that don’t.

If you want to be deliberate about it, lean into the tiers: draft the approach in Plan mode on the Opus/GLM tier, then /model down to a cheaper tier to grind out the execution. Plan with the smart model, code with the cheap one. That’s the whole pitch, and now it’s a config file instead of a vendor lock-in.

Gotchas (the painful ones)

OpenCode Go 404s on /v1/responses. Every request to a Go-backed tier logs Client error '404 Not Found' for url 'https://opencode.ai/zen/go/v1/responses', then cascades into 429 No deployments available as the failing deployment goes into cooldown. The cause: LiteLLM’s Anthropic pass-through converts /v1/messages into an OpenAI Responses API call (/v1/responses). Zen implements that endpoint; Go does not — only chat/completions and messages. The fix is the env var from step 2:

LITELLM_USE_CHAT_COMPLETIONS_URL_FOR_ANTHROPIC_MESSAGES=True

It’s global but only touches the Anthropic→OpenAI path, so Zen and Baseten keep working. The tell: when you see a 404 … /v1/<endpoint> against a provider, you’re calling an API surface that provider doesn’t implement — reach for the chat-completions toggle before anything else.

Catalog drift. You’ll hit ModelError: Model <x> is not supported or There are no healthy deployments for this model because provider catalogs change often and they are not symmetric between plans. OpenCode Zen’s model list is different from Go’s, and an id that looks plausibly newer can still be the wrong plan. Check the live catalog and copy the exact id:

# Zen
curl -s https://opencode.ai/zen/v1/models -H "Authorization: Bearer $OPENCODE_API_KEY"
# Go
curl -s https://opencode.ai/zen/go/v1/models -H "Authorization: Bearer $OPENCODE_API_KEY"

Match the id field exactly in your model: line (after the openai/ prefix, or baseten/… for Baseten). A 403 instead of a model error means a backend key is wrong, not the model string.

TL;DR

uv venv .venv && uv pip install --python .venv 'litellm[proxy]'   # 1. install (avoid 1.82.7/1.82.8)
# 2. put BASETEN_API_KEY / OPENCODE_API_KEY / LITELLM_MASTER_KEY +
#    LITELLM_USE_CHAT_COMPLETIONS_URL_FOR_ANTHROPIC_MESSAGES=True in .env
# 3. write litellm.config.yaml: thinking tier → baseten/zai-org/GLM-5.2, rest → openai/… on OpenCode
./start-proxy.sh                                                   # 4. start it (port 30180)
ANTHROPIC_BASE_URL=http://localhost:30180 ANTHROPIC_AUTH_TOKEN=sk-litellm-local claude   # 5. use it

Claude Code never knows the difference. You just stopped paying Opus prices for grunt work.

There are two ways to do that. The first takes thirty seconds and works with a subset of the models. The second installs a small proxy and unlocks the whole catalog with stable per-model routing. Here’s both.

Way 1: Environment variables only

Claude Code speaks the Anthropic Messages API. OpenCode Go exposes some of its models through an Anthropic-compatible endpoint, so for those models you don’t need anything in the middle — you just tell Claude Code’s Anthropic client to call OpenCode Go instead of Anthropic. That’s a handful of environment variables:

export ANTHROPIC_DEFAULT_OPUS_MODEL=minimax-m3
export ANTHROPIC_DEFAULT_SONNET_MODEL=minimax-m3
export ANTHROPIC_DEFAULT_HAIKU_MODEL=minimax-m3
export CLAUDE_CODE_SUBAGENT_MODEL=minimax-m3
export ANTHROPIC_BASE_URL="https://opencode.ai/zen/go/"
export ANTHROPIC_AUTH_TOKEN=""
export ANTHROPIC_API_KEY="$OPENCODE_API_KEY"

Set those, start claude, and every Opus/Sonnet/Haiku slot — plus subagents — resolves to the OpenCode Go model you named.

The one limitation: this only works with models that ship an Anthropic-compatible interface. On OpenCode Go’s model list those are the ones with @ai-sdk/anthropic in the AI SDK column — at the moment, the MiniMax and Qwen families (minimax-m3, qwen-3.7-plus, qwen-3.7-max). Anything else needs a translation layer, which is exactly what the second method gives you. (Credit to kkovacs.eu for documenting this approach.)

Way 2: The ocgo proxy (all models, with mapping)

ocgo is a small Go CLI that runs a local compatibility proxy. It translates Claude Code’s Anthropic Messages API requests into OpenAI-style chat completions on the way out, so any OpenCode Go model works — not just the Anthropic-compatible ones — and it remembers a per-model mapping so you don’t reconfigure every session.

Install it and save your key:

brew install emanuelcasco/tap/ocgo
ocgo setup   # paste your OpenCode Go API key when prompted

Now map each Claude model name to the OpenCode Go model you actually want behind it. Three commands — one per tier:

ocgo mapping claude set claude-opus-4-8 glm-5.2
ocgo mapping claude set claude-sonnet-4-6 deepseek-v4-flash
ocgo mapping claude set claude-haiku-4-5 kimi-k2.7-code

Then launch Claude Code through the proxy:

ocgo launch claude

Under the hood, ocgo launch claude exports ANTHROPIC_BASE_URL=http://127.0.0.1:3456 and ANTHROPIC_AUTH_TOKEN=unused, then routes each Claude model name to its mapped OpenCode Go model — Opus requests go to GLM, Sonnet to DeepSeek, Haiku to Kimi — while the proxy injects your real OpenCode Go key upstream. Unmapped names pass through unchanged.

The proof is in the model picker. Ask the running session what it is and it tells you straight:

Model: kimi-k2.7-code. Claude Code session, but not running a Claude model.

That’s the Claude Code harness, your $10 subscription, and a Kimi model answering the prompt.

Which one to use

Way 1 is zero-install but limited to the Anthropic-compatible models. Way 2 is one brew install and a proxy process, but it opens the entire OpenCode Go catalog and lets you pin a different model to each tier and keep it there. Either way, you keep the harness you like and swap out the expensive backend for a ten-dollar one.

And honestly — if you can get good work done on the cheap models, you’ll have no trouble at all when you do reach for the expensive ones.