Cost Control
Cost Control is the sidebar surface that puts spending in one place — live AI usage and out-of-pocket cost at the top, and every budget cap below it, all editable inline. Covers where it sits, how its caps relate to the Settings screens that own them, the one-time 2026-09-08 historical-spend repair, and how to hide the row.
What it is
Cost Control is a top-level sidebar surface (in the System group, next to Stats) that puts spending in one place: live spend at the top and every budget cap below, all editable inline. It's the one door for both watching what you spend and managing the limits that keep spend in check — no hunting across separate Settings pages.
What you see
- Live spend (top): your total AI usage and out-of-pocket cost for the current time range, plus a See full breakdown link into the Statistics → Spend screen.
- Sessions & daily limits: the per-session warn/stop caps, the daily per-account warn/stop caps, and the per-metered-vendor daily cap (the same controls as Settings → Sessions — editing here changes the same setting).
- Workflow & automation caps: the default recipe run cap, the nightly-maintenance cost warning + audit-count + concurrency limits, and the automation AI-condition daily cap.
- Per-feature daily caps: the daily spend ceilings for knowledge summaries / image analysis / aggregation, Writer, AI Council, Decks, continuous summaries, the workflow coach, SMS name inference, title evaluation, and Voiceprint Studio.
Where to find it
Cost Control is a surface of its own rather than a tab buried inside Settings — it sits in the System group of the sidebar, alongside Stats. Opening it gives you one panel with the live figures at the top and every budget cap listed underneath, each editable in place. If you would rather the row were not there, it can be hidden from the sidebar without affecting the caps themselves; they keep working and stay editable from the Settings screens that own them.
How it behaves
How it relates to the rest of the app
- It reuses the existing spend data (the same numbers the Statistics → Spend tab shows)
and the existing session/daily/vendor limit controls — nothing here is a second copy.
A cap changed in Cost Control is the same
AppSettingsfield its home screen writes. - The caps that only apply to pay-per-use API keys (per-session and daily-per-account) never limit flat-fee Claude Pro/Max subscription sessions — the controls say so.
- The daily per-account limit card shows today's coding-session spend for each API-key account right beside the limit — the exact figure the limit checks. That coding-session number is separate from (and usually larger than) the metered "API charges" figure an account row shows (which excludes coding-session spend), so the limit and the number next to it refer to the same thing. This closed a report where a user over a $5 limit saw only a $0.13 metered figure and thought the block was broken.
- When the daily API-key limit stops a session, the notice now explains it plainly — it names the API-key account, says it is the daily limit (not this one session), makes clear the figure is today's cumulative spend across sessions on that key, and that it resumes tomorrow, with a pointer to these spending-limits controls. And turning on "Allow API Keys to Run Sessions" (Settings → Accounts) now warns up front that sessions billed to an API key spend real money and are subject to this daily cap — so a later stop is expected, not a surprise. (This closed a report where a subscription user was interrupted by "killed at $91 (hard cap: $25)" without knowing their work had moved to their paid API key.)
- A few internal safety limits (e.g. the AI-coaching spend pools) are fixed guardrails with no user setting and are intentionally not shown here as editable caps. They are named below anyway, because a limit you cannot see is a limit you cannot diagnose.
Internal safety limits (fixed, no setting — listed so they can be diagnosed)
These are code constants, not settings: they have no row in Cost Control, no entry in the generated settings reference, and no way to change them. Each is a runaway brake rather than a budget, so the numbers are deliberately far above normal use.
- Shared AI tool loop —
$50/day. The loop behind the agentic chat features (Google Drive, Sheets and Calendar AI) has its own daily ceiling, used when a caller does not set one. When it trips the feature stops and says so on screen: "I paused here — this feature reached its daily usage limit. Please try again tomorrow." A caller may pass its own cap, and operators can move the default with theAMC_TOOL_LOOP_DAILY_CAP_USDknob; the$50is what you get otherwise. It resets the next day. - Built-in AI helpers —
$25/day, per label. The client-side net under the small background helpers. See built-in-ai-helpers.md — it is explicitly not the per-user ceiling, which lives at the gateway. - Email Cleanup classifier —
$0.50/day, and Mission Control comment summaries —$0.50/day. Both are feature-local: past the cap that one AI feature stops and everything else is unaffected. See email-cleanup.md and mission-control-part-3.md. - Mission Control LLM features —
$5/day default. The shared default for the PM features that make LLM calls; an individual PM feature may pin a lower cap of its own. See pm-intelligence-advisor.md. - The AI-coaching spend pools — the example this section has always named, and the same shape: fixed guardrails with no user setting.
Turning it off
Cost Control ships visible. To hide the sidebar item, toggle
costControlSidebarEnabled (Settings, or PATCH /settings over the CLI) — the same
hide mechanism Stats uses. Removing it from the sidebar never affects the caps themselves;
they keep working and stay editable from their home Settings screens.
Why historical spend figures changed (one-time repair, 2026-09-08)
If numbers on Cost Control or Statistics -> Spend are LOWER than you remember for dates before 2026-09-07, that is a deliberate correction, not a data loss.
What was wrong. Claude Code reports a session's cost as a running total for the whole underlying process, and Omniscio was adding each reading to the session's total. So a session with many turns re-billed its own history over and over, and the recorded figure grew far beyond what was actually spent. The same defect inflated recorded API time.
What was done. A one-time repair runs itself in the background the first time you open a build that has it (about two minutes after launch, so it never slows your window opening). For each old session it either:
- rebuilds the real cost from that session's own Claude Code transcript, when the transcript still exists; or
- lowers it to the highest value its own recorded tokens could possibly have cost, when the transcript is gone but the recorded figure is arithmetically impossible; or
- leaves it exactly alone — which is what happens to the overwhelming majority of sessions, including every session recorded after the fix.
What it will never do. It never raises a cost, never writes $0 over a real charge, and never touches a session that is still running. Every original value is saved before anything changes, so any correction can be inspected or undone.
What it cannot do. Claude Code deletes its own transcripts after about 30 days, and those are the only surviving record of what an old session really cost. Recent history can be rebuilt exactly; older history can only be lowered to a provable ceiling, and some over-count from months back is simply not recoverable. Numbers from that era should be read as an upper bound.
Separately, cache pricing got more accurate. Anthropic charges more for a prompt cached for an hour than for five minutes, and Omniscio was pricing both at the cheaper rate. Anywhere a cost is ESTIMATED from tokens — spend caps, the pre-send warning, non-Claude providers — it was under-counting. Normal Claude sessions were unaffected, because those bill from Anthropic's own reported figure.
For agents
Under the hood
- Virtual project sentinel
__cost_control__; integration manifestsrc/shared/integrations/cost-control.ts; sidebar/panel wired in the UI registry. - Panel
src/renderer/src/features/cost-control/CostControlView.tsxreads the settings store + the stats store; the cap list is generated from the single catalogcost-cap-catalog.ts(one entry per cap, so nothing is hand-duplicated).
Related
The figures Cost Control reports are the same ones described on the Statistics page, and the per-session and daily limits it edits are explained alongside the credentials they apply to on the API Keys page. If you would rather be nudged than watch a panel, AI spend alerts covers threshold notifications, and Usage Forecast covers the projection of where the month is heading.
Last verified 2026-09-28