Issue #68

Gemma 4, GLM-5, and the Real Cost of Running Agents

Google's Gemma 4 and a fresh GLM-5 benchmark reopen the question of what an agent model should actually cost to run.

AI & TechGemma 4, GLM-5, and the Real Cost of Running Agents

Recalculating which model to use for an agent

An open model is one whose weights—the output of training—are released publicly, so anyone can download and run it. What you’re allowed to do with it depends on the license. If you have the right hardware, you can run it on your own computer or on your company’s servers, or you can access it through an API run by another company.

Gemma 4, which Google announced on April 2, offers all of these options. Google released everything from a small model that runs on smartphones to a server-grade model, and adopted the Apache 2.0 license, which permits commercial use.

That same day, the Deep Agents team at LangChain published its own evaluation comparing GLM-5 and MiniMax M2.7 against Claude Opus 4.6, GPT-5.4, and others. The results, covering tasks like editing files, calling tools, and following instructions, suggested that cheaper models could hold their own. But since the evaluation was run through APIs, it doesn’t mean all of these models can be installed on a personal computer right away.

As I’ve said before, I’m skeptical of picking a model based on benchmark scores alone. What caught my attention this time was the relationship between price and actual task performance. Once you have several models that handle your work satisfactorily, cost differences start to weigh heavily on the choice.

Output Pricing per Million Tokens: $25, $3.15, $1.2

The output token prices the Deep Agents team laid out in their April 2 post are as follows. This is the fee charged when a model generates a response — the input tokens we send carry a separate charge.

ModelProviderPrice per million output tokens
Claude Opus 4.6Anthropic$25
GLM-5Baseten$3.15
MiniMax M2.7OpenRouter$1.2

Looking at output price alone, Opus 4.6 costs about 7.9x GLM-5 and about 20.8x MiniMax M2.7. But if the cheaper model needs more retries to land on an answer, or produces longer responses, the per-task cost gap narrows.

Let’s assume 10 million output tokens a day, 365 days a year. Opus 4.6 comes out to $250 a day, MiniMax M2.7 to $12 a day — a $86,870 annual gap in output fees alone. This is a simplified calculation that excludes input fees, cache discounts, and tool-use charges, but it’s reason enough to scrutinize unit prices closely once your usage scales up.

Gemma 4 Also Gives You the Option to Run It Yourself

With a weights-open model like Gemma 4, you can compare API fees against the cost of running it yourself. Which approach wins out depends on the hardware a company already owns, the volume of work it needs to process, and the operations staff it has on hand.

At launch, Gemma 4 came in four versions: E2B, E4B, 26B MoE, and 31B Dense. E2B and E4B are built with mobile-device execution in mind. The numbers in the names don’t exactly match the full model size. The 26B MoE1 activates only a portion of its total parameters during computation, while the 31B Dense requires more memory. Running the 31B on a consumer GPU calls for quantization — compressing the weights — plus enough graphics memory to hold them.

Features useful for agent development are built in too. Support for function calling2 and structured JSON output makes it easier to connect the model’s responses to external tools. But developers still need to build the software that actually executes those tools, checks permissions, and handles errors.

The Apache 2.0 license permits commercial use. Run the model on your own servers and you don’t owe an outside vendor per-token API fees. Instead, you take on the cost of buying or leasing hardware, electricity, maintenance, and operations staff. Even if you’re using equipment you already own, that hardware is a resource that could be doing other work — so it’s a mistake to treat it as free.

Even when comparing one API against another, you first need to line up what the pricing is actually measuring. Placing a blended input-output average price side by side with an output-only price makes the gap look bigger than it is. It’s more accurate to match the provider, the input-to-output ratio, and the caching conditions first, and only then calculate the cost against your own workload.

When retries pile up, even a low unit price adds up to real money

When you’re running an agent, unit price alone doesn’t tell the whole story — you also need to watch how many times the model gets called. A request that gets answered once and closes out is a completely different animal from one that involves editing a file and then testing it.

Take a coding agent, for instance: it plans, reads files, tests the fix, and if the test fails, goes back and revises. At each of these steps it calls the model again, and it may re-feed content it read earlier or the results of a prior test run. Depending on how many times this loop repeats, token usage for the exact same user request can vary enormously.

That’s why figuring out how many tokens a single code fix actually costs requires knowing both the scope of the task and the number of retries. You need to track input and output tokens separately, and keep an eye on how many tasks succeeded versus failed.

