Skip to content
Autonomous AI Agents GuideTry Kortix

What an autonomous agent run costs

An agent's bill comes from how often its trigger fires and the two caps on that trigger. Model choice moves one half of that. Kortix is the open-source AI Operating System: your agents, their skills, your company memory and every connector live in one git repo you own.

Where the run caps sit on a trigger

The documented run-cap example, a webhook trigger held to 20 runs an hour and 100 a day.

kortix.yaml
triggers:  - slug: pr-review    type: webhook    secret_env: GITHUB_WEBHOOK_SECRET    prompt: "Review {{ body.pull_request.html_url }}"    max_runs_per_hour: 20    max_runs_per_day: 100
Source: https://kortix.com/docs/connect/triggers
terminal
kortix triggers add|set --max-runs-per-hour <n> --max-runs-per-day <n>
Source: https://kortix.com/docs/connect/triggers

How each vendor meters a run

Open source
Yes
No
No
How a run is metered
Sandbox seconds in credits; provider bills tokens; managed tokens in credits
Copilot Credits per response or action, by task complexity
Input and output tokens at each model's list price
What sets the monthly bill
Fires, reserved sandbox seconds, model calls
Copilot Credits used in the month
Tokens sent and returned, per model
What a cap looks like
Run caps per hour and per day; empty wallet stops fires
Purchased capacity enforced monthly; unused credits do not carry over
Hard spend limit per org or project; requests return 429 past it

A fire is one session, and the session is what the meter runs on

An agent bill is set by the fire, not by the month. One trigger, one prompt, one session, over and over, and each repeat is a machine that wakes up.

Nobody is at the keyboard when a trigger fires. Each fire renders the prompt against the payload and sends it to the session that session_mode picks, a new session by default. A fire creates no commit of its own. The spend lives in that session. Each session puts one agent on a sandbox of its own, and that machine bills while it is awake.

That is why two agents on the same model can differ by an order of magnitude. A weekday digest fires about 22 times in a month. A monitor that wakes on every spike in a queue can fire hundreds of times, and each fire starts another session and makes another set of model calls. The prompt is close to identical in both cases.

The caps bound how many fires happen, and nothing else

Two fields on the trigger do the bounding. Kortix writes them as one line: "--max-runs-per-hour and --max-runs-per-day apply on every add and set."

They sit in kortix.yaml beside the prompt, so a change to either shows up as a diff entry. The defaults are the part people skip. With max_runs_per_hour unset, a trigger starts at most 60 runs in any 60 minutes. With max_runs_per_day unset, the UTC day holds no cap at all, and that second default is the one to override first. Sixty an hour is 1,440 sessions in a day if a trigger could fire that often. That figure is arithmetic on the default, not a price for anything.

Three behaviours decide whether a cap actually holds:

  • A fire past a limit starts no session and sends no prompt, so a skipped run costs nothing to run.
  • A trigger that runs at its hourly limit through the hour before pauses itself. max_runs_per_day never pauses a trigger.
  • overlap: skip is the default for a cron trigger, so a schedule faster than its runs finish starts nothing while the previous run is still active.

Read a month off the expression before the first fire, then compare that number with the caps you set.

Cron expression (6 fields)FiresFires in 30 days
0 0 9 * * *1 a day30
0 0 9 * * 1-55 a weekabout 22
0 0 * * * *24 a day720
0 */30 * * * *48 a day1,440

The last row is where a cap earns its place. Forty-eight fires a day, each holding a reserved sandbox for twenty minutes, is a different month from forty-eight fires that finish in thirty seconds flat.

What the model half costs on each route

Every plan can use models on your own provider key or a ChatGPT subscription. On your own key, model usage goes straight to your provider. The first $1,000 a month is free, then Kortix adds 5%, paid from credits. So credits pay for the sandbox and for a small fee past the allowance, and the provider sends its own invoice for the tokens.

Managed models are the other route, on the Credits plan only. Those calls meter at the provider's base price plus a 5.5% platform fee, paid from credits. The whole month then arrives on one invoice, and you hold no provider key.

Self-hosting is the third route. A self-hosted instance runs with billing off by default, with no credits, no plan limits and no managed models. The deployment is a choice: Kortix Cloud, your VPC, or your own on-prem network, with self-hosting free, as Kortix sets out.

Model calls on that instance go to the provider key you add in the app. The sandbox is not the server. The self-hosting page at Kortix is explicit: "Sessions run on Platinum sandboxes, not on the server."

Read the real number instead of modelling it

A published rate answers a different question from the one a buyer asks. 100 credits per dollar tells you what a credit is worth. It says nothing about what your digest costs. That depends on how long its sandbox stays reserved and how many tokens the prompt pulls in.

The trigger keeps the answer. kortix triggers runs <slug> lists a trigger's runs newest first with their duration and cost, so after a week you can read what a fire costs in your own project rather than estimating it. kortix billing status reads the balance.

The tier arithmetic is short from there. At 100 credits per dollar, the smallest Credits tier of 5,000 credits a month is $50, and a bigger tier buys more credits rather than a cheaper credit. Members do not move that number. Kortix grants unlimited members, with no per-member charge.

The wallet is the last cap and the bluntest. When the balance reaches zero, agents pause and triggers stop starting sessions, and a run needs a positive balance. A team that never set --max-runs-per-day still has that floor.

Trigger mechanics sit in running an agent with nobody watching, and the definition each of these settings tests is in what autonomous AI agents are.

Questions a buyer asks before the first invoice

A run bills the sandbox and the model calls. Credits pay for the sandbox. Managed models also meter their tokens in credits, at base price plus 5.5%. On your own key your provider invoices the tokens, and Kortix adds 5% past $1,000 a month.

Yes. Two caps sit on the trigger, --max-runs-per-hour and --max-runs-per-day, and the wallet is a third: when the balance reaches zero, agents pause and triggers stop starting sessions.

It changes the model half. On your own key the provider bills tokens directly, and past $1,000 a month Kortix adds 5%. The fires and the sandbox seconds come from the schedule.

At most once a minute, and 60 times an hour by default. A cron trigger fires at most once a minute, and max_runs_per_hour holds a trigger to 60 runs in any 60 minutes when it is unset.

Sandbox time, managed model tokens and proxied tool calls. 100 credits per dollar; the smallest Credits tier is 5,000 credits a month ($50). The credit is the unit and the sandbox second is the meter.

Price the trigger before the first fire.

The caps, the wallet and the per-run cost are all readable in the project you own.