Plan and costs
Contracted plan​
Running a task requires Kadu to be in the organization's plan with Kobana (active, in trial or past due). The contract is read from Kobana's billing once a day, at sign-in and when the Kobana team refreshes the organization.
Without a plan, only the run is blocked, on every path: console, API, run
endpoint and schedules. Registration, reading, settings and cancellation
remain available. The console shows the Subscribe bar, and the API
responds 403 ENTITLEMENT_REQUIRED. A schedule that stops running for lack of
a plan emits the organization.entitlement_required event to your
webhooks.
Credits​
Besides the plan, the organization can have credits in reais (1 credit = R$ 1):
- Plan allowance: if the plan includes monthly credits, the month's usage (executions and Slack conversations, at price) is covered up to the allowance. The month is the one in the organization's time zone.
- Balance: credits bought in Kobana's billing go into the organization's balance when the invoice is paid. The Kobana team can also post adjustments.
Who pays for each use is decided before it starts:
| Situation | Who pays |
|---|---|
| Courtesy in force | the courtesy |
| Plan without a credit allowance | the plan (the price goes to the invoice) |
| Plan with an allowance, within this month's allowance | the plan |
| Allowance used up, or no plan, with a positive balance | the balance (the use's price is debited) |
| None of the above | the use is refused (403 ENTITLEMENT_REQUIRED, reason credits_exhausted or no_plan) |
The balance is only used once the allowance runs out: it is a reserve. The debit happens when the use's price is calculated; the balance can go negative if the last use costs more than what was left. At 80 % and 100 % of the allowance, the organization's owners get an email.
Tiers​
Each task has a tier (Tier 1, Tier 2…), chosen in the repository
through the task.model field (model: tier-3). The tier defines three
things:
| The tier defines | What for |
|---|---|
| Price | how much the execution costs the organization, in reais per million tokens (input, output and cache) |
| Executor | the program that runs the agent (Claude Code or Goose) |
| AI model | the model used by the executor |
Higher tiers use more capable models and cost more per token. An organization can have a tier price negotiated with Kobana.
Cost and price of an execution​
Each execution records the tokens consumed (input, output, cache read and write) and two values:
| Value | Currency | What it is |
|---|---|---|
Cost (cost_usd) | USD | what the execution consumed from the AI provider |
Price (price_brl) | BRL | tokens × tier price; the amount charged to the organization |
The price uses the PTAX selling rate of the business day before the execution
(usd_brl_rate). The execution's Cost tab and the
Analytics screens show these numbers.
Slack conversations​
Each message answered by the Slack bot is metered too: tokens, cost and price, calculated the same way as for an execution. Conversations have a single tier, set by Kobana for the bot, which also accepts a negotiated price. Conversations count in the same monthly usage, in the credit allowance, in the monthly cap and in Analytics, with the Slack conversations source. Each conversation has a spending limit; once reached, the bot asks to start another thread.
Monthly cap​
Kobana can set a monthly cost cap for the organization, in USD. The month
is the one in the organization's time zone: the cap reopens at midnight on the
1st in that time zone. The cost of Slack conversations adds up to the same cap.
Once the cap is reached, new runs and new conversations are rejected until the
month turns over (cost_limit_reached in the API) and your webhooks receive
organization.cost_limit_reached. The cap applies even with an active plan.