OAuth-proxied requests metered as 'extra usage' instead of included plan usage

[thomaswillner]

Summary

OAuth-proxied requests through CLIProxy are being metered by Anthropic as "extra usage" (billed at API rates against a spending cap) instead of counting against the plan's included usage limits. This defeats CLIProxy's core design purpose of proxying OAuth tokens so that requests are indistinguishable from native app usage.

Environment

• CLIProxy version: 6.9.15 (HEAD-c8b7e2b, built from source)
• Plan: Claude Max (individual)
• Auth method: OAuth tokens via ~/.cli-proxy-api/ auth files
• OS: macOS (Homebrew install)

Observed Behavior

With the same claude.ai account, authenticated via OAuth:

Channel	Metering	Status
Claude Desktop (Cowork)	Included plan usage	Works (5-hour limit at 37%)
CLIProxy OAuth proxy	Extra usage (API-rate billing)	Blocked (spending cap exceeded)

Both channels use the same OAuth account. The plan's included rate limits still have capacity:

5-hour limit:    37%
7-day limit:     70%
7-day Sonnet:    80%
Extra Usage:     EXCEEDED — blocking CLIProxy only

Error from Anthropic

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "You're out of extra usage. Add more at claude.ai/settings/usage and keep going."
  }
}

This error hits all Claude models routed through CLIProxy (Sonnet 4.6, Opus 4.6) while the same models work fine through the native Claude Desktop app on the same account at the same time.

Expected Behavior

Requests proxied through CLIProxy using OAuth tokens should count against the plan's included usage limits (5-hour, 7-day, Sonnet-specific), not against the extra usage spending cap. The whole point of OAuth-based proxying is to share the same metering bucket as the native app.

Suspected Cause

Anthropic's backend appears to classify CLIProxy's POST /v1/messages requests differently from native Claude Desktop requests, even though both use the same OAuth session. Possible distinguishing factors:

• Request path / endpoint differences
• User-Agent or other header differences
• Auth presentation format (Bearer token vs session cookie)
• Anthropic backend routing based on client type

Impact

High-frequency automated use cases (cron jobs, agent loops) burn through the extra usage spending cap rapidly, while the included plan usage sits mostly unused. This makes CLIProxy economically unviable for its intended purpose — you end up paying API rates for usage that should be covered by your plan.

Reproduction

1. Set up CLIProxy with OAuth token from a Max plan account
2. Set a modest extra usage spending cap (e.g. $20)
3. Run automated workloads through CLIProxy (e.g. cron jobs)
4. Observe that the extra usage cap fills up while included plan limits remain partially unused
5. Simultaneously confirm that Claude Desktop still works on the same account (proving included limits have capacity)

[imbytecat]

same here.

Third-party apps now draw from your extra usage, not your plan limits. We've added a $200 credit to get you started. Claim it at claude.ai/settings/usage and keep going. 

[nazriel]

I think it is related to how system prompt is built.

When running proxy via CLIProxyApi and overwriting system prompt in my opencode

  "agent": {
    "plan": {
      "prompt": "You are Claude Code, Anthropic's official CLI for Claude."
    },
  }

likes so, makes it work again.

Otherwise I was getting the same error like you.

I don't know what is the premise of CLIProxyApi here though, whenever it should force system prompt and overwrite what harness is sending, or it is out of scope, let me know

[deblanco]

I think it is related to how system prompt is built.

When running proxy via CLIProxyApi and overwriting system prompt in my opencode

  "agent": {
    "plan": {
      "prompt": "You are Claude Code, Anthropic's official CLI for Claude."
    },
  }

likes so, makes it work again.

Otherwise I was getting the same error like you.

I don't know what is the premise of CLIProxyApi here though, whenever it should force system prompt and overwrite what harness is sending, or it is out of scope, let me know

This worked for me. Where did you get the System Prompt?

[nazriel]

@deblanco in issue tracker of one of the oauth plugins - but I don't recall anymore from which one exactly

