Usage and Quotas

The overview separates Usage limits (quotas) and Consumption into two tabs. In vord you open it from the toolbar. The popover has an Open in Window button in its upper-right corner; it opens usage in its own freely resizable window, which is also listed in the Window menu. The vord popover adapts its size to the window and the screen. Longer content and opened source details scroll inside the view; the header and tab choice stay reachable.

Quotas

The Usage limits tab opens with one overview line. It counts accounts as free, stopped, and paused. Free includes an account marked Next. Stopped covers your own limit, a provider limit, and Blocked. Paused is only an account you paused. The same line is the legend: consumed is the filled bar, your limit is the mark on the bar, Reserve, not for new sessions is the hatched part above your limit, and halted is a bar that has stopped new work.

A provider with two or more accounts gets its own section, titled with the provider name and a count such as 2 accounts. A provider with exactly one account, and pools such as OpenCode Go or the MiniMax Token Plan, share the section Other providers, subtitled one account or shared pool each. Cards in one section are the same height: the window area follows the card with the most windows, and the header, status line, and footer stay fixed. A failed save adds an error line under that card only.

Each card has a header, a status line, one bar per reported window, and a footer. On a card with an own limit, a note adds that project leads are not held by the limit, but their usage still counts toward it.

The header shows the account name, the plan when the provider reports one, and one status pill. The account name is the account’s slot, the short name you gave it when you connected it (mandr for ~/.claude-mandr). The default account keeps the part of its email before the @; if another account of the same provider already has that name, the default one reads rico (default). Below the name, the card shows the provider and the email, so two accounts with the same email prefix stay easy to tell apart. A pool card (OpenCode Go, MiniMax Token Plan) shows the plan as its title and via OpenCode below it; a plan badge that repeats the title is hidden. In vord, a protected account also carries a Protected badge with a lock next to its name. Its tooltip says whether the account is held in reserve until its reset approaches or is Spending down before its reset. While an account’s own weekly limit is released before its reset (see below), vord adds a Limit released badge with a flame. The pills:

Pill	Meaning
Free	Nothing is blocking new work on this account.
Your limit reached	Usage on a window has reached the limit you set. No new session starts on this account until you choose another account, raise the limit, or the window resets.
Provider limit	A reported window is fully used at the provider, whether or not you set a limit.
Paused	You paused the account. The status line says Paused by you. No new sessions start here.
Blocked	The saved limits could not be read, or a window that has a limit has no current measurement. The status line names which.

A window title is plain text from its length: 5 hours, Day, Week, or Month. A model limit keeps the model name, and a weekly model window reads like Fable · Week. A window with no length keeps the provider’s own label. A missing number is —, not 0 %. The fill is what is consumed. Your limit is a mark on that bar, and the part above the mark is hatched.

The footer lists up to two running sessions. With none it says No sessions running here right now. The count reads No sessions, 1 session, or N sessions, and N more when further sessions are hidden. Limits opens the editor. Done closes it. A pool card has no Limits button. OpenCode Go and the MiniMax Token Plan are pools.

Usage limits per window

Limits edits the card in place. Each window has its own switch. Off shows No limit. On shows Stop at N % and a slider from 5 to 95 in steps of 5. Turning a window on starts at 80 %. The arrow keys move the same steps. The slider is saved when you release it. The switch is saved immediately. A model window is captioned Model limit, blocks the account: that one limit blocks the whole account, not only that model. While you edit, the status line says No new sessions start here once your limit is reached. Running sessions finish.

An account that only reports approximate values (≈) cannot take a window limit. The window switches and the slider stay off, and the status line says Limits need exact usage values. This account only reports approximate values (≈). Pause account still works. A window limit already stored on that account still blocks it, because those approximate figures are not used as the measurement.

Pause account sits in the footer while you edit, with No new sessions, however much is free. Pause is checked before any window. Done leaves the editor.

With the internal account features unlocked, vord adds a Release before reset switch with a flame to the Week row once that window has a limit. It is set per account. When it is on, the account’s own weekly limit stops counting during its spend-down window, the configured working hours before the weekly reset, so the rest of the week’s quota can be used up. The card then shows Limit released. Pause and the limits on the other windows keep applying, and so does the provider’s own limit.

