The Hidden Cost of Renting AI by the Token

Usage limits have become the practical constraint on AI-heavy work. When a model is rented by the token, a provider's ceiling rather than the scope of the task determines how much work gets done, and agentic workloads have made that ceiling far easier to reach.

Most teams recognize the moment. A project is nearly finished when the model stops: the allowance is exhausted, and it will not reset for hours. Moving the work to another provider is rarely an option, because the context that made the work possible sits inside the session. So you buy additional credits, upgrade the plan when those run short, and finish several hundred dollars over budget.

The rationing effect

Agents are what made this acute. A single chat message is one model call. An agent makes many: point one at a repository or a folder of contracts, and it reads, plans, tries an approach, checks its own output, and tries again. One instruction can turn into dozens of metered calls, and the more capable the agent, the more calls it makes.

Faced with that, teams begin to ration, usually without deciding to. You scope an agent to a single directory rather than the full codebase. You accept the seventh draft in place of the tenth. You analyze one year of filings rather than four, because four would exhaust the week's allowance in an afternoon. Each of these decisions is reasonable on its own. Together, they allow a usage ceiling rather than the requirements of the work to determine how far the analysis goes.

It gets worse as models improve. The better the model, the more tokens it requires. A fixed ceiling means more of that work never gets done.

The ceiling comes with renting

Claude is a clear illustration. It meters usage in four different ways: an allowance that refills on a fixed clock, prepaid API credits that expire after a year, per-model limits in Claude Code, and an administrative spend cap that can halt a whole organization at once. Anthropic is transparent about these usage limits.

What ownership changes

A model running on hardware you own has no allowance to exhaust and no upstream vendor able to reprice or withdraw it. An agent can run thousands of iterations overnight for the cost of electricity, because the computer has already been paid for. The rationing ends. That is what Icosa builds: a model trained on your own data that you download and run on your own machine.

The obvious objection is quality: a model small enough to run locally would appear to concede too much capability to be worth it. Icosa's answer is Combinatorial Reasoning, a physics-inspired optimization method developed in collaboration with NASA and supported by a $1.4 million NSF grant, published and public. Rather than accepting a model's first chain of thought, the system generates multiple candidate reasoning paths, scores them, and selects the strongest subset before the model answers.

Within its trained domain, a model running on a laptop can reason at a level associated with substantially larger hosted systems. In practice, that means a model trained on your contracts can catch the same clause-level risk a much larger hosted model would, and a model trained on your codebase can hold your architecture in mind across a long refactor. It knows your work because it was built on your work.

Where Icosa fits in

The Icosa AI platform is available now via chat.icosa. Upload your documents, train a custom model without writing code, then download it and run it locally with llama.cpp or any preferred application.

Zeno, Icosa's local AI workspace for macOS, launches August 19. It learns how your team works from your own files and runs entirely offline, with nothing to configure and nothing to meter.

Owning a model should not require operating a server room. It should mean that the depth of the work is set by the work itself, not by a meter counting against you.