Headless `claude -p` reports "You've hit your session limit" while the account is at 11% and the parent session works

Summary

Every request made through the headless claude -p CLI fails with You've hit your session limit, while the Settings > Usage panel for the same account shows 11% of the current session used. A parent Claude Code session running on the same account and the same machine (via the Agent SDK) continues to work normally with the same model at the same moment.

This breaks any workflow that shells out to claude -p — for example delegating a step of a task to a different model.

Environment

• Claude Code CLI: 2.1.159
• Claude Agent SDK: 0.3.227
• macOS 27.0.0 (Apple Silicon)
• Plan: Max (5x)
• ANTHROPIC_BASE_URL=https://api.anthropic.com (default)
• No ANTHROPIC_API_KEY set

Reproduction

From any directory, including one outside any project:

cd /tmp
echo "Reply with only READY." | claude -p --model claude-opus-5

Result:

You've hit your session limit · resets 3:50pm (Asia/Tokyo)

At the same moment, Settings > Usage reports:

• Current session: 11% used (resets in 2h 1m)
• Weekly, all models: 26% used
• Weekly, Fable: 4% used

And the parent Claude Code session — same account, same machine, same model (claude-opus-5) — is running without any limit error.

What I ruled out

• Not project-specific: reproduced from /tmp, outside any repository.
• Not caused by a custom endpoint: ANTHROPIC_BASE_URL is the default.
• Not a stale process: reproduced with a freshly spawned CLI process.
• Not model-specific in the sense of a single bad model id: see the second symptom below.

Second symptom, possibly the same root cause

claude -p --model claude-fable-5 fails with:

Usage credits are required for this model.

while the same Settings > Usage panel displays the notice "Fable 5 は引き続き Max プランに含まれています" (Fable 5 is still included in the Max plan) and shows Fable at 4% of the weekly allowance. The notice tells the user to restart Claude Code when this message appears, which suggests a known client-side staleness issue.

This part looks related to #78610, #78611 and #78614. I am filing separately because the primary symptom here is the session limit error in headless mode while the same account is demonstrably under its limit and the parent session works — which those issues do not cover.

Impact

Any automation that spawns claude -p as a subprocess is blocked, even though the account has ~89% of the current session budget remaining. There is no way to tell from the error whether the limit is real, so the caller either waits for a reset that is not needed, or has to fall back to a different provider.

Expected

claude -p should reflect the same limit state as the interactive session on the same account, and should not report a session limit when the account is under it.