Budgets
Hard caps per session, per agent, per developer, and per account, declared in the same YAML as the prompt and enforced before a sandbox exists. Spend is attributed to a person, an agent, and a step, so you always know who spent what.
Account, agent, session, and developer each get their own limit, so 'the account may spend this much today' and 'the weekly summary agent may spend a fraction of that' are both one line of config. The tightest applicable cap wins.
Placeholder: the four cap levels as nested rings (account > agent > session > developer), each labeled with its scope
Account, agent, session, and developer caps compose
An agent declares its own budget block: a per-session cap plus trailing daily, weekly, and monthly limits. It deploys by merging, previews on a branch, and is reviewed like the rest of the config, because it is the rest of the config.
Placeholder: agent YAML with the budget block highlighted (session / day / week / month lines)
budget: declared in the agent's YAML
A session that would breach a trailing limit never starts: it is cancelled pre-flight and recorded with the exact reason. A running session that reaches its cap stops immediately, and the person whose mention was blocked gets a reply naming the limit.
Placeholder: session timeline ending in a budget_hit status, next to the reply a blocked mention receives
Pre-flight blocks and in-flight stops, both recorded
Sessions break their cost into tokens, sandbox compute, and fee, with per-step spend on the timeline. Each session ties to a person, an API key, or a parent session, so 'who spent what last week' is a filter, not an investigation.
Placeholder: usage dashboard with spend per agent and per developer (Splitshift demo data)
Cost per step, per session, per person
Caps, windows, alerts, and attribution are the platform's job, not a spreadsheet someone maintains.
Daily, weekly, and monthly caps on everything your account spends ship enabled with defaults. Adjust them from the Usage page.
An agent caps itself in its config: a per-session cap plus trailing daily, weekly, and monthly limits, declared next to the prompt they govern.
Opt-in caps on what one person triggers across mentions, the dashboard, the CLI, and API keys, with per-person overrides.
Every session runs under a cap, and a platform maximum bounds even the most generous config.
Every limit is a trailing window from this moment, never a calendar reset an agent can wait out.
A session that would breach a limit is cancelled before a sandbox exists, recorded with the exact reason.
A running session that reaches its budget stops immediately and records budget_hit, with the timeline showing which step spent what.
A blocked mention gets a reply naming the limit it hit and a link to the session, so nobody wonders why nothing happened.
Configurable thresholds fire before a limit is reached.
Every session breaks its cost into tokens, sandbox CPU, memory, and fee, and every conversation turn records what it cost.
Raise the budget for a single run with a config override from the API or CLI, without touching the deployed agent.
Scheduled sessions are exempt from developer limits; the agent budget in its own YAML is what caps them.
Declare a budget block in the agent YAML: a per-session cap plus trailing daily, weekly, and monthly limits, in US dollars. Omit a value and it inherits the account default for sessions or the platform ceiling for the windows. The budget deploys like the rest of the config, by merging.
It stops immediately and records the exit status budget_hit. The session timeline shows which step spent what, so the cap is a diagnosis, not just a stop.
No. A session that would breach a trailing limit is cancelled before a sandbox exists, recorded as budget_hit with the exact reason. If a mention triggered it, the person who asked gets a reply naming the limit and linking the session.
Yes. Per-developer limits cap what one person triggers, whether through a mention, the dashboard, the CLI, or an API key. Enabling sets a default for everyone, and overrides adjust individuals. Scheduled sessions are exempt: a cron agent belongs to the team, so its own agent budget caps it.
No. Every window is rolling: the trailing day, week, or month from this moment. There is no calendar reset for spend to pile up against.
Yes. Pass a config override when starting or replaying a session from the API or CLI, raising its session budget for that run alone. The deployed agent is untouched and the platform per-session maximum still holds.
Every session shows its cost split into tokens, sandbox CPU, sandbox memory, and fee, with per-step spend on the timeline. The Usage page aggregates the same numbers per billing period, and every session is attributed to a person, an API key, or a parent session.