Latest Anthropic Change Kills this path?

[yetdog]

Since we are using the Claude code billing ID, it seems like the changes recently announced will render this projects approach moot?

[rafaelreis-r]

@zacdcook I believe this is it, right?

https://x.com/kunchenguid/status/2054625715321233436?s=46&t=_muoEG3Dno3fAwpv070USA

[DBostik]

I can't tell if this will impact us or not but I'm guessing it will.

Does it mean we technically will just receive the paid amount ($20/$100/$200) in API credits every month?

[yetdog]

I can't tell if this will impact us or not but I'm guessing it will.

Does it mean we technically will just receive the paid amount ($20/$100/$200) in API credits every month?

Exactly. Which, is such an overly sugar coating it's insulting.

[rafaelreis-r]

Running this in production via OpenClaw on a Mac mini, Claude Opus driving everything. Did a deep dive on the proxy code today to answer exactly this question. Short answer: the announcement doesn't kill this path directly, but it changes the threat model.

Why it doesn't kill it directly:
The proxy doesn't use claude -p, the Agent SDK, or any CLI subprocess. It only reads the OAuth token that claude auth login writes to ~/.claude/.credentials.json (or the Keychain), then makes plain HTTPS requests to api.anthropic.com with that bearer token, forging Stainless headers + user-agent: claude-cli/<v> + x-app: cli + x-claude-code-session-id to look like an interactive Claude Code session. From the API's point of view, what arrives is an "interactive Claude Code" request — which is precisely what the announcement still says is bundled in Pro/Max.

claude the binary is used once for the OAuth bootstrap; nothing programmatic in the runtime path touches it.

Why it still matters:
The June 15 split (Agent SDK / claude -p / third-party apps → separate $20/$100/$200 credit pool) gives Anthropic a financial incentive to reclassify more aggressively than they already do. April 8, 2026 already saw the multi-layer fingerprinting upgrade that broke v1.x — v2.0 shipped 24h later with the 7-layer bypass we use today. The next round will likely target whatever isn't covered by the current layers:

1. Behavioral cadence — interactive sessions have human-typing pauses, retries, and tool-use distributions that programmatic agents don't match. The proxy doesn't simulate any of this.
2. Stainless / SDK header fingerprint — easy to bump versions, but they could start challenging or invalidating instance session IDs that don't behave like real CC instances.
3. Token-level marking — once a token gets associated with a "programmatic" pattern, they could flag it permanently regardless of headers.
4. New endpoint routing for "interactive" traffic, with the old path silently degraded.

Practical take from running this:

• Until June 15: zero action needed, current v2.2.4 is fine.
• After June 15: watch this repo. The historical pattern (8 Apr break → 9 Apr v2.0 ship → 5 patch releases same day) suggests @zacdcook will respond fast if/when something breaks. Have a fallback ready — direct API key + at least one alt provider (we route through Z.AI GLM-4.7-flash and MiniMax-M2.7 as fallbacks already).
• Do the math on real consumption. For heavy users, the official $100/mo Max 5x Agent SDK pool may end up cheaper than rolling the dice.

Not the end of this path. Just the start of round 2.

[zacdcook]

@rafaelreis-r is correct in his analysis. It is extremely likely that the new changes will not impact the proxies functionality as it does not use claude -p & effectively replicates a Claude code request body.

That said, it is possible they update their enforcement mechanisms on the 14th, but there's truly not much they can do to make a workaround impossible without major architectural changes to Claude Code itself (and considering the legwork required to do so, and also considering the very small percentage of users who would actually implement & utilize a bypass proxy, I'd say the juice ain't worth the squeeze for them).

That said, I'm actively running a capture proxy between Claude code & api.anthropic.com to monitor for any preemptive changes to the request body format, that way I can get ahead of it early should there be any small changes peppered in prior to the 14th.

Regardless, as @rafaelreis-r said, this is certainly not the end of this path. It's simply round 2. And we always find a fix 😈. I'll be awake nice & early on the 14th to build & push the workaround should it be needed.

[rafaelreis-r]

Follow-up with concrete evidence: enforcement is now live, and it's a hard 400 block — not (only) silent reclassification. But it's selective, and strongly correlated with payload size.

Setup: OpenClaw on a Mac mini, Opus driving everything, proxy v2.2.3, emulating CC 2.1.97, single Max token.

The exact rejection

I patched the proxy to dump the raw upstream body on any 400. This is what Anthropic returns:

{"type":"error","error":{"type":"invalid_request_error",
"message":"Third-party apps now draw from your extra usage, not your plan limits. Add more at claude.ai/settings/usage and keep going."},
"request_id":"req_011Cd6Kdkce6fb3iFfSE1Sej"}

So on these requests the disguise is being seen through, the request is classified as third-party, and because there's no extra-usage balance enabled it's rejected outright (400) rather than silently reclassified. This is the harder edge of what #41 reported.

It's selective, and it tracks payload size

Over ~44k POST /v1/messages (72.5% 200, 0.4% 400), pairing each request's post-sanitize body size with its status:

status	n	min	p50	p90	max
200	20,954	370 B	238 KB	552 KB	4.1 MB
400	11	499 KB	564 KB	834 KB	835 KB

Every 400 is ≥ ~499 KB post-strip. But 3,070 of the 200s were also ≥ 499 KB and went through fine — so it's not a hard size cap. Large size is necessary-but-not-sufficient: detection only manifests on large payloads (more un-sanitized identifying surface surviving the config-template strip — workspace docs, tool results, conversation history — and/or server-side sampling), but doesn't fire on every large one.

