Pre-emptive rotation

The naive approach to account rotation is reactive: send the request, take the 429, switch accounts, retry. That works, but every reactive rotation costs a round-trip of latency and an Anthropic-side rate-limit increment that didn't need to happen.

Power Claude is pre-emptive: it decides to rotate based on response headers from the previous request, before the next one is sent.

The headers we read

Every Anthropic response includes:

• anthropic-ratelimit-unified-5h-reset — absolute UTC timestamp the 5-hour window resets
• anthropic-ratelimit-unified-5h-remaining — tokens remaining in the current window
• anthropic-ratelimit-unified-7d-remaining — tokens remaining in the 7-day window

After every response, the proxy updates the account's record. Before every send, it asks: will this request fit in 5h-remaining?

The headroom heuristic

Power Claude estimates the request's token cost from message length × an empirical input-output ratio (input tokens are exact; output is bounded by max_tokens and recent averages). If:

estimated_cost > 0.95 × remaining_in_5h_window

…the account is marked cooldown for the remainder of the window and the request is handed to the next eligible account. The 0.95 ratio is configurable via pc config set rotation.headroom 0.95; we recommend not touching it unless you're profiling a specific workload.

Why 0.95, not 1.0

Anthropic's rate-limit accounting has small drift — local estimation cannot exactly match server-side counting because tokenization rules are not fully published. A 5% headroom buffer covers the gap and avoids the case where the local estimate says "fits" but the server returns 429 anyway.

What pre-emptive rotation does NOT do

• It doesn't reduce your total rate-limit budget. The math is identical to reactive rotation; you just don't pay the 429 round-trip.
• It doesn't speculatively pre-warm other accounts.
• It doesn't shift load to accounts you haven't authorized.

Disabling it

If you want strictly reactive rotation (useful for debugging or to confirm the heuristic isn't being overly conservative on your workload):

pc config set rotation.preemptive false

You will see more 429s in events.jsonl, but total throughput should be the same. We have not seen a workload where reactive is faster — the latency penalty of a 429 retry always wins.