Context compression vs plan quota: two different walls people keep mixing up

Two systems, side by side

The names sound similar and both feel like “Claude is running out of room,” but they live in different places and respond to different commands.

The 200K wall is local. The 429 wall is account-wide.

Picture two doors in Claude Code, one in front of the other. The first door is the 200K-token context window. It is the size of one conversation. When this single chat's prompt + response + file context approaches that ceiling, the model can no longer fit everything. Auto-compact triggers; the model summarizes the older turns and the conversation continues with a shorter prefix. A new chat starts at zero tokens, so this door resets every time you run /clear or open a new project.

The second door is plan quota. It does not care how many tokens are in your current conversation. It cares about the total weighted compute your whole Anthropic account has spent in the last 5 hours and the last 7 days, summed across every Claude Code instance, every browser tab on claude.ai, every IDE extension, every machine you are signed in on. Anthropic publishes this as JSON at /api/organizations/{org_uuid}/usage, the same endpoint that powers claude.ai/settings/usage. When the float in five_hour or seven_day crosses 1.0, every further request from your org returns 429 until the bucket bleeds back down.

A new chat does nothing to this door. /clear does nothing to it. Restarting Claude Code does nothing to it. Logging into a different machine does nothing to it. The buckets are server-side and per-account.

The data shape: there is no “context_window” field

Here is the actual JSON Anthropic returns when you, your browser, or a tool like ClaudeMeter calls /api/organizations/{org_uuid}/usage using the cookie session you already have from claude.ai:

Notice what is not there. There is no context_window field. There is no “tokens left in this chat” field. There is no “auto-compact threshold” field. The 200K context window is the model's problem, not the account's, and the account-level quota endpoint genuinely has nothing to say about it. The Rust struct that backs ClaudeMeter has the same shape:

That is the whole data model on the menu-bar side. The 5-hour float, the 7-day float, the per-model sub-buckets, the extra-usage block. Nothing about the conversation length, because conversation length is a different problem solved at a different layer. If a tool claims to show both your context-window position and your plan-quota position in one number, it is doing something synthetic; the server does not return them as the same thing.

The trick everyone misses: compaction itself spends quota

The most common pop misconception about /compact is that it “saves usage” or “extends the limit.” It does neither. Compaction is implemented as another LLM call: the model is asked to summarize the conversation so far, and the summary replaces the original transcript. That summarization call counts against your plan quota the same way any other prompt does. Anthropic states this directly:

You can watch this happen on the server in real time. ClaudeMeter polls /api/organizations/{org_uuid}/usage every 30 seconds (POLL_INTERVAL at src/bin/menubar.rs:18). Trigger a /compact in one window and watch the menu bar in another. The seven_day_opus float ticks up, often by 1 to 2 percent on a heavy conversation, because Opus is weighted more heavily than Sonnet against the weekly cap and the summarization runs on the same model you were using.

The takeaway is not “don't compact.” The takeaway is that compaction is a quota tax you pay to keep the conversation alive past the 200K wall. It is the right move when you genuinely need the earlier turns in summary form. It is the wrong move when you only need the last few turns; in that case /clear and a fresh chat is free against plan quota and free against the context window.

Watching it happen on the menu bar

Here is a real session, two terminals open: Claude Code on the left, ClaudeMeter status on the right. Notice that the server-truth quota numbers move while the local conversation is being compacted, and the move is in the wrong direction for “saving” quota.

The /compact freed 186K tokens of context window, which was real and necessary. It also spent 1.2% of the weekly Opus bucket and 2.7% of the rolling 5-hour bucket on the way. If you only had the context-left indicator to look at, you would think compaction was pure profit. The plan-quota numbers are the half of the picture Claude Code does not show you.

The cache-miss tail that nobody mentions

So which one should you actually watch?

Both, on different timescales. The 200K context window is a per-chat concern; you keep an eye on it inside Claude Code via the “context left” indicator and you act on it with /compact or /clear. The plan quota is a per-week concern; you keep an eye on it via claude.ai/settings/usage or a tool that polls the same endpoint, and you act on it by switching models, deferring work to off-peak hours (Anthropic's peak-hour multiplier on the 5-hour bucket runs 5 to 11 a.m. Pacific weekdays per their March 2026 statement), or topping up extra-usage credits.

The trap is treating one as a substitute for the other. Compacting does not buy you plan quota; clearing does not buy you context; starting a new chat does not reset your weekly bucket; topping up extra-usage does not give you a bigger context window. Each lever moves a different ceiling.

ClaudeMeter is open source and MIT licensed; the relevant code is in src/models.rs (data shape), src/api.rs (the GET to /api/organizations/{org_uuid}/usage), and src/bin/menubar.rs (the 30-second polling loop). It only knows about plan quota, not context window, on purpose, those are different problems and lumping them into one indicator was the original confusion this page is trying to undo. Repo: github.com/m13v/claude-meter.

The honest caveat

The percentage numbers in the example session above are typical for an Opus-heavy refactor session, not a guaranteed measurement; the exact compaction cost depends on conversation length, model in use, and Anthropic's internal weighting which is not published as a formula. The directional claim, that /compact consumes plan quota rather than refunding it, is from Anthropic's own help center. The /api/organizations/{org_uuid}/usage endpoint is undocumented; the published 200K context window and the published 5-hour / 7-day plan-quota numbers come from Help Center articles, not API contracts. The only thing you can fully trust is the float in the JSON, and that is what claude-meter pins to the menu bar.