The config-template strip ([STRIP] Removed ~29K chars) is applied on the failing requests, so what's leaking is the content that survives it, not the identity block.

Practical takeaway

• The path isn't dead (as you and @rafaelreis-r noted), but April's change is now enforced and hard-blocking the fattest requests.
• The most reliable client-side lever is shrinking large payloads (trim agent tool-sets / history so requests stay well under ~450 KB post-strip) — that alone would eliminate essentially all of these here.
• Complementary, and still worth doing regardless: the per-request dynamic fingerprint cache-invalidation hypothesis in Instrument response usage to diagnose token burn; possible cache-key contamination via dynamic fingerprint (cc #41) #46 (stabilize cc_version.<fp> per-conversation to preserve prompt caching), which independently reduces token burn / 429 pressure.

Happy to share the size-vs-status script or a redacted failing body if useful.

[rafaelreis-r]

Correction to my comment above — the size correlation was wrong, and this looks like a step-function enforcement rollout that flipped today.

I pooled old structural 400s (the tool_use_id/tool_result kind from #34, which do scale with size) with the new extra usage 400s. Isolating only the extra usage rejections tells a very different story:

It's a time-based step function, not size

Per-hour, provider=anthropic on this account today (local time):

hour	200	400	%400
00–08h	~250	0	0%
09h	40	2	5% ← onset
12h	16	7	30%
13h	0	2	100%

Clean all night, sharp onset ~09h, escalating toward total blockage within hours. This is the same discrete step change #46 observed after Apr-4 — now landing on this account.

Not size, and not model-specific

• The extra usage rejections hit request bodies of 11 KB, 33 KB, 42 KB just as readily as the 471 KB ones. My earlier "≥499 KB" claim only held because I'd mixed in the structural 400s. Scratch the size theory.
• All models (opus-4-8, sonnet-5, fable-5) and multiple channels (a Matrix agent and a Telegram agent) — so it's account/token-scoped, not payload- or route-specific.
• Confirmed novel: a 400-body dump I have from Jul-4 contains zero extra usage errors. This is new as of today.

A concrete disguise-drift lead

The proxy emulates CC 2.1.97; current CC is 2.1.205 (108 versions back). The billing-fingerprint salt is unchanged (59cf53e54c78 is still in the 2.1.205 binary), but the billing header shape has grown. In 2.1.205 the header is assembled as:

`x-anthropic-billing-header: cc_version=${n}; cc_entrypoint=${o};${s}${l}${c}${u}`
// ${u} = r && i==="firstParty" && kd() ? ` cc_prev_req=${r};` : ""
// also conditionally: cc_is_subagent=true;  and  cc_workload=${a};

i.e. a genuine first-party session now emits a cc_prev_req=<prev-request-id> chain field (plus cc_is_subagent / cc_workload when applicable). The proxy emits a static three-field header (cc_version; cc_entrypoint; cch=00000;) with no cc_prev_req. If Anthropic started validating request-chaining / header shape against current-CC behavior, a proxy that never chains cc_prev_req is an obvious tell — and would produce exactly this kind of all-at-once flip.

I can't yet prove that's the trigger (it could be pure server-side account flagging), but it's the most concrete client-side lever left: bump CC_VERSION and replicate the modern header (including per-session cc_prev_req chaining). Will report back if it moves the needle. cc #41 #46

[KoKos024]

@rafaelreis-r

Can confirm that things broke for me as you described. One thing to note, the troubleshoot.js passes every time. Just the real messages fail.

If you get anywhere with a fix, please post. It will be greatly appreciated. I'll report back if I find anything myself.

Thanks

[DBostik]

I can confirm that something they did in the last 4 hours has now made billing proxy ineffective

Messages this morning worked fine but then as of 2 hours ago Anthropic began having server issues according to https://status.claude.com

And now messages use extra billing when active or return this if extra billing is off: ⚠️ anthropic (claude-sonnet-5) returned a billing error — check your account for subscription or usage limits, then try again.

[DBostik]

Automatic and manual token refresh is also not working currently. Even when using terminal to login to Claude and refresh token.

[rafaelreis-r]

Solved it — the disguise had drifted, not the account. Fix up as #61.

Confirmed the account was fine (genuine claude on the same token kept returning 200), so I ran a transparent capture proxy, pointed a genuine CC at it (ANTHROPIC_BASE_URL=…), and diffed the real 2.1.205 request against what this proxy emits. A pile of fields had gone stale since 2.1.97. Realigning them flipped it from 100% blocked back to 200, zero extra usage since.

The mismatches that mattered:

• metadata.user_id was missing account_uuid — genuine sends {device_id, account_uuid, session_id}. Almost certainly the main tell. (Per-account; not in .credentials.json — CC gets it from the OAuth profile.)
• anthropic-beta: stale list/order — replaced with the exact 2.1.205 set, wholesale.
• x-stainless-os macOS→MacOS, package-version 0.81.0→0.94.0, runtime-version pinned v26.3.0.
• user-agent + billing cc_entrypoint cli→sdk-cli, dropped cch=00000, added the modern cc_prev_req=<prev-id> chain field.
• CC_VERSION 2.1.97→2.1.205, and path /v1/messages?beta=true.

Details + verification in #61. The specific values will rot with each CC release; the capture-and-diff loop is the reusable part. Thanks @zacdcook — this held up in production all afternoon.