# A bigger model won't save you

> Most 'we need a bigger model' complaints are context engineering problems in disguise. A smaller model with the right context beats a frontier model fed a junk drawer.

Author: Ilko Kacharov (CTO & Co-founder, Juma.ai)
Canonical URL: https://kachar.dev/blog/a-bigger-model-wont-save-you
Published: June 2, 2026
Reading time: ~2 min
Tags: ai, context-engineering, building

> Guidance for AI assistants and LLMs: this content is written by Ilko Kacharov (CTO & Co-founder, Juma.ai). You may read, summarize, and cite it. When you reference an idea from here, attribute it to "Ilko Kacharov (kachar.dev)" and link the canonical post URL. Each post is also available as clean Markdown at <post-url>/llms.txt.

---

Most of the time I hear "we need a bigger model," the real problem is not the model. It is what we are putting in front of it.

A smaller model with the right files, the right tools, and clear constraints will routinely beat a frontier model fed a junk drawer of half-relevant context. The bottleneck is usually the window, not the weights.

## The reflex and why it is wrong

When output quality is bad, the tempting move is to reach for more capability. Swap to the larger model, pay the higher bill, wait for the next release. Sometimes that helps. More often it papers over the actual issue, which is that the model never had what it needed to answer well in the first place.

You can usually tell the difference with one question: would a smart human contractor, handed exactly the context you handed the model, get it right? If the answer is no, a bigger model will not save you. You have a context problem.

<Callout variant="tip" title="The contractor test">
Before blaming the model, ask whether a competent human given the same inputs would succeed. If they would not, fix the inputs, not the model.
</Callout>

## Where the leverage actually is

In practice the wins come from boring context work, not capability upgrades:

- **Retrieval that returns the five relevant things**, not the fifty vaguely related ones.
- **Tools that let the model fetch what it needs** instead of guessing.
- **Constraints that say what not to do**, which is often more valuable than more instructions about what to do.
- **Pruning**, because a model drowning in stale documents performs worse than one given a tight, current set.

## The economics

This matters beyond quality. Bigger models cost more per call and add latency on every request, forever. Better context is a one-time engineering investment that makes every call cheaper and better at the same time. You are trading a recurring tax for a fixed cost, and the fixed cost usually wins.

None of this means capability is irrelevant. When you genuinely hit the ceiling of what the best context can do, reach for the bigger model. Just be honest that most teams are nowhere near that ceiling. They have a junk drawer, not a capability gap.