A Lot of AI Work Isn't Reasoning. Stop Paying Frontier Prices for It.

Open up almost any production AI system and look at what the model is actually being asked to do. Route this support ticket to the right queue. Pull the invoice number, date, and total out of this email. Turn "book me a table for four on Friday" into a structured API call. Decide whether this transaction looks like fraud. Fill these seven fields from this PDF.

None of that is open-ended reasoning. It's narrow, repeatable, bounded work. The same shape of job, over and over, at volume. Call it the 80%.

For the 80%, a frontier model is the wrong tool. Not because it's bad, because it's overkill. You pay reasoning prices, eat cloud round-trip latency, and ship your data off-device, all to do something a small specialized model does instantly, for pennies, on a CPU, offline.

What the 80% actually looks like

The 80% isn't a vague category. It's most of the AI work that ships:

• Routing. Intent classification, triage, deciding which of N buckets a request belongs in.
• Extraction. Names, dates, amounts, line items - structured fields pulled out of unstructured text.
• Form-filling and slot-filling. Mapping a request onto a fixed schema.
• Function calling. Turning a natural-language intent into a concrete API call with the right arguments in the right places.

What unites them is simple. The intent → action mapping repeats. The output is structured. The domain is bounded. You already know the finite set of things that can happen; the model's job is to pick and fill, not to ponder. There's no novel problem to solve on the thousandth request that wasn't there on the first.

Why the frontier model is overkill here

A frontier model is a general reasoner you rent by the token. On an 80% task, every one of its strengths is a cost you don't need to be paying:

You pay reasoning prices for a lookup. Classifying a ticket into one of twelve categories doesn't require a model that can also write a sonnet or debug a distributed system. You're renting that capability and using none of it - on every single call, forever.

You eat cloud latency on a task that should be instant. The work is a network round-trip to someone else's datacenter, queued behind everyone else's requests. For a real-time route or an inline form-fill, that round-trip is often slower than the rest of your pipeline combined.

You send your data out to do it. The invoice, the support ticket, the customer message - it all leaves your environment to be processed by a third party. For regulated, sensitive, or simply private data, that's not a latency footnote; it's a compliance and trust problem you've created for yourself.

You inherit non-determinism you didn't ask for. A general model is built to be open-ended. On a bounded task, "open-ended" mostly shows up as the freedom to wander off your schema in ways you have to catch and clean up downstream.

The honest 20% is real

This isn't an argument against frontier models. There is a genuine 20% where they earn every penny: open-ended reasoning, novel and ambiguous problems with no fixed schema, long-context synthesis across messy documents, the work where you genuinely don't know in advance what the right move is. Keep ChatGPT and Claude there. That's what they're for, and nothing small replaces them.

The mistake was never using a frontier model. The mistake is using a 20% tool for 80% of the work. Paying the genius rate for jobs that are, by construction, not hard.

How to tell which is which

You don't need a framework. You need three questions:

1. Does the same intent → action repeat at volume?
2. Is the output structured - an API call, a field, a route?
3. Is the domain bounded?

Yes, yes, yes → it's an 80% task, and a small specialized model wins. Three nos → it's the 20%, and you should reach for the frontier model.

Most teams already know the answer for most of their pipeline. They just haven't priced the habit of defaulting everything to the biggest model available.

Why small wins on the 80%

Once you've identified an 80% task, the small model isn't just the cheaper option - it's often the better one across the board:

Cost. Pennies, not reasoning-token prices. At volume, that's the difference between AI being a line item and AI being a margin problem.

Latency. It runs on a CPU, locally, with no network hop. Instant instead of "fast for a cloud call."

Privacy. It runs offline, on your hardware. The data never leaves. The compliance story writes itself because there's nothing to disclose.

Reliability. This is the underrated one. A small model on a bounded task can't wander, and even better, you can constrain and ground its output by design. Lock it to your schema. Force valid API calls. Validate against the finite set of things that are allowed to happen. A general reasoner gives you flexibility you have to police; a constrained small model gives you guarantees you can lean on.

The instinct that "bigger is safer" is backwards here. On the 80%, bigger is more capability you're not using, more surface area for the output to drift, more cost to do something that didn't need doing expensively.

This is the whole idea behind Fern

Fern is a tiny model that turns intent into action for the 80% - routing, extraction, slot-filling, function calls - instantly, cheaply, on-device, with output you can constrain and trust. It's built for exactly the work that doesn't need a frontier model, so you can reserve the expensive model for the 20% that actually earns it.

The result isn't "less capable AI." It's the right tool on each side of the line: small and specialized where the work repeats, frontier where the work is genuinely hard.

Try Fern, see the difference yourself →