What I learned running the same prompt across three model sizes
I spend most of my week wiring models into pipelines that touch real work: drafting content, summarizing footage transcripts, triaging agent tool calls. At some point every one of those pipelines forces the same question. Do I run this on a small model I can host myself, a mid-size model that balances cost and capability, or a large cloud model I call over an API? I stopped guessing and started testing, running the identical prompt through all three tiers on the same task and watching where each one broke.
This isn't a benchmark post. I'm not going to hand you scores or claim one lab's model beats another's on some leaderboard, because I didn't run that kind of test and I don't trust numbers I can't reproduce myself. What I can tell you is what actually changed in the output as I moved from small to large, and where that difference mattered for the work I was doing.
Why I set this up in the first place
Every automation I build has a cost per run. A small model running locally costs electricity and GPU time I already own. A large cloud model costs a per-call fee and adds network latency. When you're running something once, that difference is trivial. When you're running it ten thousand times a month across a content pipeline, it stops being trivial fast.
So the real question was never "which model is smarter." It was "which model is good enough for this specific step, and where does the extra capability of a bigger model actually pay for itself." Comparing AI model sizes only makes sense in that framing. Size in isolation tells you almost nothing about whether a model fits your task.
The setup
I picked one repeated task from my own pipeline: turning a rough bullet list of talking points into a structured outline with headers, in a fixed format my downstream script expects. I fed the exact same prompt, same system instructions, same input, into a small local model, a mid-size model, and a large cloud model, with no other variables changed.
I wasn't grading for style. I was checking three mechanical things: did the output follow the format instructions exactly, did it hallucinate content that wasn't in my input, and did it need a second pass from me to be usable.
What actually changes as size goes up
The biggest shift I noticed wasn't raw "intelligence." It was instruction adherence. The small model would often get the gist of the task right but drift from the exact format I specified, maybe skipping a required field or reordering sections it wasn't supposed to touch. That's consistent with how these models work under the hood. A smaller parameter count means less capacity to hold onto every constraint in a long instruction set while also generating coherent text. It's not that the small model is "dumber" in some general sense. It has less room to juggle competing constraints at once.
The mid-size model followed formatting instructions much more reliably and only occasionally needed a nudge. The large model followed the format essentially every time and also handled edge cases in my input, like a bullet point that didn't cleanly map to any section, in a more sensible way. It made a judgment call instead of forcing a bad fit.
That pattern, more headroom for edge cases and competing instructions as size increases, showed up consistently enough that I now treat it as a rule of thumb rather than a surprise.
Where the small model held its own
Here's the part that matters most for anyone thinking about cost. For narrow, well-specified tasks, the small model did fine. When I simplified the prompt, gave it fewer simultaneous constraints, and made the output format looser, the gap between it and the bigger models nearly closed. Classification, short rewrites, pulling a field out of structured text, that kind of narrow work didn't need the extra capacity.
This lines up with how you'd expect a smaller model to behave. If the task doesn't require holding many constraints in tension at once, you're not paying the tax that comes with a small model's limited capacity. You're just using it for what it's actually built to do well.
That's also where local models earn their keep. If a task is narrow enough for a small model to handle reliably, running it locally means no per-call cost, no dependency on an external API being up, and no data leaving your machine. For high-volume, low-complexity steps in a pipeline, that tradeoff is usually worth it.
Where the small model fell apart
Multi-step reasoning was the clear failure point. Any prompt that asked the model to hold an intermediate conclusion in mind and then act on it, like "identify which of these points contradicts an earlier one, then restructure around that," produced noticeably worse results on the small model. It would sometimes miss the contradiction entirely or restructure around the wrong thing.
Ambiguous input was the other weak spot. When my bullet list had a vague or oddly phrased point, the small model tended to either ignore the ambiguity and force it into the nearest template slot, or invent context that wasn't there to make it fit. The mid-size and large models were more likely to flag the ambiguity in their output or make a defensible interpretation rather than fabricate detail. I want to be careful here: I'm describing a pattern I observed on my own inputs, not a universal law. Different prompts and different domains will shift where that line falls.
The mid-size model as the actual sweet spot
If I'm honest about my own pipeline, the mid-size model did the most useful work per dollar and per second of latency. It wasn't as fast or as cheap as the small local model, and it wasn't as capable on the hardest edge cases as the large cloud model, but for the bulk of my day-to-day tasks it hit the point where added capability stopped translating into visibly better output.
That's the pattern worth internalizing if you're building any kind of agent or automation stack. Bigger isn't better in a straight line. Capability gains taper off for a given task well before you hit the largest model available. The trick is finding where your specific task sits on that curve, not assuming the top of the range is always the right default.
What this means for how I route tasks now
I now think of model selection less like picking "the best model" and more like routing traffic. Narrow, high-volume, format-constrained tasks go to a small local model. Anything involving multiple constraints, judgment calls, or ambiguous input goes to the mid-size or large model, depending on how much that judgment call actually matters downstream. If a mistake at that step gets caught and fixed later in the pipeline, I'll tolerate a smaller model. If a mistake propagates and I won't catch it, I pay for the bigger one.
This isn't about any model replacing the judgment I still apply before something ships. It's about deciding, task by task, how much capacity a given step actually needs, and not defaulting to the biggest available model out of habit or the smallest one out of instinct to save cost. Both are lazy defaults. Neither holds up once you actually test the difference on your own prompts.
If you're building your own pipelines and want to see how I wire this kind of model routing into real agent workflows, you can find more breakdowns and walkthroughs on [the home page](/).
Get new guides and videos first — join the Telegram channel.