Repository navigation
Session limit blocks the Agent SDK while the desktop app on the same account is at 62% #104738
Copy link
Copy link
Open
Labels
area:agent-sdkarea:costbugSomething isn't workingSomething isn't workingplatform:windowsIssue specifically occurs on WindowsIssue specifically occurs on Windows
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
On one account, the Agent SDK's Claude Code process was rejected with the session limit while a Code session in the Claude desktop app kept working in the same minutes. The two report different 5-hour windows, although the usage limits article says all surfaces share one limit.
| Time (Europe/Berlin, UTC+2) | Agent SDK process | Desktop app |
|---|---|---|
| Oct 23, 19:49–19:53 | 66 requests rejected, resets 10:40pm |
not checked |
| Oct 24, 00:58–01:02 | 29 requests rejected, resets 3:40am |
requests succeed; usage panel at 01:01: 5-hour limit 62%, resets 01:20; weekly 78% |
| Oct 24, 01:32 | no requests | usage panel: 5-hour limit 1%, resets 06:20; weekly 78% |
- Neither the 01:20 nor the 06:20 reset matches the 03:40 reset the SDK process got.
claude auth statusshowsauthMethod: claude.aiand the same account and organization as the desktop app.ANTHROPIC_API_KEY,ANTHROPIC_AUTH_TOKEN,CLAUDE_CODE_OAUTH_TOKENandCLAUDE_CONFIG_DIRare not set in the user or machine environment.
What Should Happen?
Both surfaces draw from one limit: they report the same usage and reset time, and are either both blocked or both allowed.
Error Messages/Logs
You've hit your session limit · resets 10:40pm (Europe/Berlin)
You've hit your session limit · resets 3:40am (Europe/Berlin)
The SDK returned the message as the query's result text.
Steps to Reproduce
- Sign in to the Claude desktop app and to the CLI (
claude auth login) with the same account, with none of the variables above set. - Run a long Agent SDK job on the subscription login (here
claude-opus-5-5with--effort=max) until it reports the session limit. - In the same minutes, send a message in a Code session of the desktop app and open its usage panel.
Observed on October 23 and 24, 2026; not yet reproduced on purpose.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
No response
Claude Code Version
- Agent SDK process: 2.1.309 (Claude Code),
@anthropic-ai/claude-agent-sdk0.3.309 - Desktop app: 3.6556.2 with Claude Code 2.1.308
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
- Windows 11 Home 10.0.26200. The SDK process runs headless; the desktop session runs in the app's Code tab.
- Related, both closed as not planned: Usage limit discrepancy: Claude Code blocked at "100% used" while claude.ai Settings shows "44% used" on same Pro account #68379 and [BUG] Claude Code shows 'Usage limit reached' despite session at 2% and weekly at 32% #61828 report a session limit that disagrees with the usage panel. Here two Claude Code processes on the same account were blocked and allowed at the same time.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area:agent-sdkarea:costbugSomething isn't workingSomething isn't workingplatform:windowsIssue specifically occurs on WindowsIssue specifically occurs on Windows
Activity
Ben-Home commentedon Oct 29, 2026
The three different reset times are the strongest evidence in the report, and they point somewhere other than the usage panel. A reset timestamp is emitted by the server alongside the limit record, so two surfaces reporting 01:20 and 03:40 for the same five hour window are not reading one shared counter with a display lag. They are reading two records. The repeated
resets 3:40amacross both the 19:53 and the 01:02 rejections sharpens it: the SDK reported the same window boundary across a period in which the desktop panel had already rolled over twice. A record that does not move when the window rolls was probably fetched once and cached for the life of the process.Cheap test for that: leave the SDK process blocked, wait until the desktop panel shows a fresh five hour window, then restart the SDK on the same account and send one request. If the restarted process succeeds while the running one stayed blocked, the limit state is process-cached and the bug is a missing invalidation on the client side rather than a server-side bucket split.
If the restarted process is still rejected, compare the identity the two requests actually carry. The same account and organization in
claude auth statusdoes not prove the same headers, and a request that omits or alters the client identifier can land on a different accounting key. That is the shape which produces a shared weekly number attached to a separate five hour window.Separately, worth filing on its own: the limit message arriving as the query's result text rather than as an error. Any harness that checks for exceptions records a successful completion of zero tokens, and the gap only surfaces later as unexplained missing work. An explicit error flag on the result makes the condition machine-detectable, which is the difference between a job that pauses and a job that silently truncates.