Anthropic oauth account ban - thanks Omniroute!!

[jbovard2016]

I passed my Claude account through Omniroute and Anthropic banned me.

Why cant Omniroute just forward the Oauth, untouched and un modified???? I tried everything but Omniroute takes it upon itself (no matter what I do) to modify the call, which not only destroys Anthropic cache headers, but it turns out triggers a ban.

I even had Astra pull the Onni platform apart trying to figure out where the modification was happening and it could not.

Surely you can ship some sort of 'DO NOT TOUCH OR MODIFY MY ANTHROPIC CALLS' setting????

[diegosouzapw]

Hi @jbovard2016. Losing an account is a bad outcome and I am not going to be defensive about it. Here is the straight answer, including the part you will not like.

Yes, OmniRoute modifies Claude OAuth requests, and there is no switch for it

The reason your investigation found nothing is that the rewrite is not in a setting. It triggers on the credential itself: any token starting with sk-ant-oat and no API key (open-sse/executors/base.ts:970-980). The comment on the line above is explicit that the cloak applies regardless of which client is calling.

What it does to the body, every time:

• Prepends two blocks to the top of system: a billing line and You are Claude Code, Anthropic's official CLI for Claude. (base.ts:1192).
• Recomputes the cch= value in that billing line as a hash of the whole body, so system[0] differs on every request (open-sse/services/claudeCodeCCH.ts:40-47).
• Deletes cache_control from every tool, unconditionally, because the real CLI never sets it (base.ts:1003-1007).
• Defaults a missing cache_control.ttl to 1h (open-sse/services/claudeCodeConstraints.ts:169-202).
• Replaces metadata.user_id with a synthetic device, account and session identity (base.ts:1143-1164, open-sse/services/claudeIdentity.ts:257-267).
• Rewrites the headers: user-agent: claude-cli/..., x-app: cli, the X-Stainless-* set, and anthropic-beta (base.ts:1242-1296). Your client's versions of those headers are dropped before the merge.
• Reorders headers and body fields to match the CLI's wire order (base.ts:1403-1410).

There is no raw or transparent mode for this path. I grepped the settings, the feature flags, the env vars and the connection fields. It does not exist. I filed #13893 to add one as an opt-in, default-off flag per connection.

Why it exists

The user:sessions:claude_code OAuth scope expects traffic shaped like claude-cli. Forwarding another client's request untouched on a Claude Code token is what produces 400 Third-party apps now draw from extra usage. So the literal thing you are asking for would most likely break your requests rather than save them. That is an explanation, not a justification for having no opt-out.

What you can turn off today

• alwaysPreserveClientCache: "always" keeps your own cache_control breakpoints even when the client is not Claude Code. In the default auto, a non-Claude-Code client loses them. There is no toggle for it in the dashboard yet, so it goes through PUT /api/settings/cache-config.
• The system-block transform pipeline can be disabled in Settings → Routing. It does not remove the billing line or the You are Claude Code sentinel, which are prepended outside it.
• x-omniroute-thinking: off and x-omniroute-effort: off as request headers disable the injected thinking and effort fields (base.ts:1013-1035).

None of those gets you to an unmodified request.

On the ban itself

I will not claim to know what triggered it, in either direction. What the repository actually records:

• [bug] Claude Teams/Max accounts banned by Anthropic right after connecting as provider — add warning + fix subscription-type badge #4118: two independent reports of Claude Teams/Max accounts banned about a minute after being connected, before any request was served. The conclusion there was upstream anti-abuse behavior on connecting a subscription account to a proxy.
• Nothing anywhere links cache-header handling to a ban. That connection is a hypothesis, and I have no measurement for it.

If you are willing, two data points would sharpen this a lot: whether the ban landed before or after your first request went through, and the exact error body and status Anthropic returned. That is what separates "banned for the shape of the request" from the #4118 pattern.

Either way, connecting a Claude subscription account to any proxy carries a real ban risk that OmniRoute cannot remove. Worth weighing before reconnecting another account.

[diegosouzapw]

Closing for inactivity -- feel free to reopen if you still hit this, or open a fresh issue with a current log. Thanks!