The limit is that window’s usage on the subscription, including work outside this app. Usage is rounded to a whole percent before it is compared with the limit. 28.5 % counts as 29, so a limit of 29 is already reached. Codex is identified by the occupied workspace from the official sign-in: a personal plan and a business plan on the same email keep separate limits; two slots of the same occupied workspace share one limit. A Codex slot without an occupied workspace ID keeps its own limit.

From the limit, or while the account is paused or Blocked, no new session starts on that account and the next job the app itself sends stays held, including an explicit pin. In vord that hold covers the composer, app-mediated mesh messages, child reports, Jobs, the board, and automatic follow-up work. A session already running may finish, and a real permission or choice-box answer may still go through. While a turn is running, the next follow-up stays held until that turn ends whenever the account is paused or has any personal limit. A vord session whose turn has already ended, and which stays 🟢 only because a background command is still running (Claude’s “1 shell still running”, a Monitor, a Grok watcher), does not count as mid-turn here. Its input box is free, so a follow-up such as a child report goes through as soon as the regular limit check allows it. A session that has just started and has not received its first prompt yet does not count as mid-turn either, even while its tile shows 🟢 during startup: its first prompt goes out as soon as the regular limit check allows it. Typing freely into a native terminal stays outside this hold. vord does not move a new start to another account on its own: the start is held, and the work stays visible until you choose another account for it. An account with its own limit but no measurement stays blocked until it is measured again.

Held work stays in the app. A fresh valid measurement of the blocked window can release it once. Raising the limit, or clearing the pause, retries work already in that queue. A provider reset by itself does not reopen the account. Running sessions are not switched silently. What happens to automations and child deliveries once your own limit is reached is described under Usage brake.

Every window with a limit needs a measurement of that window from the last five minutes. A missing, invalid, or older figure blocks the account and the pill says Blocked. When that window is no longer one of the bars on the card, the status line offers Remove limit, which clears the stored limit. A window that is still listed stays Blocked without that button until a fresh measurement arrives. On an account that only reports approximate values (≈), the limit editor is locked, so Remove limit appears for any stored limit that blocks the account. A measurement taken before a reset that has already passed counts as outdated until a fresh one arrives. If the saved limits cannot be read, the status says Saved weekly usage budgets could not be read. New starts and next requests stay blocked until the saved limits are repaired. There is no fallback that treats them as allowed.

An older weekly budget is kept the first time the new store is read. 0 pauses the account. Any other saved percent becomes the limit on Week, even when it is not a step of 5. The slider itself only offers 5–95.

vord measures the official quota of kimi and Grok in the background only while it is needed: when the agent is allowed as a child agent (Settings → Agents → Allowed child agents), while a session of that agent is running, or while the usage dashboard is open (opening it measures right away). For an agent that is not allowed, has no running session and while the dashboard is closed, there is no background measurement, so no reports no quota notice and no failure entry in the event log from it either.

If the measurement for a window with a limit is missing or older than five minutes, vord requests a fresh one right away (at most once a minute per agent) and releases the held work as soon as it arrives. Automatic deliveries that are held — a child’s first prompt, reports, mesh messages, Auto-Pilot — no longer open a dialog; vord records them in the event log. A dialog appears only for your own send or session-start action. It names the blocked account and, for a request, its session; shows usage, your limit, any known reset, and whether the message was not sent or the session did not start. If another ready account is available, Switch to … and restart pins it and restarts the session, while Change limit… opens the Usage limits tab. Agent-initiated MCP send and send_to_agent calls do not open the dialog and receive an English rejection instead.

Caution

This is the app’s own reserve on the windows you limited. The usage brake below decides what happens once that reserve is hit.

Usage brake

Each agent account can have its own usage limit (“own limit”, for example 50 % of the weekly window), so accounts you also use elsewhere never accidentally reach their weekly limit. When an account reaches that limit, the usage brake holds back automation instead of letting it burn more quota.

Under Settings → Agents → Automation, When an account reaches its own limit sets the usage brake. It stops new starts on that account. Choose Hold until released or Continue running for running sessions.

Held, by kind: child reports, child starts, child first prompts, messages to children, auto-pilot answers, auto-continue, jobs, mesh messages, board answers, other. What you type yourself is never held.

