How usage is measured

The coding plan has no message counting and no per-request slowdowns. Everything runs at full speed. This page explains how the allowance works and how each model draws on it.

The allowance: window, week, bank, month

• The 5-hour window. A window starts with your first request and lasts 5 hours. One window can use up to a fifth of your weekly allowance, so a focused session goes a long way.
• The week. Your weekly allowance resets at the same day and time every week. Your dashboard shows the exact time.
• The bank. Each day, whatever you left unused of that day's share of your week moves into your bank, up to ten days of it, so you can watch it grow. Once a week's allowance is used, the bank keeps you going, and it also keeps a window open after the window's own share is spent. The bank never decays and carries across renewals.
• The month. Your plan's total for each billing period, renewing with your plan. Running flat out every single week can reach it a few days before renewal; the floor below carries you to it.
• Full speed, always. Every request runs at full speed. Reach a limit and the response names it (window, week or month) and exactly when it lifts.
• The near-endless floor. Six models, deepseek-v4.1-flash-1017, deepseek-v4.1-flash, glm-5.3-flash, mimo-v2.6-flash, deepseek-v4-flash-0731 and deepseek-v4-flash, ride a separate always-on floor on every plan, a few requests at a time. Even with the window, the week, the bank and the month all spent, they keep answering at a steady pace.

How models draw on your plan

There are no multipliers to memorize. Each model draws on your allowance at its per-token rate, at a discount of roughly 25% from the prices listed on the models page. Combined with usage banking, heavy use ends up significantly cheaper on the coding plan than the same work at pay-per-token rates.

Because rates differ per model, your allowance stretches differently depending on what you run. The plan page's "up to X million tokens" figures are based on a mid-weight flagship (the 1.00x row below). Relative to that:

Reading it: a million tokens on glm-5.3-flash draws about a third of what the same million draws on glm-5.2, so the plan's headline figure roughly triples on it. kimi-k3 draws about 6.5x faster, which is why it carries the heavy-usage note wherever it appears. Rates are blended for typical coding traffic (mostly input, some output) and shift slightly when we reprice models; the models page always has the current per-token prices.

Where to see your own numbers

Your dashboard is the live answer for your account: four lines (this window, this week, your bank, this month), each with the time it resets, and one line naming whatever limit is next. Plan keys can also call GET /v1/usage for the same numbers as JSON: the meter object carries window (percent_left, open, resets_at), week (percent_left, resets_at, bank_covering), bank (days, cap_days), month (percent_left, renews_at), plus available_now_percent_of_window, limited_by, walled, resume_at and a plain-language summary. Every plan response also carries them as headers (X-PGS-Window-Left, X-PGS-Week-Left, X-PGS-Bank-Days, X-PGS-Month-Left, their reset times, and X-PGS-Limit). Turbo variants route with priority at a higher rate; on plans we recommend the standard ids.