Skip to content
ISSUE 001·LIVE·22:28 IL
← Journal/2026-11-02·8 min·anthropic

Anthropic Python SDK 2.4.0: Spend Limits, Increase Requests and Two New Session Limit Errors

The Anthropic Python SDK 2.4.0 shipped on November 2 with GA admin methods and two new managed-agent session errors. I read the release notes and the type definitions at the tag to see what spend limits, increase requests and the new stop reasons actually say.

By Harel Asaf·AI Builder·Tel Aviv

Anthropic's Python SDK v2.4.0 was published on GitHub on November 2, 2026. Two parts matter for people running agents: admin methods for spend limits, analytics and RBAC are now listed as GA, and managed-agent sessions have two new error types, tool_use_limit_reached_error and compaction_limit_reached_error. Both describe a turn that stopped on a limit, not a failed request.

I read the v2.4.0 and v2.3.0 release notes and the Python source and type files at the v2.4.0 tag through the GitHub API. I did not install the SDK, call any endpoint, or read Anthropic's API documentation. Everything below is what the SDK source says, not what the service does.

What the release notes list

The 2.4.0 features section has six lines:

  • GA methods for analytics, spend limits and RBAC.
  • Named beta types for unified metrics and RBAC delete responses.
  • Shared analytics order and increase request actor types.
  • The two session error types above.
  • Types for analytics group_by and spend limit period filters.
  • user_profile_id on External Keys and Workspaces.

The bug fixes include making spend_limit nullable in the increase request approve response, and requiring "always-sent" analytics fields. The v2.3.0 release, from October 23, added Claude Tag endpoints for Claude Enterprise organizations. That is a separate item and I did not read it further.

Spend limits, as typed in the SDK

The SDK has two trees. Under resources/beta/organization/spend_limits the file defines retrieve, list, delete and set, all against /v1/organizations/spend_limits. Under resources/organization/spend_limits, the non-beta spend_limits.py I opened exposes only two sub-resources: effective (/v1/organizations/spend_limits/effective) and increase_requests. I did not check whether the GA tree gets set elsewhere, so do not read this as a statement about what is missing from the product.

From the beta SpendLimitSetParams docstring:

  • amount is a decimal string in the minor unit of the organization's billing currency. For USD, "50000" is $500.00.
  • amount: null sets "an explicit no-limit override" for that scope and period only. Each period resolves independently, so caps for other periods still apply.
  • Claude Enterprise organizations set user limits. Claude Console organizations set organization and workspace limits. Any other combination returns 400.
  • Setting organization and workspace limits through the API is described as an early access preview.
  • The period type is daily, weekly or monthly.

The non-beta tree also has scope types for rbac_group, seat_tier, usage_tier, organization_service, user and workspace. I saw the file names, not their contents, so I do not say how they combine.

Increase requests

A SpendLimitIncreaseRequest has an id, an actor (who submitted it), created_at, a period, optional resolved_at and resolved_by, an optional spend_summary, and a status of pending, approved or denied. The resource has retrieve, list, approve and deny, and approve and deny live under /v1/organizations/spend_limit_increase_requests/....

The beta approve params take amount (the "new per-user spend limit", in minor units), an optional period, and suppress_notification. Note the wording: the docstring says per-user, which fits the Enterprise user scope. I did not verify how it behaves for other scopes.

The two new session errors

Both types sit under types/beta/sessions and use the managed-agents prefix.

  • tool_use_limit_reached_error: per its docstring, the turn stopped because the agent loop reached its limit on tool-use rounds. One model response that calls tools, plus running those tools, is one round.
  • compaction_limit_reached_error: the turn stopped because the context was compacted the maximum number of times in a row without the model producing a message or a tool call.

Both say the stop is "not because a request failed". The thread goes idle with stop_reason: retries_exhausted, a child thread terminates, and the next user.message starts a new turn. Each carries a message and a retry_status, which is one of three types:

  • retrying: the server retries automatically. The client should wait. The same error may fire again as retrying, then once as exhausted.
  • exhausted: the turn is dead, queued inputs are flushed, and the session returns to idle. The client may send a new prompt.
  • terminal: the session hit a terminal error and moves to terminated.

The docstrings do not give the limit numbers. I did not find them in the files I read.

What I would check

These are my untested suggestions, not documented behavior.

  • If you count errors by type, add the two new types to your handlers before upgrading. A turn that ends in retries_exhausted with no failed request may look like a success in dashboards that only track HTTP errors.
  • Do not auto-send a "continue" message when you see either error. A loop that hit a tool-use limit or a compaction loop may hit it again. Log the session and look at what the agent was doing first.
  • Treat amount as a string in minor units in your own wrappers. A float conversion error here would change a budget by a factor of 100.
  • If you automate approvals of increase requests, keep a human in the path for the amount. The SDK shows that approve can set a new limit, and suppress_notification exists. That is a lot of authority for a script.
  • Pin the SDK version and read the type diff between 2.3.0 and 2.4.0 before bumping it in production.

What I would not conclude

  • I would not conclude the spend limits API is generally available to every account. The release notes say "GA methods", but the same docstring calls organization and workspace limits an early access preview.
  • I would not conclude a particular numeric limit for tool-use rounds or compactions. I did not find one.
  • I would not conclude how billing or enforcement works. The SDK describes request and response shapes only.
  • I would not treat this article as a review of the Claude API pricing or admin console.

Frequently asked questions

What changed in Anthropic Python SDK 2.4.0?

The release notes list GA methods for analytics, spend limits and RBAC, named beta types for unified metrics and RBAC delete responses, two session error types, filter types for analytics and spend limit periods, and user_profile_id on External Keys and Workspaces.

When was it released?

GitHub shows v2.4.0 published on November 2, 2026. v2.3.0 was published on October 23.

What does tool_use_limit_reached_error mean?

Per the type docstring, the agent loop reached its limit on tool-use rounds. It is not a failed request. The thread goes idle with stop_reason: retries_exhausted and the next user.message starts a new turn.

What does compaction_limit_reached_error mean?

The context was compacted the maximum number of times in a row without the model producing a message or a tool call. The stop behavior is the same as the tool-use error.

How are spend limit amounts written?

As a decimal string in the minor unit of the organization's billing currency. For USD, "50000" is $500.00. A null amount is an explicit no-limit override for that scope and period.

Which spend limit scopes can I set?

The beta docstring says Claude Enterprise organizations set user limits and Claude Console organizations set organization and workspace limits, with the latter in early access preview. Other combinations return 400.

Did you run it?

No. I read the release notes and the source and type files at the tag. I did not install the SDK or call the API.

Sources

All read on November 2, 2026.

Not read: Anthropic's API documentation, the analytics and RBAC resources in detail, the scope type contents, the Claude Tag endpoints, and any behavior of the live service.

Related reading

The build log

Follow the work.

New essays and prototypes, in your feed reader. Email subscriptions are paused while I connect a working delivery service. No email is collected here.

Follow via RSS