On Friday, April 3, 2026, Boris Cherny — Anthropic's Head of Claude Code — posted on X: "Starting tomorrow at 12pm PT, Claude subscriptions will no longer cover usage on third-party tools like OpenClaw." The next day at noon Pacific, the billing cutover landed. OpenClaw, OpenCode, Cursor, Manus, and Pi — the major third-party Claude Code harnesses — stopped being a cheap way to run autonomous Claude agents on a flat subscription. Their users were pushed onto metered "extra usage" rates on top of their subscription, or invited to cancel and take a refund. An Anthropic spokesperson told The Register: "Starting April 4, third-party tools will draw from extra usage instead of subscription limits. Capacity is something we manage thoughtfully, and we need to prioritize customers using our core products."
This wasn't the first move. Anthropic had been walking this back in stages. On January 9, 2026, server-side checks first started rejecting Claude subscription OAuth tokens outside Claude Code with the error "This credential is only authorized for use with Claude Code and cannot be used for other API requests." OpenClaw's maintainer shipped a patch within hours and closed the issue the same day. The patch held for a while. Then on February 20, Anthropic engineer Thariq Shihipar said on the record: "Third-party harnesses using Claude subscriptions create problems for users and are prohibited by our Terms of Service. They generate unusual traffic patterns without any of the usual telemetry..." The Register reported that the underlying prohibition had been in the Consumer Terms since at least February 2024. Anthropic had the language for two years and hadn't enforced it. Then they enforced it.
Somewhere in the middle — on March 19, 2026, to be exact — opencode's maintainer Dax Raad opened PR #18186. The title was "anthropic legal requests." He merged it himself, nineteen minutes after opening it. The diff removed the file that mattered most: packages/opencode/src/session/prompt/anthropic-20250930.txt, 166 lines — a verbatim copy of Claude Code's official system prompt, with Dax's own working directory still baked into the environment block (cwd: /home/thdxr/dev/projects/anomalyco/opencode/packages/opencode). The new docs page copy, added in the same diff, reads: "There are plugins that allow you to use your Claude Pro/Max models with OpenCode. Anthropic explicitly prohibits this." That merge was two weeks before the April 4 billing cutover. thdxr saw it coming and jumped first.
The line between a harness Anthropic won't kill and a harness Anthropic will kill is not written clearly in the legal pages. But two public signals tell you where it sits, and once you see them, the rules are not hard to follow. I've been building nanika on the safe side of that line, and I want to show you what I learned — some of it by design, some of it by luck.
What follows is five rules. They come from reading Anthropic's Consumer Terms, the Acceptable Use Policy, the Claude Agent SDK documentation, Simon Willison's writeup of Thariq Shihipar's public quotes, two Register articles covering the February clarification and the April billing cutover, Theo Browne's seventeen-minute video on the T3 Code launch, and the full diff of thdxr's surrender PR. I'll show the source for each one. None of them are numbered prohibitions in the AUP. That is the whole problem, and it's why you need to know where the line actually sits.
Rule 1: Don't use claude.ai credentials in your harness.
This is the only harness-specific prohibition Anthropic has written down in plain language, and it lives in the developer docs, not the legal pages.
From the Claude Agent SDK overview docs, Step 2 ("Set your API key"):
"Unless previously approved, Anthropic does not allow third party developers to offer claude.ai login or rate limits for their products, including agents built on the Claude Agent SDK. Please use the API key authentication methods described in this document instead."
Theo Browne reads this on camera in the T3 Code launch video. He reads it twice. He's clear about why: T3 Code sits on the right side of this line because it shells out to the user's locally installed claude CLI — whatever auth that CLI already has, T3 Code inherits. It never ships its own OAuth flow, never brokers tokens through its own client, never pretends to be Claude Code. OpenCode crossed the line because it did ship its own OAuth flow that brokered Claude Max tokens through its own client.
The Consumer Terms of Service back this up obliquely. Section 3 has the clause that gets cited in the ban notices:
"Except when you are accessing our Services via an Anthropic API Key or where we otherwise explicitly permit it, to access the Services through automated or non-human means, whether through a bot, script, or otherwise."
And section 2 adds the account-sharing restriction:
"You may not share your Account login information, Anthropic API key, or Account credentials with anyone else. You also may not make your Account available to anyone else."
A harness that pipes a Claude Pro or Claude Max token through its own client is, by the plain reading of Section 3, accessing the Services by "automated or non-human means" without an API key. That is the violation. The Agent SDK docs are the developer-facing version of the same rule. The February 20 Register clarification, quoting Shihipar directly, added a sharper gloss: "Using OAuth tokens obtained through Claude Free, Pro, or Max accounts in any other product, tool, or service — including the Agent SDK — is not permitted and constitutes a violation of the Consumer Terms of Service."
Nanika sits on the safe side by architecture, and the architecture is the same as T3 Code's. Every worker phase spawns the local claude CLI as a subprocess (claude -p with a prompt file). Whatever auth the user has configured for their claude install — subscription, API key, or Bedrock — nanika inherits it. Nanika doesn't implement an OAuth flow, doesn't store a token, doesn't know whether the underlying session is Pro or Max or API. It is a parent process that composes structured prompts, fans them out across specialist personas, and parses the CLI's output. The claude binary is the thing that talks to Anthropic, not nanika. That delegation is what keeps it on the right side of Rule 1, and it's the same delegation pattern Theo calls out as the reason T3 Code is safe.
Rule 2: Keep your cache hit rate above the survival floor.
This rule is not in any Anthropic legal document. It lives in public statements by Anthropic's own Claude Code engineering team.
From a Simon Willison post quoting Thariq Shihipar, an Anthropic member of technical staff on the Claude Code team:
"Long running agentic products like Claude Code are made feasible by prompt caching which allows us to reuse computation from previous roundtrips and significantly decrease latency and cost."
And:
"We build our entire harness around prompt caching... we run alerts on our prompt cache hit rate and declare SEVs if they're too low."
And Boris Cherny, head of Claude Code:
"Third party services are not optimized in this way, so it's really hard for us to do sustainably."
Read that carefully. Anthropic declares severity incidents — the kind of alerts you get paged for at 3 AM — when their own harness's cache hit rate drops. That is not a nice-to-have metric. It is the unit of margin that makes running an agentic product at a flat subscription rate economically possible at all. When the subscription economics broke — which they did, on April 4 — this is the lever they cited.
The economics are brutal. Fresh input tokens bill at the full rate. Cache writes bill at 125% of base. Cache reads bill at 10%. A session that reuses its context well can pay one-tenth the cost of a session that rebuilds from scratch. Shihipar's quote is the polite version of "if you can't hit our hit rate, we can't serve you sustainably, and we will find a reason to stop."
How high is high enough?
A writeup on frr.dev measured 95.5% cache-read share across a month of plain Claude Code usage — a single developer, no custom harness, normal interactive sessions — and over 99% inside individual long-running sessions. The Claude Code Camp post on prompt caching puts typical Claude Code hit rates in the 90–96% range. Multiple community posts treat 90% as the floor for a well-cached session, not the ceiling.
Nanika measures 94.17% cache-read share over the last seven days and 91.20% over the last thirty. That is honest. It is also below the plain-Claude-Code baseline. The shortfall is explained by the architecture: multi-mission orchestration spins up fresh worker sessions per phase, the five-minute prompt cache TTL doesn't bridge across missions, and every new mission pays some cache-creation cost before it starts harvesting reads.
94% is not a number to brag about. It's a number that tells me nanika is sitting just inside the fence. If Anthropic's internal SEV threshold sits anywhere in the 85–90 range, we have headroom. If it sits at 95+, we have homework. I don't know where the line actually is. Matt Pocock asked Thariq publicly, and per Theo's video a week later, Thariq had not answered. I suspect he won't. The vagueness is the enforcement mechanism.
Rule 3: Don't inject dead bytes into the hot path.
Rule 2 tells you what the target is. Rule 3 tells you how to actually move the number.
Prompt cache hit rate depends on the cache key staying stable across turns. Every dead byte in a hot-path prompt — every stale skill description, every verbose system instruction that changes when you regenerate anything — is a fragmentation risk. A byte that doesn't earn its keep on information grounds is a byte that can only hurt you on cache-stability grounds.
The way I found this out was through the caveman evaluation.
Caveman is a Claude Code plugin that pitches a roughly 65% output token reduction by making Claude reply in compressed "caveman-speak," plus a roughly 45% input token reduction by rewriting loaded context files into the same style. Someone thought it would fit nanika. I ran an evaluation mission on it.
The verdict was a narrow no — narrower than I realized at the time. Nanika's token shape is input-heavy, about 5:1, with a 94% cache-read share. Caveman's 45% input savings would apply to the ~6% of tokens that aren't already cache reads, which moves the dial by essentially nothing. That part of the call I still stand by. The output-compression half I waved off too quickly. Output tokens are never cached, they're always billed at the full rate, and for prose-heavy worker personas — technical-writer, architect, reviewer, data-analyst — they plausibly add up. A walkthrough of caveman's output side shows a concrete React-bug explanation going from 1,180 tokens to 159, and a March 2026 paper claims brevity constraints can lift response accuracy by as much as 26 percentage points on some LLM benchmarks. The output side is back on the post-Option-E test list as a stacked follow-up, not a killed branch. Caveman's verdict was "not yet," not "never."
But the evaluation produced a map. The map showed that one block — the skills index injected into every worker phase's CLAUDE.md — was the single biggest fixed input cost in the system. 14,698 bytes. Approximately 3,674 tokens. Every phase, whether the phase needed a skill or not.
I ran a re-evaluation mission to figure out what to do about it. The first pass got it wrong. The analyst took a three-day, 109-phase window, found that ten of sixteen command-tailed skills had zero invocations in that window, and recommended full removal of the skills index. That recommendation would have deleted both the CLI skill definitions (which workers sometimes don't reference directly) and the knowledge skill definitions (which workers reach for constantly). The methodology was wrong on two grounds: a three-day sample can't speak for a 35-day codebase, and the analyst treated CLI and knowledge skills as a single class when they aren't.
The corrective mission added evidence grading on every claim — measured, projected, or inferred from code — required all-time metrics instead of a short window, and demanded a consumer map of which code paths actually read the block and how. The consumer map found thirteen code consumers. Only one of them — the worker phase prompt builder — emitted the full block with command tails. Another path, FormatSkillsForDecomposer, stripped each entry at the colon-brace boundary (the marker that separates a skill header from its command-tail payload) before the decomposer saw it. The decomposer had been running on header-only input for the entire 35 days of instrumentation and routed skills correctly every single phase. 99.16% gate pass rate. Zero routing regressions.
The ship was Option E. Strip command tails from the worker-visible block, keep every header row. Two files changed. One commit, 4671bcec. Block size went from 14,698 bytes to 5,801. A 60.5% reduction, all 35 skill entries retained.
The twist is what reframes the whole optimization. FormatSkillsForDecomposer had already been doing this. Option E didn't introduce a new regime. It normalized the worker-visible path to match what the decomposer had already been doing for 35 days. The change was grounded in 35 days of empirical confirmation — just on a different code path. The win wasn't "smaller block." The win was "worker path now has the same cache-friendly surface the decomposer path already had."
That's the actionable version of Rule 3. Audit your hot path for surface that isn't earning its place, and remove it.
Rule 4: Instrument before you optimize.
Nanika runs on a Claude Max subscription — there's no per-phase bill I can look at. But the serving-side load my harness puts on Anthropic is exactly the thing Rule 2's SEV alerts watch, and it's computable from the cache_read_input_tokens and cache_creation_input_tokens fields the claude CLI emits on every response. I call it the shadow weight: the load a session puts on Anthropic's serving infrastructure, which I don't pay but which determines whether Anthropic will keep serving me. Knowing this number in token terms is the point. Converting it to dollars is theater, and I fell for it once.
The first evaluation almost shipped the wrong answer. That would have deleted the knowledge skill definitions along with the CLI command tails, and nanika would have lost its skill discovery for half the skill types. The only thing that stopped it was the corrective mission's evidence grading — which only exists because someone read the first recommendation and went "that number looks too confident for a three-day sample."
My baseline snapshot before the Option E cutover estimated roughly 2,172 tokens saved per worker phase from the 60.5% block reduction. That number is defensible — it's just bytes divided by bytes-per-token. The error I almost made was treating every saved token as equivalent. They aren't. The cache composition on nanika's actual traffic shows 94% of those saved tokens would have been cache reads (billed at 10% of the base input rate by Anthropic's own pricing), 5.78% cache creation (billed at 125% of base), and 0.22% fresh input (billed at 100%). The weighted average works out to roughly 18% of the base rate — about 5.6 times less than the naive "every token costs base rate" assumption.
In serving-cost terms, Option E is about 5.6 times less impactful than "save 2,172 tokens per phase" makes it sound, because the tokens I was saving were already the cheap kind. Option E's structural case is unchanged by the correction — smaller block, better cache stability, no dead bytes in the hot path — but the story I almost told myself about meaningful savings was five and a half times louder than the actual serving-load impact.
That's the lesson I want Rule 4 to carry: know the cost weight of what you're saving, not just the count. A byte stripped from a cache-stable hot path is a tiny fraction of the serving cost of a byte stripped from a fresh-rebuild path. Anthropic already priced this in for you — 10% versus 125% versus 100%. Your optimization's real impact on Rule 2's SEV surface is the token count multiplied by the applicable rate, not the raw token count.
Shihipar's team declares SEVs on their cache hit rate. The minimum version of this rule for anyone building a harness is: know yours. Log cache_read_input_tokens and cache_creation_input_tokens on every response. Compute the share. Compare against the plain-Claude-Code baseline. If you're more than ten points below 95%, something in your harness architecture is fighting the cache, and you should figure out what it is before you optimize anything else. And when you go to estimate the impact of a change, weight your token counts by the rate column. Don't do what I did.
Rule 5: Don't touch the system prompt surface.
This is the rule that killed OpenCode, and the PR #18186 diff is the cleanest explanation of why.
The file that got deleted was a verbatim copy of Claude Code's official system prompt, hardcoded in the opencode repo, 166 lines, with Dax Raad's own working directory still baked into the environment block. OpenCode was shipping its Claude Max integration by pretending to be Claude Code. The prompt wasn't similar to Claude Code's — it was identical. That's the thing the AUP's circumvention language reaches for.
From the Acceptable Use Policy:
"Circumvent a ban through the use of a different account, such as the creation of a new account, use of an existing account, or providing access to a person or entity that was previously banned."
"Intentionally bypass capabilities, restrictions, or guardrails established within our products."
"Engage in actions or behaviors that circumvent the guardrails or terms of other platforms or services."
A harness that invents its own system prompt and runs on its own API key is exercising a legitimate developer use case. A harness that clones Claude Code's system prompt and brokers subscription tokens through it is impersonating the official client. Those are different categories. The first is what Anthropic wants. The second is what Anthropic will block, and the fact that the hardcoded path was visible in the public opencode repo is why PR #18186 merged in nineteen minutes instead of nineteen days.
Nanika ships its own system prompt contract. It has its own worker persona model, its own phase lifecycle, its own structured output format. The worker prompt surface is not Claude Code's. That isn't cleverness — it's the consequence of needing the workers to do things Claude Code doesn't do, like produce structured phase outputs a parent orchestrator can parse.
If your harness is tempted to start from Claude Code's system prompt and tweak it: don't. Write your own. It's more work, and it's the whole reason you have a defensible architecture.
What we still don't know.
Four things.
First, I don't know where the cache hit rate floor actually is. 94% is comfortably above what I can measure for anything I've seen publicly documented, but the Shihipar quote doesn't name a number. The vagueness is deliberate. If you need certainty, you will not get it.
Second, the Option E watch window is still open. It opened at 2026-04-11T03:05Z and closes at 100 completed phases or 2026-04-25T03:05Z, whichever comes first. At the time I'm writing this, zero post-cutover phases have completed. Every per-phase number in this piece — the projected ~2,172 tokens saved per phase, the 5.6x cost-weighting correction, the per-persona sensitivity breakdown — is projected from baseline instrumentation, not measured from post-cutover data. The direction is confident. The magnitude is not yet confirmed.
Third, the timeline I gave at the top is accurate for enforcement but misleading for policy. The Register reported, citing Anthropic, that the underlying prohibition against using subscription OAuth tokens in third-party tools has been in the Consumer Terms since at least February 2024. The language was there for almost two years before Anthropic started enforcing it on January 9, 2026. I couldn't independently verify the exact clause in a publicly-archived 2024 version of the Terms — if you have a Wayback capture, tell me. The practical point stands: the rules aren't new. The willingness to enforce them is.
Fourth, and most important: Anthropic has not publicly codified the cache-economics argument in any legal document. The Shihipar quote is operational reality. It is not contractual obligation. A harness builder reading the published AUP from scratch cannot derive "your cache hit rate must be above X" from the text. You have to read between the lines of public statements, ban notices, and a PR that merged in nineteen minutes. That's the actual hard part. The rules exist. They're just not all written down.
Matt Pocock asked Thariq publicly if Anthropic would clarify. A week later, Theo read that question on camera and said he'd never had a company so unwilling to answer basic questions that were blocking people every day. I don't have a better answer than Matt's open question. I have a harness that hasn't been killed, five rules that explain why, and a watch window that will tell me in about seventeen hours of wall clock whether my latest alignment change with the Claude Code harness economics actually moves the measured number I care about.
If it doesn't, I'll revert. If it does, the rules stay.
Sources: Simon Willison — Thariq Shihipar quote · The Register — Anthropic closes door on subscription use of OpenClaw (Apr 6, 2026) · The Register — Anthropic clarifies ban on third-party tool access to Claude (Feb 20, 2026) · OpenClaw issue #559 · opencode PR #18186 · Theo Browne — "I need you guys to trust me on this" · Anthropic Consumer Terms of Service · Anthropic Acceptable Use Policy · Claude Agent SDK overview · frr.dev — 99% of what you send to Claude is already cached · Claude Code Camp — How Prompt Caching Actually Works