Budgets and cost

Model usage costs money, and a coding agent that loops can burn a lot of it. kanman puts hard limits on spending per team, shows the cost of every run as it happens, and stops before a limit is crossed instead of after.

The three budgets

Set budgets on the team under Settings > Limits and budgets (/<workspace>/teams/<team>/settings/limits), or ask kanman “Show me the budgets” in the team’s chat. All amounts are in EUR. Old links to the former Budgets page land on the Spend card of this page. It holds everything that limits the team:

• Work at the same time: Stories at the same time, with a meter that shows which cap applies: the team’s own setting, the team’s plan or the workspace’s total.
• Spend: the run budget and the budgets per day and per month, each month and day with a meter of what the team has spent so far. On teams that use the runner’s own model access, this card shows the runner’s limits in minutes and runs instead.
• What I may change: protected paths and the secrets runs may use, as chips. Some paths are always protected and show as locked chips; secret names are suggested from the workspace’s secrets.
• Improve over time: whether kanman may re-run the team’s past stories to get better at its work, and the monthly limit for it (see Improve over time).
• Advanced: how many failed checks a story may collect before kanman asks, and how often kanman checks on long runs.

Every change saves at once: Saved shows next to it, and Undo brings the previous value back.

Days and months are counted in the time zone of the team’s working hours, or UTC if none are set.

Before a run starts, kanman checks the daily and monthly budgets. If one of them is used up, the story waits in Ready and starts once the next day or month begins; this is a wait, not a question, so no decision is created. The check is recorded in the audit log as policy_decision, and every run that stops at its budget as budget_stop.

When a run hits its budget

A run that would go over its budget stops at the step where it would cross the limit. kanman says so in the team’s chat with the amounts, for example “I stopped SBX-12: it used €0.80, its budget is €0.50. I recommend raising it to €1.00.”, and the decision inbox asks Raise budget for this run? with the options Raise to twice the current run budget (for example Raise to €1.00 for a run with 0.50 EUR) and Abandon. Raising the budget resumes the run; abandoning it ends the run and moves the story back to Backlog, with your note as a comment.

The health check also catches runs whose spend reached the run budget between two attempts. Such a run is parked, and the decision inbox offers to raise its budget by one more run budget and continue, or to stop it, which kanman recommends.

Urgent work is never blocked

Stories with the class of service expedite, and incident work such as a CI regression, an outage or a security fix, are never stopped by budgets or throttles. They still count toward the spend, so you see them in the totals.

Seeing what things cost

• Run page: the key numbers on the overview show the cost of the run against its budget; the Cost & details tab shows the cost of each attempt.
• Evidence pack: cost and duration are part of every pack on the pull request.
• Team report: the weekly report on the team’s Reports tab shows what the team spent and the cost per merged pull request.
• Team settings: Settings > Limits and budgets shows the spend of the current month, including what runs that are still going or waiting for you have used so far.

Keeping cost down

The main lever is complexity routing: kanman sends trivial stories to a small model with a short turn budget and keeps the flagship models for complex work. See Runs. Small, well-written stories cost less and fail less, see Write requirements kanman can finish.

Improve over time

kanman gets better at your team’s work by learning from the stories it already finished for that team. The setting Improve over time is on for every team, and you can switch it off at any time.

How it works:

• Re-running past stories. When the team is quiet (outside its working hours, with no story waiting for a slot), kanman takes stories of this team that were merged and re-runs them from the point where the real run started: the story as it was written then, the code as it was then and what kanman knew then. Each re-run tries one change to how kanman works, for example a different way to gather context before it writes code.
• Checked like real work. The tests that came with the merged change decide whether a re-run solved the story. Stories whose tests do not give the same answer every time are left out.
• Kept only when it is better. kanman compares the re-runs with and without the change and keeps a change only when it solves at least as many stories and is clearly cheaper, faster or more often right. After that it keeps checking the change on new work and goes back on its own if the team’s results get worse.
• What it tries, once there is enough history. First small changes to how kanman gathers context and works through a story. As the team’s history grows, more follows: an approach kanman learned from earlier stories is used in real work only after the re-runs showed that it helps; simple stories may move to a smaller, cheaper model; kanman’s own review and planning steps get a few notes written for this team; and the hardest stories may get two tries, of which kanman keeps the one whose checks pass. Each of these starts only when the team has enough finished stories to judge it fairly, and stays only if it proves itself.
• Never on your code host. Re-runs read the repository and nothing else: they never push, open a pull request, comment or touch the tracker.
• Never real work’s capacity. A re-run starts only when nothing of the team is waiting, never competes with stories for a slot, and stops when the workspace’s runs are stopped.

Where it runs and who pays. Re-runs use the team’s own model access, exactly like its real runs: the team’s own key, pay through kanman, or the team’s own runner and its model access. On teams that run everything on their own runners, the re-runs run there too.

The limit. By default re-runs use at most 5 % of what the team spent on models in the last 30 days, per calendar month. You can set another share (1 to 25 %) or a fixed amount per month. Re-runs never use the last tenth of the team’s monthly budget, so they are never the reason work stops at the budget. Their cost is part of the team’s spend and of the invoice like any other model use.

Your data stays in your workspace. Only this team’s own stories are used, and only for this team. Nothing is shared with other workspaces, and kanman does not learn across customers.

When kanman tells you. The first time it applies to a team, kanman says so once in the team’s chat, with How does it work and I don’t want that (owners and admins switch it off there at once, with Undo). The weekly report then says in one sentence what was tested that week and whether kanman kept a change.

Where to change it. Settings > Limits and budgets of the team, card Improve over time: the switch, the monthly limit, and what was used this month with the number of re-runs, changes tested and changes kept. It is not available on the Local plan, which starts no runs.

Paying for model usage

Each team chooses one of two billing modes (billing_mode):

Add a key under Workspace settings > Model access, then choose it when you set up the team. On the same page, New teams use sets which mode new teams start with (What new teams use). Claude Code works with an Anthropic or Amazon Bedrock key, Codex with an OpenAI or Azure OpenAI key. The team’s Settings > Agent and models shows which mode it uses, under how model use is billed. Keys are stored encrypted and are never shown again after you save them.

Budgets apply in both modes: with BYOK they protect your provider bill. Runs on a model whose price kanman does not know (often the case with an AI gateway’s model names) show Model usage in tokens instead of a cost, and euro budgets cannot stop them; the turn limit of each run still applies.

kanman’s assistant steps (drafting, conversation replies, the reviewer, the spec author) follow the coding agent’s mode unless the team gives them their own under Model access of kanman’s assistant steps in Settings > Agent and models.

Plan fees are separate from compute. See Plans and billing.

Related

• Policy settings: budgets
• Decisions
• What model providers see