Skip to content

Session limit blocks the Agent SDK while the desktop app on the same account is at 62% #104738

Open

Description

@nikolailehbrink

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 status shows authMethod: claude.ai and the same account and organization as the desktop app.
  • ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, CLAUDE_CODE_OAUTH_TOKEN and CLAUDE_CONFIG_DIR are 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

  1. 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.
  2. Run a long Agent SDK job on the subscription login (here claude-opus-5-5 with --effort=max) until it reports the session limit.
  3. 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-sdk 0.3.309
  • Desktop app: 3.6556.2 with Claude Code 2.1.308

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Activity

  1. Ben-Home commented on Oct 29, 2026

    @Ben-Home

    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:40am across 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 status does 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions