[FEATURE] Public capacity-signal endpoint for automation-friendly off-peak scheduling

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Anthropic has publicly stated that recent session-limit redistributions (notably the March 2026 peak-hours change) exist to manage demand during peak periods. The constraint is real and the goal is reasonable.

The gap: only Anthropic can currently see the load signal. Users running MCP servers, CI pipelines, and scheduled automations have no programmatic way to know:

Whether the current moment is peak, elevated, or nominal load
What the peak window actually is (currently only documented in an engineer's personal X post)
Whether a peak multiplier is being applied to their requests
When the next off-peak window starts
Without this signal, automations can't cooperate with load management. They fire whenever scheduled, hit limits mid-run, and either retry (adding more peak-period pressure) or fail. If the goal is peak smoothing, opacity defeats it — give users the signal and a meaningful share of batch workloads will shift voluntarily. That's cheaper than throttling and materially better DX.

Proposed Solution

A public, unauthenticated endpoint (e.g., GET https://api.anthropic.com/v1/capacity or an addition to the status.claude.com JSON feed) returning:

{
"current_load": "nominal" | "elevated" | "peak",
"peak_window": {
"start": "13:00Z",
"end": "19:00Z",
"days": ["Mon", "Tue", "Wed", "Thu", "Fri"]
},
"multiplier_applied": 1.0,
"next_offpeak_starts": "2026-04-19T19:00:00Z"
}
Rate-limited generously so MCP servers and CI jobs can poll without friction. Response cacheable for 30–60 seconds. Callable from inside Claude Code via an MCP server or a CLI helper like claude capacity.

Alternative Solutions

status.claude.com — exposes component health and incidents, not load.
anthropic-ratelimit-* headers — per-request only; no forward-looking or aggregate signal.
Admin API — historical usage only, not live capacity.
Tribal knowledge (reading engineer tweets) — currently the only source for the peak window; fragile and not machine-readable.
Priority: "Medium - Would improve my workflow" (adjust — lower than Issue 1 because it's primarily useful with better accounting; raise if you disagree)

Feature Category: best fit — likely "API" or "MCP integration"

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

Scenario: I run an MCP server that performs nightly codebase audits across a team's repos. Today it fires at 14:00 UTC because that's when the team's workday starts — squarely in the peak window, eating weekly session allowance faster than necessary.

MCP server polls GET /v1/capacity before initiating each audit batch.
If current_load == "peak" and next_offpeak_starts is within 4 hours, the server defers the batch.
Auditor receives a Slack note: "Deferring 47-file audit to 19:00 UTC to avoid peak multiplier; results by 19:30 UTC."
Audit runs off-peak, uses fewer tokens, doesn't compete with interactive-user demand.
Extends naturally to CI pipelines, scheduled refactors, doc-generation jobs — anything without a human waiting on it.

Additional Context

The peak window (roughly 05:00–11:00 PT / 13:00–19:00 GMT, weekdays) is currently documented only via engineer X posts on March 26, 2026. Moving it from tribal knowledge to a machine-readable endpoint is a prerequisite for automations to cooperate with load management.

Companion feature request: detailed in-session token-accounting breakdown [link Issue 1 URL once filed]. Together: "what should I do differently?" (Issue 1) + "when should I run this?" (Issue 2).