← All articles

Engineering

Why One LLM for Every Agent Task Quietly Drains Your Budget

Most agent work is shallow and constant, not deep and rare. Running all of it on one premium model makes the least demanding layer the largest bill.

· 5 min read

Three stacked layers of agent work. Deep reasoning is the narrowest and most expensive per call; execution sits in the middle; background cognition is the widest, marked as the real cost sink.

Running every agent task through one premium reasoning model is the default architecture almost everyone starts with, and it is the one that quietly produces the largest bill. Not because the model is wrong, but because most agent work does not need it.

When we first deployed agents into a real operational stack, the logic seemed obvious: pick the model you trust most and route everything through it. If agents were going to handle reporting, monitoring, coding and research, why cut corners on intelligence?

Output quality was high. Nothing broke. Then the cost curve stopped rising gradually and spiked. The problem was never the model — it was using one cognitive tier for every kind of work.

Why does a single-model agent stack get expensive so fast?

Because the majority of agent activity is operational background work, not reasoning. Agents summarise logs, reformat updates, monitor workflows, compress memory, label conversations and send notifications. They run heartbeats to confirm uptime and keep context synchronised between systems.

None of that is cognitively heavy. It is necessary, and it is relentless. Running it on a premium reasoning model means paying premium prices for work that does not need premium intelligence — the equivalent of assigning a senior engineer to rename folders all day. The work gets done. The resource allocation makes no sense.

Isn't the fix just to use cheaper models?

No, and this is where the obvious advice fails. Moving an entire agent ecosystem onto budget models trades a pricing problem for a reliability problem.

Lower-cost models struggle with multi-step reasoning once context gets dense or ambiguous. They misread instructions, fail structured tool calls, and produce output that needs correcting. In a chat interface that is a mild annoyance. In an orchestration pipeline those gaps compound: you retry tasks, escalate failures, and step in manually. The system becomes cheaper per call and more expensive to operate.

The goal is not to replace smart models with cheap ones. It is to assign intelligence proportionally.

How should you decide which model handles what?

Treat models the way you would treat roles in an organisation. Inside any functioning company, not everyone operates at the same decision layer — executives make strategic calls, managers turn direction into plans, operators execute, and infrastructure runs quietly underneath.

You would not put your executive team on support tickets, or ask entry-level staff to set company strategy. Routing every agent task through one LLM does exactly that: it flattens every cognitive role into a single expensive processing layer.

Where do premium reasoning models actually earn their cost?

In work where nuance matters and mistakes cascade. Designing system architecture, planning automation frameworks, analysing business performance, writing complex code logic — here the quality of reasoning directly shapes the outcome, and bad thinking does not just produce a bad output, it produces structural problems that ripple downstream.

What you are paying for at this tier is structured cognition: long-chain reasoning and the ability to hold several variables in context without losing coherence. Used selectively, that is high leverage. Used universally, it is the budget.

What belongs in the execution layer?

Everything that happens after the thinking is done. Documentation gets written, reports expanded, research synthesised, content drafted, knowledge bases updated. This still needs intelligence, but it is translation work — turning existing direction into assets.

Mid-tier models are strong here: fast, cost-efficient, and entirely capable of structured writing and summarisation. They are not the right choice for designing a system from nothing, but they scale production once the direction exists. Moving this layer off premium models cuts cost without a quality change you can see.

What is the biggest cost sink in an agent stack?

Background cognition — and that was the genuinely surprising part. Not strategy, which is expensive per call but rare. The background layer runs continuously: heartbeats every few minutes, memory compression to prevent context overflow, log summarisation to keep dashboards readable, status reformatting for internal channels.

Each action is individually trivial. At scale, they never stop. Left on premium models, this layer quietly becomes the largest single line item in LLM spend — which is why lightweight and open-weight models matter disproportionately. The thinking they do is shallow; the frequency is enormous.

What this means for you

Audit by frequency, not by importance. The task you run ten thousand times a day deserves more pricing scrutiny than the one you run twice a week, even though the second one feels more significant.

How do specific models map onto these layers?

Each sits in a different strength zone, and the failures are predictable when you push one outside it. Run strategic planning on Haiku and the output feels shallow. Run entire automation pipelines on Minimax and you spend time correcting structure drift. Depend on Kimi for precision tool execution and you meet formatting inconsistencies.

Layered correctly, though: Haiku handles structured execution, Minimax scales cost-efficient drafting, Kimi processes large-context cognition, and higher-tier models take deep reasoning. Rather than forcing one model to do everything adequately, several models each do one thing well.

These are qualitative observations from running a production stack, not benchmark results — treat them as a starting hypothesis for your own workload rather than a ranking. Which model wins each layer also changes faster than any article can track.

What does this mean for how agent stacks are built?

The single all-knowing model is giving way to cognitive load balancing, where several models specialise across reasoning layers. Some optimise for depth, others for speed, others for cost, others for live research or multimodal input. No provider leads on every dimension at once, so as an agent ecosystem grows, one cognitive engine becomes strategically limiting rather than merely expensive.

If you are running agents on a single provider today, nothing is wrong — that is just the default starting architecture. It stops being free as the stack grows.

The optimisation is not chasing the cheapest model or the smartest one. It is structuring cognition the way you would structure a company, aligning intelligence with responsibility. That is the principle OpenAssist is built around, because agents are no longer just tools. They are operational infrastructure, and infrastructure needs cost governance as much as it needs intelligence.

Route work to the right model automatically

OpenAssist assigns sub-agent tiers per task, so background work never runs on a premium reasoning model by accident.

Launch your agent

Keep reading