When a held send_to_parent report or lead_send_prompt is blocked by a personal weekly limit, its sender receives held_by_usage_brake with the account and usage details; the delivery remains queued until release or a safe account move.

When the limit holds a session’s first prompt, vord tells whoever started it once — the parent session, or the project lead that started it — naming the account with its usage and limit. The tile then leaves 🟢 and shows ⚪ with the brake badge until the prompt goes out.

After the release — a window reset or a changed limit — vord delivers everything held automatically. Child reports then note how long they waited, and waiting child starts launch on their own.

When usage can’t be measured

The brake needs a measurement to check a limit against. A limit exists only if you set one; an account without a limit is never held because of a missing measurement. For an account with a limit, three cases differ:

• The provider reports no plan quota. Some accounts, such as a free tier without a coding plan, answer the usage query with no quota at all. The card says <agent> reports no plan quota (no coding plan?). Your limit doesn’t apply. Nothing is held, you get one notice (<agent> reports no quota) per account, and automatic model selection prefers other accounts of that agent. If every account of the agent reports no quota, the agent is only softly deprioritised: it is skipped as long as another provider remains, and never excluded outright. The state ends when the provider reports windows again.
• The measurement is temporarily unavailable. The card says Usage can’t be measured since <time>. Automations wait. For weekly and monthly windows there is a 60-minute grace: if the last measurement is at most 60 minutes old, its window has not reset, and it still left at least 5 points of headroom under your limit, vord keeps working on that figure. Otherwise (and always for 5-hour and model windows) the account is held, with one notice per episode: Usage of <account> can’t be measured.
• Measurement is off for the account. Without a measurement source (for example OpenCode, or Claude and Codex without an official status), the card says Limit can’t be checked: usage measurement is off for this account. The hold and the actions are the same as above, with one notice: Limit for <account> can’t be checked. A new limit can only be set on an account that has a measurement source; the field is disabled with that hint otherwise.

While a hold from the last two cases is active, the usage card offers three actions: Measure again (or Open account settings when measurement is off), Suspend limit for 24 h, and Remove limit. A suspended limit shows Limit suspended until <time> with Resume limit; after 24 hours it applies again by itself. Agents that try to start a child on such an account are told the start was refused and what to ask you for.

You can switch a session to another connected account yourself by clicking that account in the session’s account menu. The usage-brake popover can also offer Move now when another account is available.

Project leads

Project leads are exempt from your own limit and from the usage brake: reaching an own limit does not hold them. Their usage still counts toward the account’s windows, so other sessions on the same account can be braked earlier.

At the hard provider limit, the project lead stays on its account. vord shows the limit and its reset time, then waits. If Auto-Continue is enabled (off by default), vord continues after the reported reset time. You can switch the session to another connected account by clicking that account.

Badges and notifications

While the brake holds, the session tile, the compact card, and the child row carry a short badge: %d waiting, 50 %, paused, not measurable, or measurement off. A parent whose own account is not at its limit shows the badge too when one of its child starts waits because every account of that agent is; the badge then names that account. Click it for a popover with the reason, the window, free in …, the list of waiting kinds, the Move now button (when a move is possible now or at the next safe point), and two more buttons: Deliver once delivers what is waiting right now while the brake stays active (shown only while something waits), and Change limit… opens the limit editor.

Exactly one notification per account episode goes to the top session’s inbox (and, by the usual rules, as a Mac banner and iPhone push): Usage brake: <account> is holding automation. After the release comes Usage brake released: <account>, with N held deliveries caught up when something was actually caught up — deliveries made with Deliver once do not count. With Hide names in push on, the push carries no session name.

On the paired iPhone, the session row carries the same short badge. Guests of a shared session never see it.

How vord spreads child sessions across accounts

vord measures the load per pool, the billing unit a child session runs on. For Claude, Codex, Grok, Muse and Kimi every account is a pool. For OpenCode every access path is a pool of its own, for example the MiniMax Token Plan (minimax-coding-plan/…) and OpenCode Go (opencode-go/…); the remaining catalog models share the rest pool other. For each pool, vord checks three things: busy means three or more sessions are working on it or have just started; over pace means its usage is more than 10 percentage points ahead of the share of its usage window that has passed (for example, 40% used 15 minutes after a weekly reset); and limited means the provider reported a limit. With OpenCode the load is counted per pool, not for the whole account. A pool that contains an orchestrator model is a fallback pool, and a provider is only marked FALLBACK when all of its pools are fallback pools. Automatic model selection puts busy and over-pace accounts behind the others, and accounts that report no plan quota behind those with a quota.

