Academy

Smaller, faster, cheaper: the case against one big model for everything

It's tempting to hand every job to the most capable model. But most jobs need only one focused capability — and the right smaller model does it faster and cheaper.

The Felesh team 3 min

One big model for everything

It is tempting to pick the most capable model and hand it every task. In reality, most jobs do not need the full power of a frontier model. They need one defined capability at a defined level. When you use a big model for a simple job, you pay for power that never gets used.

Each job needs only some capabilitiesThree jobs set against speed, format and deep reasoning. The intent classifier reading “refund status?” needs speed. The summary of a 40-message ticket needs format. The policy answer on a refund after day 20 needs format and deep reasoning. One big model for all three needs every capability in every row.jobspeedformatreasoningintent: “refund status?”summary: 40-message ticketpolicy: refund on day 20?one big model, for all three
Each job needs one or two of these three things, so one big model for all of them pays for the rest.

Every job, a focused need

Rather than relying on a single ranking, evaluate each role independently. A classifier detecting user intent does not need deep reasoning; it relies on speed and stability. A summariser needs discipline and structure in its output format. Each role calls for only a subset of capabilities, at a level set by how sensitive it is and what its failure would cost. Once you sharpen the need this way, you often find a smaller, more focused model does the same job well.

One label picks the one model that runsA customer message, “Where is my refund?”, goes to the classifier, which reads it for speed and returns the label refund.status. That label routes the message to the answer model, which needs deep reasoning. The summary model is not called for this message.customer message“Where is my refund?”classifierspeed, stable labelslabel: refund.statusanswer modeldeep reasoningfor refund questionssummary modelstructure, fixed formatthe other model is not called for this message
The classifier labels the message first, and that one label decides which small model is called.

The hidden cost of size

This is not merely a matter of technical elegance; the real issue is speed and cost. Bigger models are slower and more expensive, and in processes that sit directly on the path of user interaction, that latency and cost become strikingly visible at scale. A simple rule helps: among the models that genuinely meet the job’s real need, choose the smallest. Reaching for a bigger model is justified only when the smaller one truly falls short on a decisive capability.

The smallest model that meets the needThree model rows, from frontier down to small, each marked as meeting the need of intent routing. A highlight starts on the frontier model and moves down the rows until it rests on the small model, the smallest that meets the need. Below, the rule: go bigger only when the smaller one falls short.the smallest model that meets the needfrontier modelmost capability, most costmid modelmore capability than this job usessmall modelspeed and stable labels are enoughmeets the needmeets the needmeets the needgo bigger only when the smaller one falls short
Among the models that meet the job’s need, choose the smallest; go bigger only when the smaller one falls short on a decisive point.

When no single model is enough

Sometimes no small model can cover every dimension of a job on its own. In that situation, the right answer is not to reach for a giant model, but to combine a primary model with a focused verifier — one that makes up the specific shortfall, and only on the portion of the data flow that needs it. The underlying principle is the same everywhere: fill the gaps by adding focused intelligence, not by scaling up the whole system.

A verifier checks only the line it is forThe primary model drafts three reply lines. Only the first, which names a renewal date, goes to a verifier that checks dates against the billing calendar, and the verifier marks it correct. The other two lines go out as drafted, with no verifier call.primary model drafts the replyYour Pro plan renews on the 3rd.Export is available as CSV.Your invoice is in the account.verifierdates onlyvs billingcalendarmatcheslines without a date skip the verifier
Only the line with a date goes to the verifier; the other two go out as the primary model drafted them.