Stop Rationing Tokens: Let the Harness Pick the Model — Kimchi by Cast AI

A developer with a token allowance can run out of coding assistance before running out of work. Laurent Gil, Cast AI’s co-founder and president, compares that experience to a laptop with an hour of battery that can only be charged once a day. Together with Kimchi engineering lead Žilvinas Urbonas, he presents a different response to rising coding-agent bills: build a harness that makes sustained use cheaper, with proprietary models for edge cases and open models for the rest.

The ambition is to make tokens “unlimited and inexpensive.” That is a management goal, rather than a claim that inference has no cost. The internal experience presented here covers three months at a company with 300 employees, two-thirds of them developers. Kimchi’s job is to reduce the expense of their coding work enough that managers can support more use instead of rationing it.

Price per token describes a unit of consumption. It does not tell you the price of a completed task. Gil introduces a comparison that holds the task and output quality constant, then places token prices beside completion costs. In the presented figures, a Google model costs $3.50 per million tokens at a blended rate but $705 to complete the task; a MiniMax model has a quoted token rate of $1.50 and a task cost of $148. The study and its task are not identified, so these figures illustrate the distinction rather than establish a purchasing ranking.

The comparison changes what the harness should optimize. A lower token price helps only in combination with the amount of work needed to reach the required outcome. Kimchi chooses a model for the task and the time, using the outcome as part of the decision. That moves model choice out of a developer’s fixed preference and into the coding system.

Gil reports 2.5× savings over Claude across the three-month period. His graph compares a calculated daily Claude bill with what the company actually paid, and he describes the outcomes as equivalent. Token use increased by 1.5× during that period. The Claude baseline is counterfactual, and the presentation does not define the outcome-equivalence test; the result is an internal cost comparison, not a controlled benchmark of every model.

The next result concerns adaptation. A model-selection chart shifts from mostly orange in early June to mostly yellow in late June. Gil describes a Kimi model as the dominant choice on June 3 and a MiniMax model as the winner on June 21. The observable change is the harness’s mix of selected models: its preferred option changes within the month.

Keeping that choice current takes work. A person would have to discover a new model, test it and become comfortable using it; an automated selector can keep revisiting the decision. Kimchi’s stated objective is to do that while preserving the task outcome and controlling cost. The recording explains this objective and shows the selection shift, but does not specify the routing algorithm or how it explores unfamiliar models.

Urbonas gives the practical origin: the company’s Claude Code spending rose sharply roughly half a year earlier, prompting the team to build its own harness. Model routing is therefore part of a working coding environment, with the next layer responsible for checking whether the cheaper route still produces acceptable work.

Ferment is Kimchi’s construct for long-running tasks. It begins by asking questions, breaks the work into milestones and can run autonomously for more than two hours. Urbonas estimates human involvement typically occurs every two or three hours. Milestones give the run intermediate units of work; scoring gives the user a way to judge the output when a cycle finishes.

Two checks keep the process moving toward completion:

• Build and repair. After making a change, the system runs a build and checks whether something broke. A failure sends it back to change the code and rebuild.
• Quality scoring. Gil describes a higher-order model checking the code’s quality and requesting another attempt when it is insufficient. Urbonas describes the completion threshold as at least a B; a user can ask for further work toward an A.

The grading rubric and its calibration are not explained, so a letter grade should be understood as this system’s completion signal, rather than a general guarantee of software correctness.

Where does a failed attempt go, and what permits the run to finish? The diagram follows the build and quality checks back into implementation. The important relationship is the return path: choosing a model starts the work, while feedback determines whether that work needs another pass.

Completion leads to staging. Stopping there is deliberate: a human remains involved before production. Automatic production delivery is described as future work that would also examine observability data, service-level objectives and application health. In a Kubernetes environment, that includes checking for crashing pods and passing health checks. A code grade and a successful build do not replace those operational checks.

Long autonomous runs also change review. Urbonas imagines a product manager—or Gil himself—producing a 2,000-line pull request through a coding agent. Reviewing the differences alone is insufficient: the reviewer also needs the intended result and the specifications given to the agent. More generated code increases the value of understanding what the run was trying to accomplish.

Kimchi Teleport addresses a separate constraint: the machine hosting the session. It starts a remote sandbox and manages the agent there, with access from a laptop or mobile device. The session continues until the task finishes or needs human input, such as clarification of a specification. Urbonas describes both SaaS and on-premise deployment options, with the platform managing sizing and security requirements.

The airplane example makes the change concrete. An engineer was coding when the laptop’s battery failed, stopping the locally hosted work. With Teleport, the environment is detected and synchronized to a remote container—in the team’s case, at Google. The laptop still feels like the place where the engineer works, but the agent runs elsewhere. Closing the laptop removes the interface from view without stopping the remote process.

That separation fits Ferment’s cadence: if human input is needed only every few hours, the engineer’s device need not stay awake between interventions. Gil reports that 62% of their engineers were using Teleport exclusively for coding at his latest check. The practical appeal is simple: going home or entering transit no longer ends the run.

Kimchi Studio builds a team interface on Teleport’s remote sessions. A browser board exposes tasks, work in progress and plans generated by the harness. A peer engineer or product manager can review a plan before the team discovers, through the finished output, that the requirements were wrong. This gives the earlier 2,000-line pull-request problem an additional response: review the intended work while it is still a plan.

The board also makes interruptions shareable. A session asks for review; a teammate can say “I take it” and answer its question; the session returns to in progress until another review is needed. Gil describes this for teams of 5 to 10 people, with a Kanban interface for backlog, in-progress work and review. The person who started the terminal session no longer has to be the only person who can move it forward.

What changes when a teammate answers a blocked session? The diagram makes the review handoff visible. The card returns to active work, while execution remains in the Teleport sandbox; closing a participant’s laptop still leaves the run operating.

The closing distinction matters for anyone trying the system: the harness is entirely open source, while the presentation describes the overall offering as mostly open source. Studio and Teleport require a Google account for the setup shown. Gil describes a five-minute install that creates Teleport sessions inside that account, which can then be shared with colleagues through Studio.

These layers solve different parts of the same working process. The harness chooses models, Ferment checks and repairs their work, Teleport keeps sessions running independently of a laptop, and Studio lets the team inspect plans and answer review requests. The current delivery endpoint remains staging, with a human involved before production.