If you start a child with an explicit agent and model, vord checks the target pool — for Claude, Codex, Grok, Muse and Kimi the account it picked for that provider, for OpenCode the pool the model belongs to.

• The target pool has no headroom: vord refuses the start with ACCOUNT_LOAD.
• The target pool is a fallback pool while a pool without orchestrator models has headroom: vord refuses with FALLBACK_POOL. Fallback pools stay reserved for that overflow.

The refusal names at most five alternatives, at most two per pool: only models from the current catalog, never orchestrator models or models without suitability data, and never the target pool itself. Pools without orchestrator models come first. When there is no alternative at all, the start runs anyway (overflow). An agent can still insist by giving a one-sentence reason with load_override_reason; the override is logged.

The agents’ delegation context lists every pool with its verdict (available, over pace with the reason, busy, limited or not assessed), its load as n/3 and whether the pool is a fallback pool; providers without FALLBACK come first. The event log records the model, thinking level, account, pool (the access path for OpenCode, otherwise -) and origin for every child start. A refused start carries its code — ACCOUNT_LOAD, FALLBACK_POOL or POOL_EXHAUSTED — and an override with load_override_reason is marked. This helps prevent agents from all choosing the same freshly reset account at once and using up a weekly quota within minutes.

Claude Pro and Max report their 5-hour and 7-day windows after the first answer. Codex provides the windows from its local rollout files. Kimi and Grok use the provider queries described below. OpenCode Go usage is queried with the API key in that account’s local OpenCode sign-in. The key must be valid for this usage endpoint; an OpenCode Console login lets Go models keep running, but it does not provide usage data. If OpenCode rejects the key or the account has no API key, the usage card explains this and points to the OpenCode Console, where current usage is available. Muse reports its subscription quota (5-hour window and week) only after a request: vord measures it with a tiny request of its own, at most every 30 minutes while a Muse session is running or the usage dashboard is open. Cards older than 60 minutes show the measurement age instead of percentages. Until then the quota stays unknown. Token consumption is read from Muse’s session records either way.

Kimi and Grok

If Grok permanently rejects renewal (for example, with invalid_grant), old quota figures disappear. The app asks you to sign in again; until then, the account is marked unavailable in delegation context and model selection, including the native default account. Temporary follow-up errors do not lift this restriction. Further quota queries wait until the sign-in file has visibly changed; a successful measurement also lifts it.

vord queries Kimi and Grok quotas through the same provider route that each CLI uses for its usage display. They read the existing local CLI sign-in. If the access token is about to expire, they renew it with the refresh token and write the renewed token fields back to the CLI sign-in file using the same locking and file semantics. Grok uses exclusive flock on the sibling file auth.json.lock. If the lock cannot be acquired within two seconds, the sign-in remains unchanged and the query reports a temporary error. After acquiring the lock, the app rereads auth.json and keeps any sibling tokens already renewed; otherwise, it atomically replaces only the three token fields in the latest file. Kimi continues to use its CLI’s lock directory. No separate vord sign-in is needed.

With the default configuration, only these hosts are contacted:

Anbieter	Kontingent	Token-Erneuerung
Kimi	api.kimi.com (/coding/v1/usages)	auth.kimi.com (/api/oauth/token)
Grok	cli-chat-proxy.grok.com (/v1/billing?format=credits)	auth.x.ai (/oauth2/token)

Kimi requests do not use a fabricated User-Agent. Grok keeps the provider-required cli client mode, but identifies itself as vord in the User-Agent. If a temporary query fails, the last successful measurement remains visible with its original timestamp; an expired sign-in is shown as expired. At least 60 seconds separate query attempts for the same account, including after HTTP 429, network timeouts, or other errors. The regular query runs every five minutes; failed calls do not bypass the minimum interval.

Before model selection and delegation context are prepared, the app also waits for any ongoing query for the same account. After ten seconds, it uses the latest available data and logs the timeout; a later response still updates the display. This budget applies per account and matches the request timeout of KimiUsageClient and GrokUsageClient (ten seconds each).

