Why a Free Model Won't Make Your AI Agent Cheaper

GLM-5.2 shipped on June 13 under an MIT license. It leads the open-weight agentic and coding benchmarks, scores 62.1 on SWE-bench Pro, and ranks first among open weights on the Artificial Analysis Intelligence Index. A 744B-parameter model you can self-host, no license fee.

So the obvious move for any team running production agents is to swap to the stronger, free-to-license model and watch the bill drop.

It can go the other way. A free model can raise your agent’s token cost, not lower it. The reason has nothing to do with the license, and everything to do with what an agent actually spends tokens on.

License price is not run cost

Two numbers decide what an agent costs to run, and the model’s license fee is neither of them.

The first is how many tokens the model spends per task. GLM-5.2 reasons longer than its peers. In Artificial Analysis evaluations it burns roughly 43,000 output tokens per task, where MiniMax-M3 does comparable work in around 24,000. A smarter model that thinks longer per job costs more per job, even when the weights are free. You stopped paying for the model and started paying for its reasoning.

The second number is how many tokens you spend before the model thinks at all. This is the one most teams never look at, and it usually dwarfs the first.

The catalog eats the context

Most agents load their tools the same way: every tool schema goes into the prompt on every call. Connect an agent to a CRM, an ATS, a finance system, and a ticketing tool, and the agent now carries hundreds of action definitions in context for a request that will touch exactly one of them.

The agent re-reads the full menu on every single call, whether it orders from it or not. At frontier-model rates, that menu is expensive. We have written before about how agents quietly exceed their own context windows through this kind of predictable bloat, and how schema and response size are the two largest line items in an MCP token bill. Tool schemas rarely show up in anyone’s cost budget, and they grow with every system you connect.

Now combine the two costs. You move to a model that reasons longer per task, and that model still has to ingest the entire tool catalog before it can reason at all. The per-task token count climbs on both ends at once. The free model made the agent more capable and more expensive in the same step.

On-demand tools beat default-loaded tools

The fix is loading tools on demand instead of pushing all of them into context at once. The model stays out of it.

Rather than push every action into context, give the agent a way to search for the one action it needs for the request in front of it. The agent asks for “update a candidate’s stage,” gets back the single tool that does it, and the context stays small no matter how many systems sit behind the search. A 200-action catalog and a 21,000-action catalog cost the same at call time, because the agent only ever loads what it picks.

Search-first tool discovery only works if the search is accurate. If the agent has to try three wrong tools before it finds the right one, you have traded schema bloat for retrieval round-trips and saved nothing. The retrieval quality is the whole game, which is why we put real work into a small embedding model fine-tuned specifically for action retrieval rather than relying on a general-purpose one.

That is the bet behind StackOne. An agent searches across 330+ connected systems and 21,000+ actions and lands the right tool on the first try 91.6% of the time on our S1 Search Bench. Permission checks on each action run in under a millisecond. The agent spends its tokens on the task, not on re-reading a catalog it never calls.

The agent never holds 21,000 schemas in context. It describes the job in front of it, the search returns the one action that matches, and the agent runs it. The context stays small whether there are 200 systems behind the search or 2,000. And because that discovery step sits between the agent and the systems it reaches, the model becomes a swappable part: move from GLM-5.2 to MiniMax-M3 tomorrow and nothing about how the agent finds and calls its tools changes.

What this means if you run agents in production

For AI and ML teams building agents at enterprise software companies, model choice is becoming a tuning knob rather than a moat. A new open-weight model that beats the frontier on agentic benchmarks ships every few weeks now. You will switch models more than once this year, and each switch changes your per-task reasoning cost in ways you only find out after the invoice arrives.

The token line you actually control is the one you load before the model reasons. Treat the tool catalog as a cost center:

• Count how many tool schemas sit in your agent’s context on an average call.
• Compare that to how many tools a typical request actually uses.
• If the ratio is bad, the model is not your problem. The loading strategy is.

A free, frontier-class model is a real gift. It just moves the cost somewhere most teams are not watching: tokens per task, and the catalog you pay to re-read every call. Fix the loading strategy and the next model swap becomes a cost decision you make on purpose, instead of one you discover later.

If you want to see what on-demand action search looks like across hundreds of systems, the StackOne docs walk through tool discovery and the agent toolset SDK.