---
title: Cost Control
---

# Cost Control

## 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 `AppSettings` field 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 the `AMC_TOOL_LOOP_DAILY_CAP_USD` knob; the `$50`
  is 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](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](email-cleanup.md) and
  [mission-control-part-3.md](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](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 manifest
  `src/shared/integrations/cost-control.ts`; sidebar/panel wired in the UI registry.
- Panel `src/renderer/src/features/cost-control/CostControlView.tsx` reads the settings
  store + the stats store; the cap list is generated from the single catalog
  `cost-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](stats.md) page, and the per-session and daily limits it edits are explained alongside the credentials they apply to on the [API Keys](api-keys.md) page. If you would rather be nudged than watch a panel, [AI spend alerts](ai-spend-alerts.md) covers threshold notifications, and [Usage Forecast](usage-forecast.md) covers the projection of where the month is heading.