Summary

Claude subscription/OAuth requests can return:

HTTP 400: You're out of extra usage. Add more at claude.ai/settings/usage and keep going.

...even when the Claude auth token is valid and minimal Anthropic Messages requests succeed.

On Tyler's macOS machine, the failure was not caused by the proxy itself, the OAuth token, or tool schemas alone. The trigger was the full Hermes-assembled system prompt on the Anthropic OAuth / Claude Max proxy path.

Environment

• Hermes repo: NousResearch/hermes-agent
• Local branch where workaround was applied: feat/context-budget-management
• Local preserving commit: 5eeb76e5
• Platform: macOS
• Provider runtime:
  • provider: anthropic
  • api_mode: anthropic_messages
  • base_url: http://127.0.0.1:18801
• Auth source: Claude Code / Claude subscription OAuth from ~/.claude/.credentials.json
• Model: claude-opus-4-6

What we verified

1. Proxy and auth were healthy

The local billing proxy on 127.0.0.1:18801 was restored and /health returned OK.

A direct minimal Anthropic SDK call through that same proxy succeeded:

client.messages.create(
    model='claude-opus-4-6',
    max_tokens=8,
    messages=[{'role': 'user', 'content': 'Say OK'}],
)

Result: OK

So this was not simply "proxy down" or "OAuth token invalid".

2. The failure was prompt-shape sensitive

Using the same proxy, auth, and model:

• baseline user-only request: works
• Claude Code identity block only: works
• tools only: works
• full Hermes system block: fails with extra-usage 400

A local isolation script showed:

• baseline -> OK
• cc_only -> OK
• tools_only -> OK
• soul_only -> extra-usage 400
• both_system -> extra-usage 400
• soul_plus_tools -> extra-usage 400

Later inspection showed the failing "SOUL block" was actually a ~30k combined system block containing:

• SOUL.md
• memory guidance
• session-search guidance
• skill-management guidance
• platform/media instructions
• other prompt-builder text

So the actual trigger is the assembled Hermes system prompt on the OAuth path, not only the profile SOUL file.

3. A sanitizer workaround restores local end-to-end success

A local workaround in agent/anthropic_adapter.py rewrites several Hermes-specific prompt phrases before sending OAuth Anthropic requests.

After applying that patch, a local end-to-end Skippy turn through the resolved runtime bundle succeeded again:

OK.

Why this should be fixed upstream

This is not just a one-off local profile problem.

Hermes currently injects a large, Hermes-specific system prompt into the Anthropic OAuth / Claude Code path. On at least some Claude subscription / proxy routes, that prompt shape appears to get misclassified server-side as requiring extra usage, even though simple Anthropic Messages requests with the same auth work fine.

That makes the symptom look like a billing/auth outage when it is actually request-shape dependent.

Proposed direction

At minimum, Hermes should defensively sanitize or slim the system prompt on the Anthropic OAuth path.

Possible fixes:

1. Keep a dedicated OAuth-path sanitizer in agent/anthropic_adapter.py
2. Reduce / rewrite the most brittle prompt-builder phrases before they reach the OAuth Anthropic path
3. Add a regression test covering:
   • direct minimal request succeeds
   • assembled system prompt does not regress into known brittle wording
4. Improve logging so this class of failure is distinguishable from genuine exhausted extra-usage state

Notes

This may be related to the general symptom tracked in #6475, but this issue is narrower and includes a concrete root-cause finding:

• valid OAuth auth
• valid proxy path
• minimal request succeeds
• full Hermes system prompt fails
• sanitizer workaround restores success