400 "out of extra usage" on all tool-bearing requests (Pi v0.75.4) — classifier triggers on tools presence, not beta headers

[SiNaPsEr0x]

Environment

• Meridian: v1.42.1
• Client: Pi v0.75.4
• OS: Windows 11
• Auth: Claude Max subscription

Problem
Every request from Pi fails with:

API Error: 400 You're out of extra usage.

Meridian logs confirm routing works (adapter=pi, session=new), but sdk_termination reason=unknown on every call.

Diagnosis steps

1. Stripped anthropic-beta header via reverse proxy (confirmed stripped by request log) → Custom betas stderr warning disappeared, but 400 persists.

2. Plugin onRequest(ctx) does not expose ctx.headers — delete operations were no-ops. The plugin API needs a way to modify incoming HTTP headers before SDK dispatch.

3. Cross-referencing [Bug]: On a Claude Max 20x subscription with a valid OAuth access token from ~/.claude/.credentials.json, every Hermes request to native Anthropic (provider: anthropic, https://api.anthropic.com/v1/messages) is rejected with HTTP 400 NousResearch/hermes-agent#15080: raw API test with same OAuth token shows:

   • tools=false → 200
   • tools=true → 400 "out of extra usage"

   Anthropic's classifier fires on the presence of tools in the request body, independent of system prompt or headers. Pi sends tools=4 on every request → always triggers.

Impact
Meridian's passthrough mode for agentic clients (Pi, Cline, etc.) is effectively unusable on Max subscriptions — not because of misconfiguration, but because the agentic tool pattern itself triggers extra-usage billing server-side.

Questions for maintainer

• Does the SDK query() path send tools in a format that bypasses the classifier (vs. raw HTTP)?
• Is there a no-tool or tool-free mode for non-interactive requests worth investigating?
• Can onRequest(ctx) be extended to expose incoming HTTP headers for plugin-level stripping?

Workaround
None found. Using local model provider.

[spuriousdata]

This only matters for a few more weeks at this point, I think, but I've been using this and it works fine:
https://github.com/lnilluv/pi-meridian-extension

[junha6316]

Additional data point + a workaround that works for us (harness: Hermes via Meridian, adapter=opencode)

Confirming the core finding: the tools-presence trigger reproduces for us too. Setup: Claude subscription via Meridian (oauth-token profile), Hermes routed through 127.0.0.1:3456. Tiny no-tool requests return 200; any real agent turn (tools=29–62) → 400 You're out of extra usage.

What did NOT help (all empirically tested by capturing the real request body and replaying it via curl to Meridian — no need to run the harness):

• MERIDIAN_BETA_POLICY=strip-all — no change
• MERIDIAN_DEFER_TOOL_THRESHOLD raised above tool count — no change
• Forcing base model (patched supports1mContext→false, i.e. no opus[1m]) — no change
• Keyword-scrubbing the system prompt — no change. We neutralized all 58 harness-identity tells (hermes/nousresearch/opencode) and it still 400'd.

Why scrubbing fails — the trigger is holistic, not keyword-based. Bisecting the captured 37 KB system prompt against Meridian:

• generic prompt + 29 tools → 200
• real harness prompt + 29 tools → 400
• first half (0–18.7k) → 400; second half → 200
• narrowed to first ~4.7k chars, but each sub-half (0–2347 / 2347–4695) passes alone while the two together fail.

So it behaves like a cumulative/score-based classifier over system-prompt content — removing individual phrases never drops below the threshold without effectively removing the whole prompt. This matches NousResearch/hermes-agent#15080's "the sanitizer doesn't change the outcome."

What DID work: Meridian SDK Features → for the adapter, set clientSystemPrompt: false (keep codeSystemPrompt: true). i.e. send only Claude Code's genuine preset system prompt and drop the harness's. With that, tools=29–62 requests return 200 from the subscription lane (no overage). Persists in ~/.config/meridian/sdk-features.json across restart.

curl -X PATCH http://127.0.0.1:3456/settings/api/features/opencode \
  -H 'Content-Type: application/json' -d '{"clientSystemPrompt":false}'

Tradeoff: the harness's own persona/rules are dropped (tool schemas are still sent, so functionality stays intact, but behavior shifts toward vanilla Claude Code). For harnesses that genuinely need their system prompt, the only real fix remains enabling/funding extra usage (or the new June-15 Agent SDK programmatic credit).