← Back to Blog

Kilo Code Splits Platform, Inference, and Cloud Compute: What Teams Pay

By Eric Bush · August 22, 2026 · 7 min read

Financial dashboard breaking a service bill into three layers

Kilo Code presents AI coding cost as three separate layers: the platform plan, model inference, and cloud compute. Individuals can use the open-source tools without a platform fee, Teams adds a per-user plan, inference can be provider-rate or bring-your-own-key, and cloud agents carry their own runtime meter.

The factual baseline comes from Kilo Code's current pricing page. Product behavior and prices can change, so confirm the current page before making a purchase or locking an annual budget.

The budgeting mistake is to look at one visible rate and treat it as the whole system. Coding work crosses planning, context retrieval, tool calls, file edits, execution, validation, repair, and review. Every stage can add tokens, runtime, or people. A useful model preserves those layers and then rolls them into cost per accepted result.

What Matters for the Cost Model

  • The Teams plan is listed at $15 per user per month, while individual platform access is free.
  • Kilo Gateway advertises hosted inference at exact provider rates, with credit purchases subject to a processing fee.
  • Cloud Agent Small and Docker are listed at $0.60 per hour, while Standard is $1.20 per hour, billed per second.
  • Kilo Pass adds subscription credits and bonus value but does not erase the need to track the underlying workload.

These facts change the shape of spend, but they do not determine whether the product is economical. A higher-priced run can be the cheaper outcome if it merges on the first attempt and needs little review. A low-cost run becomes expensive when it wakes repeatedly, occupies compute while idle, or produces a patch that experts must rewrite.

Build the Equation Before the Forecast

Monthly cost equals seats plus inference plus cloud seconds plus purchase fees and any optional pass. Ten Team seats cost $150 before usage. If the team runs 120 Standard cloud-agent hours, compute adds $144. A $400 inference workload then produces a $694 base before payment processing or discounts.

Keep cached input, uncached input, and output separate because their rates can differ by an order of magnitude. Add tool fees, search calls, image or screenshot processing, and regional premiums only when the workflow actually uses them. For runtime, model billing minimums and rounding explicitly. A spreadsheet that assumes perfect per-second billing can understate a block-priced service.

A Worked Monthly Example

Compare two groups. Team A has 10 users but only two heavy cloud-agent users; Team B has three users running agents continuously. Team A may be seat-dominated, while Team B is compute-dominated. A single blended dollars-per-developer metric hides this difference, so allocate all three layers to projects and users.

Run a sensitivity range around the estimate. Use a low, expected, and high case for acceptance rate, output length, retry count, and runtime. Those variables usually move the answer more than a tiny difference in input-token price. The high case should represent a difficult but plausible sprint, not an impossible catastrophe.

Controls That Preserve the Savings

  • Tag platform, inference, and runtime separately. Make this visible in the run record so the team can connect the control to dollars and accepted output.
  • Use local or BYOK paths where governance permits. Make this visible in the run record so the team can connect the control to dollars and accepted output.
  • Right-size cloud agents by memory and CPU need. Make this visible in the run record so the team can connect the control to dollars and accepted output.
  • Evaluate pass bonuses against actual monthly consumption. Make this visible in the run record so the team can connect the control to dollars and accepted output.

Give every automated run a durable identifier that follows retries, branches, builds, and review. Without that join key, invoices remain disconnected from engineering outcomes. Aggregate by task class, repository, team, model, and trigger so a change in workload mix does not masquerade as a price change.

The Failure Mode to Watch

Exact provider rates do not mean zero platform cost. Credit processing, cloud runtime, seats, and idle agents remain. Conversely, a local model is not free when workstation depreciation, electricity, setup, and slow output reduce developer productivity. Keep the accounting boundary explicit.

Set a stop condition before the run begins. Repeated failure on the same test, no material repository change, a spend ceiling, or a deadline can all trigger escalation. Stopping is not failure; it protects the budget and gives a human the evidence needed to change the approach instead of financing another identical loop.

How to Decide

The three-layer model helps teams choose independently: governance can justify a seat, quality determines the model, and execution needs determine runtime. It is especially useful for comparing vendors that bury one layer inside credits or advertise inference without showing sandbox compute.

Start with a bounded pilot and preserve a control group using the current process. Track model dollars, runtime dollars, tool charges, reviewer minutes, acceptance, cycle time, and post-merge defects. After enough comparable tasks, calculate total cost per accepted result. Use the AI Cost Calculator for the token component, then add the operational layers the API invoice does not show.

Want to calculate exact costs for your project?

Frequently Asked Questions

What is the first number I should track?

Track total cost per accepted outcome, then split it into inference, runtime, tools, CI, and human review so you know which lever to improve.

Should I optimize token price or success rate?

Optimize their combination. A more expensive model can be cheaper per accepted task when it reduces retries and reviewer corrections.

How do I keep autonomous retries from inflating spend?

Use durable run IDs, explicit retry and dollar limits, material-state checks, and escalation after repeated failure.

How often should the budget model be recalculated?

Recalculate after pricing or product changes and at least monthly using the latest task mix, acceptance rate, runtime, and review data.