Quotas are available in the dashboard and delegation context regardless of internal enablement. Automatic model selection receives only percentages, window lengths, and reset times. Access and refresh tokens are never passed to model selection, an agent, or the vord server.

In vord on Mac, a Kimi, Grok, or Muse account that changes from a known signed-in state to a state that needs sign-in again creates one Account signed out inbox entry and a device-routed phone push. The first status observed after launch does not alert because vord has no previous state to compare. A successful measurement clears the signed-out state, so a later sign-out can alert again. Sign in again on the Mac; this alert is account-wide and does not repeat for each session.

For Claude, vord measures usage with its own Usage login per account. When Anthropic rejects that login, vord creates one Usage login expired inbox entry for the account, also right after launch if the login is already expired. Your normal Claude Code sign-in is not affected; only the measurement stops. Connect Usage again for that account (see Agent accounts). After the sign-in tile reports Sign-in finished, vord takes the login over; the usage card shows whether it worked.

MiniMax Token Plan

If you signed in to the MiniMax Token Plan in OpenCode (opencode auth login, provider MiniMax Token Plan), the overview shows a separate MiniMax Token Plan entry right after your OpenCode account. It is a subscription of its own, so it is measured and shown apart from OpenCode Go, OpenCode Zen and local Ollama models. The entry shows the rolling 5-hour window and the weekly window with the used share and reset time.

The numbers come from MiniMax’s documented usage query. vord asks it about every five minutes with the key from your existing OpenCode sign-in; the key is only sent to MiniMax and never written to logs or given to an agent. Without that sign-in there is no entry and no request. A pay-as-you-go MiniMax key is never used. If MiniMax does not answer, the entry says so instead of showing a number.

