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:
| Component | Rate |
|---|---|
| Model tokens | The 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 fee | Equal 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.
| Level | What it caps | Defaults | Where to set it |
|---|---|---|---|
| Account | Everything your account spends, per rolling window | $250 / day, $2,500 / week, $10,000 / month | Usage → Limits |
| Per agent | One agent's trailing spend and its per-session budget | Inherits the account default and ceilings | budget in the agent's YAML |
| Per session | A single session | $250, which is also the platform maximum | Usage → Limits (the account default) or budget.session |
| Per developer | What one person's sessions spend | Off; enabling suggests $25 / day, $100 / week, $250 / month | Usage → 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 daysThis 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_hitwith 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:
| Field | Default | What it caps |
|---|---|---|
budget.run | $10 | One review pass, across every reviewer and the gatekeeper together. |
budget.day | unset (ceiling $1,000) | The pipeline's trailing 1-day spend. |
budget.week | unset (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.00Review 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.
Linear
Connect your Linear workspace so new issues start implementing agents and @ellipsis answers on any issue. Scope access per Linear team.
Security
Every session runs in an isolated, ephemeral sandbox with one-hour scoped credentials. What Ellipsis stores, the retention setting, and where prompts go under each Models choice.