[devxoul]

fyi, it doesn't have to exact match. It works with:

"prompt": "You are you"
"prompt": "You are a builder"
"prompt": "You are whatever"
"prompt": "Hi"

[thomaswillner]

Fix: proxy-side system prompt injection via payload.default (no client changes needed)

Building on @nazriel's discovery — the root cause is that Anthropic's backend classifies requests without a system prompt differently, routing them to "extra usage" metering instead of plan limits. As @devxoul confirmed, any system prompt works; it doesn't need to be an exact match.

Instead of patching each client (OpenCode, Cline, etc.), you can fix this once at the CLIProxy level using the payload config. Here's how:

Step-by-step

1. Back up your config

cp /opt/homebrew/etc/cliproxyapi.conf /opt/homebrew/etc/cliproxyapi.conf.bak-$(date +%Y%m%d-%H%M%S)

(Adjust the path if you're not on Homebrew — check where your active config lives.)

2. Add this block to the end of your cliproxyapi.conf

payload:
  default:
    - models:
        - name: "claude-*"
          protocol: "claude"
      params:
        "system": "You are Claude Code, Anthropic's official CLI for Claude."

Key detail: default means it only injects the system prompt when the client doesn't already send one. So native Claude Code sessions (which send their own system prompt) are completely unaffected — this only kicks in for clients that omit it.

3. Restart CLIProxy

brew services restart cliproxyapi

4. Verify

# Confirm it's listening
lsof -nP -iTCP:8317 -sTCP:LISTEN

# Confirm auth still works
curl -s -o /dev/null -w "HTTP %{http_code}" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  http://127.0.0.1:8317/v1/models

Why this works

The payload.default feature uses sjson to set JSON fields in the request body before it hits Anthropic's API. By setting "system" as a default, every Claude request going through the proxy will have a system prompt present — which appears to be the signal Anthropic uses to classify the request as "first-party app usage" rather than "third-party API usage."

Why cloak doesn't help here

CLIProxy's existing cloak feature does something similar (prepends the Claude Code system prompt), but it's only available on claude-api-key entries — not OAuth sessions. The payload approach works globally regardless of auth method.

Note for CLIProxy maintainers

It might be worth considering adding OAuth-level cloak support (or making payload.default the documented workaround for this class of issues). The current cloak feature being limited to API key entries leaves OAuth users without a built-in fix.

[thomaswillner]

How Anthropic could close this

Following up on my fix above — worth noting how thin the current gate actually is.

What they're doing now (trivially bypassable)

Binary presence check: does the request have a system field? If yes → plan usage. If no → extra usage / API billing. As @devxoul confirmed, even "prompt": "Hi" works. They're not validating content at all.

What they could try next

System prompt signature validation — hash or pattern-match against known Claude Code system prompts. Problem: Claude Code's system prompt is visible to anyone running --debug or intercepting locally. Becomes an arms race: extract → inject → rotate → repeat.

Cryptographic client attestation — sign requests with a client-side secret or certificate proving they came from a genuine Claude Code binary. CLIProxy already reverse-engineers the cch signing header (experimental-cch-signing in config), so Anthropic would need to make attestation harder to replicate — hardware-bound tokens, binary integrity checks, or challenge-response flows tied to the OAuth session origin.

The fundamental problem: Any proxy sitting between a legitimate OAuth token and Anthropic's API can mimic whatever client signals they check for. The only real defense is making client attestation expensive to replicate — but that conflicts with their open API/SDK design. It's the same DRM problem every platform faces.

For now, a single missing JSON field is the entire boundary between "plan usage" and "API billing." That won't hold.

[thomaswillner]

@luispater @hkfires @wykk-12138 — heads up: commit 69b950d fixes this at the executor level (nice, three birds with one stone). Could this get a point release soon? There are a lot of users hitting the extra usage wall right now, and the payload.default workaround above only covers people who find this thread.

Also might be worth adding a bug label to this issue for discoverability.

[devxoul]

It stopped working from this morning btw.

[imbytecat]

Not working again, should find a way to fix it

[thomaswillner]

Update (2026-04-09): The payload.default system prompt injection workaround no longer works as of today. Anthropic appears to have tightened validation — presence of a system field alone is no longer sufficient.

Observed behavior:

• Direct minimal requests (simple hi message, no tools) → succeed on plan tokens
• Real workload requests via OpenClaw (full system prompt, tool definitions, large context) → 400 "out of extra usage" on all Anthropic models (Opus 4.6, Opus 4.5, Sonnet 4.5, Haiku 4.5)
• CLIProxy updated to HEAD-1dba2d0 (built today) — same result
• Same OAuth credential, same account, same plan (Max 20x) with 95%+ session capacity remaining

CLIProxy dashboard vs Anthropic billing page:

• CLIProxy shows 97% PlanMax remaining on 5h window
• Anthropic billing page confirms: session 5% used, weekly 56% used, Sonnet weekly 22% used
• Extra usage is OFF, spend cap at €20 (already exceeded at €20.66 from prior API metering)

This confirms Anthropic is classifying CLIProxy-forwarded requests as API/extra-usage rather than plan usage, regardless of system prompt presence. The structural validation (5-block system prompt format, CCH signing) from PR #2621 appears to be the required fix.

Request: Can #2621 be prioritized? The workaround path is dead and all Anthropic models are currently unusable through CLIProxy for any non-trivial request.

[thomaswillner]

Working fix: local rewrite proxy (complete solution with auto-rollback)

Following up on my earlier updates — I've built, tested, and deployed a working fix that routes OC/third-party requests through Anthropic plan tokens again. Sharing the full implementation for anyone stuck on this while waiting for PR #2621.

---

Root cause analysis (updated)

Anthropic now validates system prompt structure, not just presence. The detection has three layers:

1. Billing header (system[0]) — x-anthropic-billing-header: cc_version=X; cc_entrypoint=Y; cch=Z;
2. Agent identifier (system[1]) — "You are Claude Code, Anthropic's official CLI for Claude."
3. Static prompt content (system[2]) — all five Claude Code sections concatenated: intro, system, doing tasks, tone & style, output efficiency

The stable CLIProxy build (HEAD-1dba2d0) already injects the billing header + CCH hash via applyCloaking, but does not rewrite system[1] and system[2]. That's what PR #2621's checkSystemInstructionsWithSigningMode() adds. Without all three blocks matching, Anthropic classifies the request as third-party API traffic → "extra usage" billing.

The earlier payload.default workaround (my comment above + @nazriel's discovery) stopped working because Anthropic moved from a binary check ("does system exist?") to structural validation ("does system match Claude Code's 3-block format?").

What the fix does

A lightweight Node.js HTTP proxy sits between your application and CLIProxy:

Your App (OC, OpenCode, Cline, etc.) → Rewrite Proxy (:8318) → CLIProxy (:8317) → Anthropic

For every POST /v1/messages, it:

1. Extracts the original system prompt content from the request
2. Replaces system[] with Claude Code's exact 3-block structure:
   • system[0]: billing header with CCH hash (SHA-256 first 5 hex of first system text)
   • system[1]: agent identifier (no cache_control — matching PR fix(claude): prevent OAuth extra-usage billing via tool name fingerprinting and system prompt cloaking #2621's buildTextBlock(text, nil))
   • system[2]: all 5 static prompt sections joined with \n\n (no cache_control)
3. Forwards original system content as <system-reminder> prepended to the first user message (OAuth-sanitized per PR's sanitizeForwardedSystemPrompt())
4. Passes through all non-/v1/messages requests unchanged

Critical implementation detail: the agent and static blocks have no cache_control. Earlier attempts with cache_control: { type: "ephemeral" } on these blocks may fail — PR #2621 passes nil for both.

The proxy code

proxy.mjs (~280 lines) — full source: https://gist.github.com/thomaswillner/oc-anthropic-proxy (or see below)

The system prompt strings are exact copies from claude_system_prompt.go in PR #2621 (Claude Code v2.1.63 reference). All 5 sections included:

• claudeCodeIntro — agent intro + URL safety warning
• claudeCodeSystem — system instructions (tool use, permission mode, system-reminder tags, prompt injection flagging, context compression)
• claudeCodeDoingTasks — task guidance (15 bullet points covering code reading, security, abstraction, etc.)
• claudeCodeToneAndStyle — conciseness, no emojis, file:line pattern, no colons before tool calls
• claudeCodeOutputEfficiency — brevity directives, milestone updates, error reporting

Don't abbreviate these. Anthropic validates content, not just structure.

Deployment

# 1. Create proxy directory
mkdir -p ~/oc-anthropic-proxy
# Put proxy.mjs there (see source above)

# 2. Test standalone
node ~/oc-anthropic-proxy/proxy.mjs &
curl -s -X POST http://127.0.0.1:8318/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_CLIPROXY_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-haiku-4-5-20251001","max_tokens":32,"system":[{"type":"text","text":"You are a test agent."}],"messages":[{"role":"user","content":"Say: test-ok"}]}'
# Should return a successful response, not a billing error

# 3. Point your application at :8318 instead of :8317
# For OpenClaw: change models.providers.cliproxy.baseUrl to http://127.0.0.1:8318
# For other tools: change the API base URL accordingly

# 4. Install as macOS LaunchAgent for persistence (optional)
cat > ~/Library/LaunchAgents/ai.openclaw.anthropic-proxy.plist << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>ai.openclaw.anthropic-proxy</string>
    <key>ProgramArguments</key>
    <array>
        <string>/opt/homebrew/bin/node</string>
        <string>/Users/YOU/oc-anthropic-proxy/proxy.mjs</string>
    </array>
    <key>WorkingDirectory</key>
    <string>/Users/YOU/oc-anthropic-proxy</string>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <dict>
        <key>SuccessfulExit</key>
        <false/>
    </dict>
    <key>StandardOutPath</key>
    <string>/tmp/anthropic-proxy.stdout.log</string>
    <key>StandardErrorPath</key>
    <string>/tmp/anthropic-proxy.stderr.log</string>
</dict>
</plist>
EOF
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/ai.openclaw.anthropic-proxy.plist

Auto-rollback when PR #2621 ships

This proxy is a temporary workaround. I've set up a daily check that:

1. Runs brew upgrade cliproxyapi
2. Checks if the new binary contains the Claude Code system prompt strings (strings $BIN | grep "You are Claude Code")
3. If found → reverts config to direct CLIProxy (:8317), unloads proxy, restarts gateway, validates
4. If the direct test fails → safety-rolls-back to the proxy

This ensures the proxy auto-removes itself once the upstream fix ships, with no manual intervention needed.

Confirmed working

• Claude Haiku 4.5 ✅
• Claude Sonnet 4.6 ✅
• Claude Sonnet 4.6 with tools array + multi-block system prompt (full OC payload) ✅
• All returning plan tokens, no "extra usage" errors
• Max 20x subscription, 95%+ capacity remaining, extra usage OFF

Key difference from PR #2621

The proxy uses the OAuth sanitization path for forwarded system content — matching sanitizeForwardedSystemPrompt() from the PR. This replaces the original (potentially large) system prompt with a 3-line neutral tool guidance string in the <system-reminder> block. This is the safest approach because:

1. It minimizes the content Anthropic could use for third-party traffic classification
2. It matches exactly what the PR does for OAuth-authenticated requests
3. The original agent behavior isn't affected because the model still receives its instructions (just relocated from system[] to user message context)

Hope this helps others stuck on this. Would love to see #2621 merged so we can all get off workarounds.