Automatic model selection uses the same measurement: a MiniMax model is only chosen automatically while the plan has measured headroom, and not at all from 90 % of a window on, because MiniMax would otherwise draw purchased credits. A usage limit hit on a MiniMax model blocks only that pool: minimax-coding-plan/* models are excluded while opencode-go/* models on the same OpenCode account stay startable. More generally, a model prefix is blocked for delegated starts when its access-path pool reports a non-model usage window at 100% with a known future reset. The block remains until that reset even if the measurement is stale; a fresh lower measurement replaces it. Only matching model prefixes are affected. A stale full window without a known reset is unknown and does not block.

Measurements older than 60 minutes count as stale; their percentage is hidden. The account hover in vord also shows the plan, if the provider reports it.

Consumption

The Consumption tab is a cockpit for the verified local totals. Choose 7 days, 30 days, or 90 days, and filter with All providers or one provider chip. Providers that have no usage in the indexed days do not appear as chips.

Four tiles share the same height:

• API value — the dollar figure, and how it compares with the previous period of the same length.
• Tokens — the total, and the share read from cache.
• Sessions — the count, and the average per session.
• Average per day — the daily average, and the Peak day.

API value per day, by provider stacks one bar per day. By provider and account shows each provider’s amount, its share of the total, tokens, and sessions. Projects (by API value) and Most expensive sessions are two rankings for the same period. What the tokens are made of splits Cache read, Cache write, Input, Output, and Reasoning. Reasoning stays its own slice here. In the older source totals, reasoning tokens are already inside the output and are not added a second time to a request’s output count.

Cache read sums the cache tokens read across requests. It does not describe the size of one context. Cache write stays separate, even when a write has no pricing basis. Project names are the known project names; the full path is available where the ranking shows it. Rankings do not shorten the totals: every included contribution in the period is in the tiles, the daily chart, the account list, the top projects, and the token mix. Most expensive sessions is the only top-N ranking in this tab; it keeps up to seven rows for the same period and never reduces the totals shown elsewhere. The same numbers apply to vord and the iPhone or iPad mirror.

Above the cockpit, Verified sources and Excluded name how many sources count. The line Amounts are API list prices, not your subscription bill. is the meaning of every dollar figure on this tab. A missing price stays marked partial amount, or as a dash when no amount can be determined. Neither mark means $0. Empty periods say No usage in this period.

Which sources count?

Above the cockpit you see the number of verified and excluded sources. A source corresponds to a provider profile, for example Codex in the “default” profile. Only fully verifiable sources flow into the displayed sums. If reading fails or proof of stored legacy values is missing, the affected source is excluded from all project, session, and day values. Its stored data is kept for a later recheck.

Under Sources and calculation details you find the individual sources, shared account directories, concrete read errors, and missing pricing bases. These details can be expanded. If multiple accounts point to the same physical session folder, it is counted exactly once; additional profiles name the account they share the source with.

During the initial read, progress and source status appear; without a previously completed state there is no ranking. On a recheck, by contrast, the last successfully verified sums remain visible. The row Rechecking: x of y files makes the ongoing reconciliation clear without hiding these last-known-good values. An older stored state without explicit verification proof stays hidden. After completion, a verified subset may appear even if individual other sources remain excluded.

When a CLI itself deletes older, already counted transcripts, their consumption is kept in the sums. The view names the count separately. This is neither a read error nor a reason to exclude the source; current read errors remain excluded.

Data sources

vord reads the already existing local data of the CLIs:

Provider	Local consumption source
Claude	Project and session files; the official statusline adds quotas, model, context, and reported costs. vord takes a statusline update right away when the model, the whole-percent context or quota values change; otherwise it refreshes at most every 30 seconds, so a session’s reported cost can lag by up to 30 seconds.
Codex	Rollouts in sessions and archived_sessions of the respective account directory. Other files in the Codex directory are not part of the consumption data.
Kimi	Local wire and session recordings under the respective Kimi account directory.
Grok	Local session updates under the respective Grok account directory.
OpenCode	The local SQLite databases with token counters and reported amounts: opencode.db (OpenCode 1 and 2) and vord.db, where the sessions vord runs on OpenCode 2 are stored.
Muse	Muse’s session records (token counters). The subscription quota comes from a small measurement request (at most every 30 minutes while a Muse session runs or the usage view is open; cards older than 60 minutes show the measurement age).

The first run covers at most the last 90 days. A background process reads the sources incrementally; later changes are processed incrementally. The index stores consumption data, no prompt or response texts. The background index writes only what changed; an active OpenCode database is read at most every 30 seconds and once per rebuild, and a rebuild keeps progressing while files change, newest first. The index stores its data in a compact format; when an updated vord opens it for the first time, it converts the file once without a full rebuild, and the last verified sums stay visible. The index removes its own old backup files after 14 days.

A read error receives a new full verification attempt. If it persists, the source is excluded. A transcript deleted by the CLI or a missing OpenCode database does not, after a parser fix following this attempt, trigger a full rebuild on every further app launch; the last state or the error notice is kept. The ongoing activity of other sessions therefore does not start an endless rebuild. A later independent re-evaluation — for example after an account switch or a parser fix — can lift the exclusion after successful verification. Repetitions of the same diagnosis do not create a new warning per run.

Parser fixes affect only the providers actually changed: Claude, Kimi, OpenCode and Muse currently stay on revision 1, Codex on revision 2, and Grok on revision 3 (because a Grok turn the user interrupted and that carries no usage record is no longer treated as a read error, like a cancelled turn). When a price list changes, the last verified sums remain visible while vord re-evaluates the stored pricing bases; local recordings are not read again. The basis contains the model, service tier, inference region, and the short- or long-context tier resolved during the initial read. An empty service tier retained from older bases, or an empty inference region, then means the default path just like a missing field; the stored key identity is nonetheless kept. If the request size is missing for a model with tiered pricing, the index records that too and estimates no amount for it. Old index rows without this basis are read again once, in a targeted way, and then carry it as well. If something is later appended to such a legacy file, vord reads that file once fully, instead of mixing old and new contributions. A pricing run does not start a full source rebuild. In a mixed file, it evaluates backed older cost rows but leaves a basis-less sister row alone if a full read could reset newer costs. The newer state can later safely read this legacy row completely. Legacy rows without a pricing basis and without a price-list date otherwise wait for an append or the next global price change instead of being rechecked repeatedly.

For Claude, an unset or unreported inference region (not_available, empty, or missing) is estimated as the global default path at the standard rate. If the transcript reports us, the US-only surcharge applies. If a request was actually processed US-only without the transcript reporting us, its real price is ten percent above the estimate.

If a provider later changes the boundary between short and long context, an old request cannot be retroactively assigned to a different tier: the index preserves the tier valid at the time of the initial read. A missing model, plan, or tier basis remains visible as a partial amount and is never guessed.

Very large or faulty consumption records do not produce invented values. If a possibly relevant record cannot be fully evaluated, the associated source stays excluded. A locked OpenCode database is treated the same way. Stored legacy values are not presented as freshly verified.

Note

An already set-up Claude statusline is passed through. Sessions with an explicitly specified --settings receive no additional statusline entry from vord and can therefore remain without quota measurement.

Meaning of the dollar amounts

Label	Meaning
reported	The CLI reported the amount. This value can also be an estimate.
estimate	Equivalent at known API list prices with the stated price-list date.
partial amount	Only the known partial amount. Missing model or plan bases are listed in the calculation details.
—	No reliably determinable amount; the dash does not mean $0.

The amounts are not invoice amounts and not a billing of your subscription. A missing pricing basis is not guessed. Verified token counters can therefore be visible while the associated dollar amount is missing or explicitly appears as a partial amount.

Context budget: when Claude compacts

Every request re-reads the entire context of a session. Without a limit, a Claude session grows to nearly one million tokens, and every further answer at that size weighs heavily on your quota. An analysis of two weeks of real sessions found that most Claude consumption came from requests with more than 300,000 tokens of context.

vord therefore sets the compaction point by session role. A vord session you start yourself holds your working context — compacting it early loses that context. Children started by an agent are short-lived and focused, so a smaller budget saves quota. Replaying two weeks of real session histories, compacting at 300,000 tokens brought Claude usage down to roughly 71 %.

In vord, the two rows live under Settings → Agents → Models → Context budget:

Setting	Covers	Default
Main sessions compact at	Sessions you start yourself. Automatic lets Claude use the model’s full context window.	Automatic (default)
Child sessions compact at	Sessions started by an agent (spawn_agent). A smaller budget keeps delegated work cheap.	300,000 tokens (default)

Each row offers Automatic, 200,000 tokens, 300,000 tokens and 500,000 tokens; the role’s default carries (default). With Automatic, vord sets no variable and Claude Code uses the model’s full context window and its own auto-compact logic; a CLAUDE_CODE_AUTO_COMPACT_WINDOW you exported in your shell yourself stays effective. The setting applies to sessions that start after the change — including a session resumed after an app restart. It affects Claude only; Codex, Kimi, Grok, OpenCode and Muse are unchanged.

Also in that Models card, Claude’s built-in subagents picks the model Claude uses for the subagents it starts itself via the Agent/Task tool: Session model (default), Sonnet or Haiku. With the session model, vord sets nothing and Claude’s built-in subagents keep the session’s model. vord child sessions (spawn_agent) are not affected, and a model an agent chooses explicitly still wins. Like the budgets, it applies to sessions that start after the change and to Claude only.

Codex compacts on its own below 300,000 tokens. There is no comparable setting yet for Kimi, Grok, OpenCode and Muse. Details from earlier in a very long session live on only in the summary after compaction, so vord’s agent instructions require agents to record plans and decisions in files.

Quota data and usage limits

When a session hits a usage limit whose message names no reset time, vord uses the quota windows it already reads for that session’s account to tell when the limit ends — it makes no extra request for this. A reset counts only from a window that is fully used up or, for Kimi’s 5-hour window, from that window’s own reset, and only from the session’s own account. The tile shows such a reset like a stated one, with per quota data, as of hh:mm in its tooltip. Without matching data the reset stays unknown. Details: Usage Limits & Auto-Continue.

Per-account limit memory

An unknown quota state is treated as usable. If vord later detects a usage limit, it stores that state for the specific provider and account slot. Routing cannot immediately select the same account again just because the limited session ended. The record survives an app restart and appears in routing both as the usage limited until … exclusion and as a limited quota pool.

If the provider gives a reset time, the restriction ends then. Otherwise it expires after the applicable wait. A limit on one slot does not restrict other accounts.

Free capacity for the next session

When a limit is reached or a required window is at 85 % usage, Where do you still have headroom? can suggest other connected accounts. The percentage denotes the used share; 0 % means fully free capacity.

The suggestion applies to the next session or message and needs your click. A running session is not switched by it. You can also switch a running session yourself by clicking a different connected account in its account menu.

On iPhone and iPad

The paired companion shows the public state of your Mac. There is no Next pill. Against an older Mac that does not announce the settings channel, limits are changed only on the Mac and the phone has no Limits button and no slider. A current Mac adds Edit limit to the account cards it prepared for editing, so window limits and pauses can be changed from the phone (step by step).

When the Mac sends a card status for at least one account, the phone shows those account cards — read-only against an older Mac. The counts read N free, N stopped, and N paused. Free counts only a free account. Stopped covers Your limit reached, Provider limit, and Blocked. Paused is an account you paused. A provider with two or more accounts is its own group, titled with that provider’s name. Every other account shares Other providers.

Each card shows the account, the plan when the Mac sent one, and one pill: Free, Your limit reached, Provider limit, Paused, or Blocked. Each window is a bar. Your limit is a mark on the bar, and the reserve above it is hatched. With a limit the value reads like 28 % / 80 %; without one it is the percent alone. A card with at least one limit adds the line Project leads are not held by this limit, but their usage still counts toward it. With no windows the card says No measurement yet. The session line says No session running here, or up to two session titles with +N when more are running.

Edit limit opens the account’s editor with exactly the windows your Mac’s limit editor offers for that account: a Custom limit switch per window plus a slider from 5 % to 95 % in steps of 5 (turning it on starts at 80 %), and Pause this account. vord-only, and only when the Mac offers it, Release weekly limit lets the account keep working after its weekly window is spent; while it is active the card shows the Limit released badge. Refresh in the overview toolbar runs the same update as the Mac’s usage-dashboard refresh, and the phone’s provider filter only changes what the list shows on the phone. Every change runs through the same setter as the Mac’s own editor, so it applies on the Mac immediately; a change the Mac rejects (locked, out of range, unknown account) rolls back to the Mac’s value with the Mac’s message. An account the Mac no longer knows says This account is no longer known to your Mac. Guests never get the editor.

When the Mac sends consumption ranges, a control offers 7, 30, and 90. That view has tiles for Cost, Tokens, Sessions, and Peak day, a daily chart by provider, an Accounts list, Top projects, Most expensive sessions, and Token mix (Cache read, Cache write, Input, Output, Reasoning). Each ranking shows up to seven rows.

When the Mac sends no card status, the phone keeps the earlier account cards: quota windows and reset times, without these pills, counts, or the hatched reserve. When it sends no consumption ranges, it keeps the earlier lists: the largest projects and days of the last 30 days. Each of those lists shows up to 20 rows; the project sums are computed from all included sessions beforehand. On that earlier view, the verified source coverage and expandable calculation details also appear.

On the initial read, a running index provides no numeric rankings. A recheck, by contrast, transfers the proven last-verified sums, the progress, and the notice about legacy transcripts deleted by the CLI. A finished state may show the verified sources and names the excluded sources explicitly. An older Mac without the new verification proof provides no shared consumption sums to a current phone. The quota display is independent of this.

The phone does not query any provider directly. It exclusively mirrors the Mac state received over the paired connection. The public overview needs no internal unlock code.

When a value is missing

• No quota data reported: The provider did not deliver a matching quota measurement. This is not a measured consumption of 0 %.
• Reports no plan quota: The provider answered the usage query and confirmed it has no quota for the account (for example a free tier). Your limit doesn’t apply there. See When usage can’t be measured.
• No verified consumption sums: The index is still running or the available state has insufficient verification proof.
• Excluded source: The source details state which provider or profile is affected. Its contributions are missing from all displayed sums.
• Partial amount or dash: Token counters are known, but a pricing basis is missing entirely or in part. The calculation details name the reason.
• Shared source: Multiple profiles use the same recordings. They are counted once under the named owner account.

More information on sign-in and account selection is under Agent accounts.

On the vord iPhone usage card, an account that needs sign-in again is shown as Signed out — sign in again on your Mac. The Mac sends this state for Kimi, Grok, and Muse when it detects a change from signed in to signed out. Claude reports an expired Usage login through the Usage login expired alert instead; Codex and OpenCode do not yet provide a sign-out signal for this alert.