Billing

Ellipsis bills for what each session uses, plus a platform fee. Signup credit funds your first sessions, and spend limits at four levels cap everything else.

Billing is usage-based: each session is billed for the model tokens and sandbox compute it used, at cost, plus a platform fee. Signup credit covers your first sessions, and spend limits cap what agents can cost you.

Credits

Installing Ellipsis grants one-time credit: $100 for organizations, $10 for personal accounts. Usage draws down credit first; nothing is charged until it is gone. Credits never expire.

What happens when credit runs out depends on whether a card is on file:

  • No card. New sessions are blocked, recorded as payment_required, until you add a card or buy credit on the Billing page. Ellipsis emails you when remaining credit crosses 25% and again at 10%, so the stop is never a surprise.
  • Card on file. Sessions keep running. Usage bills monthly in arrears, with remaining credit applied to the invoice first; once $100 of usage accrues mid-cycle, it is invoiced then rather than waiting for month end.

Buy more credit on the Billing page: packs from $100 to $10,000, sold at face value. Buying credit does not add a card, so a credit-funded account pauses again at zero until you top up or add one.

What a session costs

Three components, totaled on every session:

ComponentRate
Model tokensThe model's own token prices, passed through at cost. Zero on your own key.
Sandbox compute$0.1419 per CPU core-hour and $0.0242 per GiB-hour of memory, for the sandbox's allocated resources over its lifetime.
Platform feeEqual to the session's actual token and compute cost (a 100% fee), minimum $0.10 per session.

Every session shows its own breakdown: total cost split into tokens, sandbox CPU, sandbox memory, and fee, plus per-step spend on the session timeline. In a conversation, each turn records what it cost. The Usage page aggregates the same numbers per billing period, and its Fees tab shows the current rate card.

Spend limits

Spend is capped at four levels. The first three are always on with defaults; per-developer limits are opt-in.

LevelWhat it capsDefaultsWhere to set it
AccountEverything your account spends, per rolling window$250 / day, $2,500 / week, $10,000 / monthUsage → Limits
Per agentOne agent's trailing spend and its per-session budgetInherits the account default and ceilingsbudget in the agent's YAML
Per sessionA single session$250, which is also the platform maximumUsage → Limits (the account default) or budget.session
Per developerWhat one person's sessions spendOff; enabling suggests $25 / day, $100 / week, $250 / monthUsage → Limits

Every window is rolling: the trailing 1, 7, or 28 days from this moment, never a calendar reset. A "month" is 28 days. Account limits are adjustable from $1 up to platform ceilings of $1,000 / day, $10,000 / week, and $40,000 / month; per-agent windows share the same ceilings.

An agent caps itself in its config, in US dollars:

budget:
  session: 1.00 # one session may spend at most $1
  day: 5.00 # this agent's trailing 1-day spend
  week: 20.00 # trailing 7 days
  month: 50.00 # trailing 28 days

This is the difference between "the account may spend $250 today" and "the weekly summary agent may spend $5 today". Omit a value to inherit: the account default for session, the platform ceiling for the windows.

Per-developer limits cap each person who triggers sessions, through a mention, the dashboard, the CLI, or an API key, so one enthusiastic teammate cannot consume the account's daily limit. Once enabled, the default applies to everyone; add an override for a developer who needs different numbers. Scheduled sessions are exempt: a cron agent belongs to the team, not the person who committed its config. Cap it with the agent's own budget instead.

To give one session more room without editing the config, pass a config override when starting or replaying it from the API or CLI, for example raising budget.session for that run alone. The override applies to that session only; the platform maximum of $250 per session still holds.

When a cap is hit

Nothing silently overspends, and nothing fails quietly:

  • A running session that reaches its budget stops immediately and records the exit status budget_hit. The timeline shows which step spent what.
  • A session that would breach a trailing limit never starts. It is cancelled before a sandbox exists, recorded as budget_hit with the exact reason, for example "Spend limit exceeded: developer trailing 1-day limit of $75.00 reached." A blocked mention gets a reply with that reason and a link to the session, so the person who asked knows why nothing happened.
  • A dashboard alert is raised the moment sessions start being blocked, naming the limit and where to raise it.

Limits release on their own as spend rolls out of the window; raising the limit releases them immediately.

Spend alerts

Alerts tell you about spend before limits block it. Two kinds, both set in Usage → Limits:

  • Percent of limit. Fires when trailing spend crosses a percentage of an account limit. Defaults: 80% and 100%.
  • Dollar thresholds. Absolute trip-wires per window, independent of the limits: "tell me at $500 / week even though my limit is $2,500."

Alerts land in the dashboard's Alerts inbox (the sidebar shows an unread dot), go to your notification email contacts, and post to your connected Slack channel. They are also readable over the API at GET /v1/alerts. Alerts only notify; the limits are what block.

Code review budgets

Code review runs under its own budget, shaped for reviews rather than sessions:

FieldDefaultWhat it caps
budget.run$10One review pass, across every reviewer and the gatekeeper together.
budget.dayunset (ceiling $1,000)The pipeline's trailing 1-day spend.
budget.weekunset (ceiling $10,000)The pipeline's trailing 7-day spend.

run caps a whole review, not one session: reviewers without their own budget split the remainder evenly. day and week are checked before a review starts, so a pull request force-pushed forty times in an afternoon stops producing reviews once the pipeline is over its cap, until the window rolls.

budget:
  run: 25.00
  day: 100.00
  week: 400.00

Review spend still counts toward your account-wide limits; the full config is in the code review YAML reference.

BYOK and fees

With your own Anthropic key or Bedrock connection, model tokens bill to your provider account and the token line of your Ellipsis bill drops to zero. Sandbox compute and the platform fee are unchanged: the fee is computed on actual usage, tokens plus compute, whichever account paid for the tokens.

Sessions still record real token spend, so every budget and limit on this page keeps working: a session on your own key that reaches its cap stops, exactly as it would on Ellipsis-managed keys.