[epic] AI budget & circuit-breaker limits are user-configurable via UI + MCP (today they are hardcoded constants)

[serge-ivo]

Goal

Every AI budget/limit a user can hit should be viewable and settable by the user via the UI and via MCP — not a hardcoded constant that requires a code edit + deploy to change.

Background (verified in code)

• Account circuit breaker = two bare constants in workers/api/src/lib/delegation-budget-store.ts: DAILY_CEILING_MICROS ($50 charged/24h, line 95) and DAILY_TOKEN_CEILING (250M tokens/24h, line 112). Enforced in reserve(); nothing reads an env var, per-account column, or admin setting.
• The only existing platform-AI setting is a boolean kill switch (PUT /v1/admin/settings/platform-ai).
• The breaker is invisible until it fires — the number only shows in the refusal message, and the agent-facing guidance even implies a nonexistent "contact support to raise it" lever.
• Cloudflare Access on the /v1/admin perimeter is currently off (see Enable Cloudflare Access on the /v1/admin perimeter before paid launch #108); admin is role-gated only.

Surfaced while investigating why 4 Coder agents went idle overnight — all tripped the 250M token breaker, and there was no way to see or change it.

Children

• [backend] Resolve AI budget ceilings from config, not hardcoded constants — env default → per-account override, read in reserve()/openBudget #474 — backend: resolve ceilings from config (env default -> per-account override), read in reserve()/openBudget, fix the refusal message
• [frontend] Budget & limits settings surface — show 24h consumption vs each ceiling + distance-to-limit, and edit the limits (console owner + admin) #475 — frontend: budget/limits settings surface (consumption vs ceiling + distance-to-limit, editable; console owner + admin)
• [mcp] get/set AI budget limits via MCP — account ceilings, per-tree defaults, Loop iteration cap #476 — MCP: get/set budget limits tools
• [enhancement] Per-run knobs configurable too — per-tree budget ($5/50/depth-4) and Loop max-iterations, via the same UI + MCP surfaces #477 — per-run knobs (per-tree budget + Loop max-iterations) via the same surfaces

Done when

A user can see their rolling-24h consumption against every ceiling and raise/lower each limit from both the console and MCP, with a clamped safe maximum — no code change required.

[serge-ivo]

Reframed by #485: rather than calibrate the ceilings now, AI budget enforcement is demoted to observe-only (BUDGET_ENFORCE, default off) until paid launch — usage is metered, structural caps stay, nothing hard-blocks. The D1 config resolver from #474 stays in place for when enforcement returns. Children #475/#476/#477 parked.

[serge-ivo]

Verdict: delivered — two small remainders, then close

All four children are closed and I have read the code that delivers each, plus confirmed the surfaces in production. This epic's premise ("today they are hardcoded constants") has expired.

Child	Shipped	Verified at HEAD
#474 resolver	32f48a1 + migration 0113	resolveAccountCeilings, lib/delegation-budget-store.ts:130-172 — per-account row → '__platform__' row → env → constant, clamped to MAX_OVERRIDE_*, fails open on a D1 error. Read by reserve() (:305) and openBudget
#475 surface	2d8f9d5 (+ 5805332 for enforced)	GET/PUT /v1/budget/limits, routes/budget.ts; console BudgetPanel, store/console/src/pages/Usage.tsx:566-780. Both are live — the deployed console bundle contains the panel, and production GET /v1/budget/limits returns effective + per-field tier + consumption + remaining + maxOverride + enforced
#476 MCP	ca476cd	get_budget_limits / set_budget_limits, workers/mcp/src/instance-tools/account.ts:108-153
#477 per-run knobs	c363fa9 + migration 0115	perTreeCostMicros / perTreeDelegations / perTreeMaxDepth / loopMaxIterations in the same four-tier stack; loopMaxIterations reaches sanitizeMaxIterations via lib/agent-loop.ts:60-64

Live proof of "no code change required", production, 2026-08-11 — every tier resolving, distance-to-limit present:

"effective": { "tokenCeiling": 250000000, "tokenCeilingTier": "default",
               "chargedMicrosCeiling": 50000000, "chargedMicrosCeilingTier": "default",
               "loopMaxIterations": 50, "loopMaxIterationsTier": "default", ... },
"consumption": { "chargedMicros": 7303714, "tokens": 221731036 },
"remaining":   { "chargedMicros": 42696286, "tokens": 28268964 },
"enforced": false

What remains

1. MCP write parity — 2 of 6 fields, and it clears the other 4. set_budget_limits (account.ts:122-151) sends only tokenCeiling and chargedMicrosCeiling; because PUT /v1/budget/limits is a full replace (routes/budget.ts:250-274), calling it wipes any per-tree or loopMaxIterations override set from the console. Filed as #501 with the fix. Read parity is fine — get_budget_limits proxies the GET, so it already returns all six.

2. The refusal message still points at a lever that is now the user's own. lib/delegation-budget-store.ts:321 and :331 both end:

To raise this limit, ask your platform operator.

This epic's own background objected to exactly this — "the agent-facing guidance even implies a nonexistent 'contact support to raise it' lever" — and #474 listed "fix the refusal message" as a deliverable. The denomination half was fixed (the message now names what was counted, over what window, and why subscription tokens are excluded — #343's finding). The lever half was not: since #475 the owner raises it themselves in Usage → Budget limits, or with set_budget_limits. A one-line copy change to something like "Raise it in Usage → Budget limits, or ask your platform operator." finishes it. Not worth its own issue; fold it into whichever of #501/#502 lands first, or do it standalone.

Correction to the 2026-08-10 08:15 comment on this issue

That comment says #475/#476/#477 are "parked" under #485. They are not — all three were closed delivered between 08:20 and 08:56 the same morning, i.e. within 46 minutes of the parking decision being written. Anyone reading this epic top-to-bottom would conclude three quarters of it is deferred when in fact all of it shipped. The Children checklist above the comment is also still unticked.

Recommendation

Tick the four children, correct or strike the "parked" comment, and close this epic as delivered, tracking the two remainders under #501 (MCP write parity) and the one-line message fix. The enforcement posture question is separate and is answered on #485 — nothing in this epic depends on it, and the machinery it built is what makes the recommended split-enforcement option there a config change rather than a code change.

Verified vs inferred

Verified: every file:line, the migrations, the production /v1/budget/limits payload, and the presence of the budget panel in the deployed console bundle. Inferred: nothing load-bearing. Not checked: whether any other client sends a partial PUT and relies on the clearing behaviour — I grepped store/, workers/, packages/ and found only the console (all six fields) and MCP (two).