Sarvam Code’s most important number is not the size of any model. It is the bill for a failed attempt: zero, according to Sarvam. The Indian AI company says its early-beta coding agent charges for completed work while absorbing the cost of retries and dead ends. If that promise survives contact with real repositories, it changes the risk developers take when handing a long migration to an agent. If it does not, ‘completed’ will become one more fuzzy unit in cloud pricing.
The product is designed around a related calculation. Sarvam says its own agent configuration sends 36% of tasks to its 105-billion-parameter model and 64% to GLM 5.2, rather than running every step on the biggest available system. That split, which the company says cuts serving costs by roughly 40%, is a company-reported result rather than an independent benchmark. But it reveals the actual pitch: Sarvam Code is an orchestration and economics product as much as it is an AI programmer.
The unit of sale is a task
Most model APIs meter input, cached input and output tokens. Coding-agent subscriptions often hide that machinery behind monthly allowances, request limits or credits, but the underlying cost still grows when an agent rereads a repository, explores the wrong branch or generates a long failed solution. Developers bear at least some of the cost of the agent’s uncertainty.
Sarvam is proposing a different boundary. Its Coding Agents product page says retries and dead ends are not billed and that customers pay for completed work. The page shows a hypothetical migration of 214 database calls across 18 modules, with the agent keeping a visible plan, testing changes, saving checkpoints and returning to the last checkpoint after a failure. A developer can reorder the plan or stop an approach while the run is active.
That is a more useful framing for multi-hour work than tokens per million. A team wants a dependency upgrade, an ORM migration or a passing rollback review, not a particular quantity of generated text. Checkpoints also matter because long-running agents fail differently from autocomplete. The costly error is not a bad line suggestion; it is ten minutes of plausible changes built on a wrong assumption. Returning to a known-good state limits how much work must be repeated.
The hard part is measurement. Sarvam has not publicly defined what counts as completed work, how a task is priced, who decides whether acceptance criteria were met, or what happens when the code passes the agent’s tests but fails in production. Its public API pricing page lists token rates for Sarvam 105B, Gemma 4 31B and GLM 5.2, but it does not list a Sarvam Code task tariff. The product page’s billing statement is therefore a design promise, not yet a price a developer can compare with a token bill or a seat subscription.
A credible version will need explicit acceptance tests, task boundaries and dispute rules. ‘Upgrade this package and keep the test suite green’ can be evaluated. ‘Improve the architecture’ cannot. Users will also need to know whether an interrupted run, a partially useful patch or a human-steered recovery counts as completion. Until Sarvam publishes those mechanics, task billing is the product’s sharpest idea and its largest unanswered question.
One agent, several model sizes
Sarvam’s second bet is that routing can make a coding agent cheaper without making every step weaker. At its Epoch event, the company said Sarvam Code routes work across models at roughly 100B, 700B and 3T scale. It says the system selects tools for each model and manages context so that the same codebase is not repeatedly processed. The product page illustrates that policy with scaffolding sent to a fast, lower-cost model and rollback review sent to a reasoning model.
This is a sensible systems response to uneven coding workloads. Finding references, formatting boilerplate and reviewing a risky concurrency change do not require identical inference budgets. A router can reserve expensive reasoning for the small fraction of steps where it has the greatest value. It can also create new failure modes: a weak classifier may send a subtle task to a cheap model, and a handoff may lose the context that made the earlier work correct. Sarvam has not published a coding benchmark that isolates the router’s accuracy, handoff cost or completion rate.
The 36/64 figure needs the same caution. Sarvam reports it from a configuration evaluated on HarnessBench, a company-described set of 106 sandboxed tasks spanning software engineering, finance, retrieval, office work, tool use, site reliability and long-running autonomy. Sarvam says the 105B model performs close enough to the much larger GLM 5.2 to make routing worthwhile. Without task-level results or an independent reproduction, the claim shows how Sarvam operates its stack, not that another team will save 40%.
There is still a practical advantage in exposing routing as part of the product’s architecture. It focuses evaluation on completed jobs and total cost, instead of asking which single model tops a leaderboard. For agentic software, the harness determines what files are read, what tools are available, how failures are recovered and when tests run. Those decisions can outweigh a narrow difference in code-generation scores.
‘Built on Codex’ does not mean powered only by OpenAI models
Sarvam says the Sarvam Code harness builds on Codex. That wording can be confusing because Codex names both OpenAI’s coding-agent product line and the Apache-2.0-licensed terminal agent published on GitHub. In Sarvam’s description, Codex is the harness foundation; model calls are routed across Sarvam and other model tiers. The company is not claiming that its 105B model is Codex or that every task goes to an OpenAI model.
That separation is strategically useful. Starting from an existing open-source agent shell lets Sarvam spend its engineering effort on model adapters, context management, skills, routing, deployment and billing. It also makes the product a test of a broader open-source pattern: a reusable agent interface can become the base for regional or industry-specific services, even when the resulting service is not itself presented as open source.
Sarvam lists skills for frontend work, data and machine learning, and cybersecurity, plus enterprise systems including SAP and Finacle. It says deployments can run on its infrastructure in India, inside a customer’s virtual private cloud or on premises. Those options aim at organisations that cannot simply upload a private repository to a foreign shared service. They also raise concrete procurement questions about which model handles each step, where prompts and traces are stored, and whether routing ever moves code outside the chosen environment. The launch material states the deployment choices but does not publish a detailed data-flow diagram for Sarvam Code.
Training inside a coding run is the bigger leap
The product page makes another unusual claim: Coding Agents can train a task-specific model during a run, using the customer’s data and requirements, and then apply it to the job. Sarvam’s example uses underwriting data and risk parameters, not source code. Its broader custom-training offer says customer training data remains isolated, is not used to train Sarvam’s models, and produces weights owned by the customer.
This could move the agent beyond choosing among general-purpose models. A repeated internal task, such as interpreting a proprietary configuration language or enforcing a company-specific review policy, might justify a smaller specialist model. The specialist could be faster and more consistent than repeatedly explaining the domain to a large model in prompts.
But the product page leaves essential technical details open. It does not say what training method is used during a run, how much data is required, how the model is evaluated, how long training takes, or whether the resulting weights are available under the same terms as Sarvam’s separate custom-training service. The example should be read as a capability claimed by the vendor, not evidence that developers can safely train a production model from one terminal session. Any use involving financial decisions would also require governance well beyond a coding agent’s self-generated holdout.
What developers can judge today
Sarvam Code is in early beta, and the company’s announcement says some Epoch products remain in rollout. That makes the current release a statement of product direction more than a finished purchasing proposition. There is enough detail to see the system’s priorities: visible plans, checkpoints, active steering, model routing, deployment control and pricing tied to outcomes. There is not yet enough public detail to compare its cost or reliability with established coding agents.
The next evidence to watch is mundane but decisive: a published task-price schedule, an exact definition of completion, repository-level evaluations with failed attempts included, and documentation showing where code and traces travel under each deployment mode. Sarvam should also separate savings produced by cheaper model routing from savings produced by caching or shorter context. Those disclosures will show whether billing for finished work is a durable contract with developers or simply an appealing label placed over token economics.