The wire · review · first seen Oct 24, 01:28 UTC

Anthropic adds Claude Code monitors and fixes gateway requests

Claude Code v2.1.310 shipped monitors and a retry for requests rejected by some gateways and compatible servers. For a builder, the immediate question is whether that retry removes a failure in the path they already use.

L0 · primary1 source3 claims checked5 min read

What shipped

The v2.1.310 release notes say the Monitor tool and plugin monitors were added on Bedrock, Vertex, and Foundry, including when telemetry or nonessential traffic is disabled. Long foreground sleeps are now blocked there too. I read this as a specific availability change, not a claim that every monitor behaves the same in every setting. The notes name the environments and the traffic-disabled case, but do not describe monitor output or configuration. Those details matter before making a monitor part of a required workflow. [1]

The request fix targets a narrower failure: some gateways and compatible servers reject the effort-2025-11-24 beta value or mid-conversation system messages. Claude Code now retries without them. That is a shipped fallback, not a statement that the first request always succeeds or that every gateway accepts the retry. If your request path includes a gateway or compatible server, this is the change I would test first against a failure you can already reproduce. The distinction between a retry and an unconditional removal matters when interpreting what the release notes promise. [1]

A separate cleanup fix addresses recent files, including pasted images, being deleted by background cleanup when cleanupPeriodDays is set to a very large value. This is not presented as a new retention policy or a guarantee against every kind of deletion. It identifies one setting and one failure mode. I would treat the fix as relevant to projects that use that setting and keep claims about its reach limited to that case. [1]

Why it matters if you build

A builder using Bedrock, Vertex, or Foundry can now evaluate the Monitor tool and plugin monitors in an environment named in the release notes. The explicit mention of disabled telemetry or nonessential traffic makes that setting worth checking rather than assuming it excludes monitors. There is a workflow constraint alongside the addition: long foreground sleeps are blocked there. If a current procedure relies on such sleeps, do not treat the monitor addition as a drop-in replacement without testing the procedure. The notes give no time savings, resource cost, or monitor behavior to budget around. [1]

For gateway users, the useful test is the original request failure followed by the retry path, not a generic successful request. The notes identify two rejection triggers, and the fallback retries without the material a server rejects. That can change what is sent on the retry, so a builder who depends on either element should inspect their own workflow before relying on the fallback. The source does not quantify how often rejection happens, how many retries occur, or the cost of a retry. I would not build a latency or reliability estimate from this note alone. [1]

For a workflow that keeps recent files around with a very large cleanupPeriodDays value, the cleanup fix is a reason to retest preservation of those files after updating. A pasted image is the concrete example in the release notes. That gives you a focused regression check, not a basis to assume all files or all cleanup settings were affected. If this failure had already disrupted your work, make the check part of your decision to adopt v2.1.310; the note does not supply a recovery procedure for files previously deleted. [1]

How to try it today

1. Check whether your Claude Code version is v2.1.310 before attributing a change to this release.
2. On Bedrock, Vertex, or Foundry, check whether the Monitor tool and plugin monitors are available, including with telemetry or nonessential traffic disabled.
3. If your procedure uses a long foreground sleep there, check its behavior before changing the procedure.
4. If a gateway or compatible server previously rejected a request, repeat that case and check whether the retry succeeds without the rejected beta value or mid-conversation system messages.
5. If cleanupPeriodDays is set to a very large value, check whether a recent file such as a pasted image remains after background cleanup.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Claude Code v2.1.310 adds the Monitor tool and plugin monitors on Bedrock, Vertex, and Foundry.

   per GitHub releases · anthropics/claude-code (L0)
2. shipped L0 · primary

   Claude Code v2.1.310 retries requests without the effort-2025-11-24 beta value or mid-conversation system messages when some gateways and compatible servers reject them.

   per GitHub releases · anthropics/claude-code (L0)
3. shipped L0 · primary

   Claude Code v2.1.310 fixes background cleanup deleting some recent files when cleanupPeriodDays is set to a very large value.

   per GitHub releases · anthropics/claude-code (L0)

What is not confirmed

The notes do not establish what the monitors report, how to configure them, or whether their behavior is identical across Bedrock, Vertex, and Foundry. They also do not give a threshold for what counts as a long foreground sleep. I would not prescribe a monitor-driven operating procedure from this excerpt alone. [1]

The notes do not identify which gateways or compatible servers reject these requests. They do not give retry counts, success rates, additional request costs, or a guarantee that removing the rejected material preserves behavior a particular integration expects. The retry shipped, but its outcome in your path remains a test question. [1]

The cleanup note does not define a numeric value for very large cleanupPeriodDays, say whether already deleted files can be recovered, or establish that every file-retention case is covered. Do not infer those promises from the pasted-image example. [1]

Who should act, who should wait

Move now if you use a named monitor environment, have a reproducible gateway rejection, or have seen recent files disappear with a very large cleanupPeriodDays setting. Test v2.1.310 against the specific path that matters to you. I would prioritize the gateway check when requests are currently failing, because the shipped change directly targets that failure; the monitor and cleanup checks answer different questions. [1][2][3]

Wait before redesigning a workflow around monitor output, relying on retry economics, or changing a file-retention policy solely on this note. The source establishes availability, a fallback, and a fix to one cleanup failure mode, but not the monitor contract, retry overhead, or a broad retention guarantee. You can test the release today without treating those unstated properties as shipped. [1][2][3]

Sources

• v2.1.310 — GitHub releases · anthropics/claude-code L0 · primary