Even if the unit price drops, your total bill can still rise if usage grows faster. Say the price is cut in half, but usage triples — your bill ends up 1.5x what it was before. If your company’s model usage has been climbing, you can’t assume a price cut alone will shrink your budget.

The number I actually want to compare is the total cost of getting one piece of work done to a satisfactory result. If a cheap model fails repeatedly and a human has to redo the work, that time needs to be counted in the comparison too. Conversely, if a model handles repetitive tasks reliably, even a small difference in unit price compounds over time.

Model choice and workflow integration need to be designed together

As more models become available, companies building services face more decisions. They need to determine which model handles which task, how to connect company data and tools to it, and how to recover when something fails. I think this operational capability can become a meaningful competitive difference in business.

Deep Agents is designed so you can test different model configurations within the same execution environment. It also has a feature that adjusts conversation compression based on how much context length a given model can handle at once. With features like these, you don’t need to rebuild all the surrounding tooling every time you switch models.

This kind of execution environment is called a harness. It’s software that handles tool calls, file processing, context management, and similar tasks. Orchestration3—coordinating the sequence of work across multiple models and tools—can also fall under this umbrella.

That said, I don’t think calling something a “harness” automatically makes it a special asset. Just collecting Markdown instructions or JSON configs doesn’t create a competitive edge on its own. What matters is connecting a company’s knowledge, setting proper permissions, and then making the whole thing run reliably on actual work.

Deloitte, too, explained in a January 2026 piece that companies need to calculate costs separately for API usage versus running their own infrastructure. It suggested concrete operational practices: choosing models that fit token usage, managing context length, and setting up alerts before budgets are exceeded.

Oswarld’s Lens

If you want to get a feel for this yourself, try one of the small Gemma 4 models in Google AI Edge Gallery. There’s an iOS app and an Android app. When I tried it, it felt to me like GPT-4o. I wasn’t testing performance under identical conditions, but it was still striking to get responses like this running directly on a phone. How much storage you’ll need and which features are available depend on the model and device you choose.

What interests me about this shift is what it means for GTM strategy — that is, which customers you sell to and how. Products built on external APIs are at the mercy of the model provider’s pricing and policies. As more models become capable of running locally, the companies building services on top of them gain more room to choose their own pricing and how they handle data.

If a model can hit the performance bar a task requires, some work can move to a company’s own servers or onto users’ devices. Running a model without an internet connection is also possible. That said, tools that pull in outside information — like search — don’t become offline-capable just because the model does, and running everything in-house isn’t automatically cheaper for every company either.

I’d treat benchmarks as a way to narrow down candidates, with the final call made through real work tests. Deep Agents’ public evaluation was based on 138 test cases, and the reasoning settings weren’t even consistent across models. It’s hard to extrapolate from that to how a whole service performs once customer data, long-running tasks, and edge cases enter the picture.

If it were up to me, I’d pick out a slice of the work an existing model currently handles and hand it to a different model as a trial. If you track accuracy, completion time, retries, and how much human cleanup is needed, it becomes much easier to tell which tasks are safe to switch and which ones still need the original model.

Closing

  • In the pricing sheet released on April 2, Opus 4.6’s output price was about 7.9x that of GLM-5 and about 20.8x that of MiniMax M2.7. Actual task costs are also affected by input volume and retries.
  • Models you can run directly, like Gemma 4, give you the option of comparing API fees against the cost of running things yourself — hardware, staffing, and so on.
  • When choosing a model, you need to look beyond unit price to the quality of a single completed task, the time it takes, and how much rework a human ends up doing.

Next time you’re evaluating the cost of an AI tool, try comparing it against one task you do repeatedly. The starting point is figuring out which model is good enough for your work, and what it actually costs.

Thanks for reading today.

If this piece was useful, please share it with people around you. Having more readers is what keeps me writing.

Your take shapes the next issue

What resonated most in this issue, or where has your experience been different?

Any registered reader can comment for free.

References & Further Reading

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

Footnotes

  1. MoE (Mixture of Experts) is a structure in which only some of a model’s internal computation modules are activated depending on the input. It doesn’t need to compute every parameter each time, but actual speed and memory usage still depend on the specific model and runtime environment.

  2. Function calling is a capability that lets a model output, in a fixed format, which tool to use and what values to pass to it. A separate program is still needed to actually receive that call and execute the tool.

  3. Orchestration refers to coordinating the order in which models and tools are run, and how results and errors are handled.