Explain the tradeoff between a larger model and a smaller one in plain product terms.

Copperpot Kitchens runs nineteen fast casual kitchens, and PriceThyme is the tool that costs out every one of its hundred and forty recipes against live ingredient prices. Zenzo Kalinowski runs menu engineering there, and PriceThyme actually does two very different jobs: repricing a known recipe against a new price, thousands of times a day, and working out a substitute when an ingredient's price jumps or disappears, maybe forty times a month. His team pointed both jobs at the same cheap model to save money. One of those jobs was never built for a model that cheap.

How to answer this, stage by stage

Nobody is grading whether you can define "parameters." They are grading whether you can point at one real call PriceThyme has to make and say, out loud, which size model should answer it and why.

Let's learn

PriceThyme looks at a restaurant's recipes and today's ingredient prices, and tells the kitchen exactly what each dish costs to make right now.

One tool, two very different jobs. Most calls are the easy kind. The rare kind is where this whole answer lives.

Before anyone touched a keyboard, Zenzo Kalinowski did that job by hand. Once a week, he pulled the supplier price sheet for all nineteen Copperpot Kitchens locations and recalculated the cost of all one hundred and forty menu items on a spreadsheet. A full day, every week, and by Thursday the numbers were already three days stale.

PriceThyme did the routine part of that same job in under a second, thousands of times a day, every time a supplier's price ticked. For the everyday calls, that's arithmetic: take the new price, multiply by the recipe quantity, done. A small, cheap model handles that fine.

Here is the turn. The extra mistakes were never the problem with the routine job. The small model has never once mispriced a straightforward reprice. The problem showed up somewhere nobody was measuring: the rare moment PriceThyme had to actually work something out, instead of just look it up.

What that costs at its worst: if Zenzo had still been doing this by hand, he would have caught the ratio the same afternoon, the way any cook checks a jar of purée against a jar of paste before using it. Automating the swap did not just fail to catch the mistake. It hid a mistake a distracted line cook would have caught by taste, and it hid it behind a number that looked exact.

What I would leave alone: the routine repricing pipeline, still running on the small model, has never caused a single one of these problems. Thousands of correct calls a day is exactly the job it's suited to, and switching it to the large model would only add cost and lag to a live margin alert during a dinner rush, for no gain at all.

The lesson: one model size can't be the whole architecture. The moment you let a single size cover every job, you've quietly promised that the hardest case and the easiest case cost the same to get right. They never do.

Now here is the same thing as a story

The short version above is what you actually say out loud. Read this one for the Tuesday that got Zenzo here, and the one small question that finally cracked it open.

Every Sunday night, for six years before PriceThyme existed, Zenzo printed the week's supplier price sheet and circled anything that jumped more than ten percent in red pen. He knew Copperpot's hundred and forty recipes the way a mechanic knows an engine, which ingredient was load bearing to a dish's margin and which one barely mattered.

Nobody decided, on any single day, to stop checking. The checking just had nothing left to catch, because PriceThyme had never once been wrong on the routine job.

When PriceThyme arrived, the routine reprice work vanished into the background, correct and instant, thousands of times a day. Zenzo spot checked it for a month. It was always right. So he stopped, and put that hour back into menu planning, which is what the tool was supposed to free up in the first place.

The substitution job was different, and rarer, maybe forty times a month across all nineteen kitchens. Early on, Zenzo reviewed every one of those by hand before it hit a prep card. Then finance flagged how much the large model was costing after a month where every single PriceThyme call, easy and hard, ran on it by default. Someone pointed the whole pipeline, substitutions included, at the cheap model instead, to bring the bill down. Nobody in that meeting was being careless. On paper it looked like a clean fix to a real cost problem.

Black garlic paste spiked three hundred and forty percent that spring, a supplier shortage. PriceThyme flagged it inside a minute and suggested a substitute: a milder roasted garlic and shallot purée, swapped in at the same weight as the paste it replaced.

The paste is concentrated, used sparingly for its punch. The purée is milder and needed nearly twice the weight to taste the same. The small model treated the two as interchangeable by weight.

That is not how the two ingredients actually relate. The purée needed about one point seven times the weight of the paste to hit the same flavor. A straight one to one swap under-seasoned every batch, and the "cost savings" the model reported, thirty two cents off the Copperpot Smash, was really a cost the kitchen hadn't paid yet.

The question came from a new sous chef, doing a manual recipe check for a health permit audit. Her paperwork said the Smash now used a cheaper garlic ingredient. The weekly numbers said the dish's food cost had climbed from twenty eight percent to thirty four percent. She turned to Zenzo with a fair, small question: "Why did the cheaper garlic make this more expensive?"

He pulled the batch math that afternoon. The purée needed one point seven times the weight the model had used. The reported savings, thirty two cents a sandwich, was actually a loss of sixty nine cents a sandwich once the correct amount went in. At around eleven hundred and fifty sandwiches a week, across five weeks, that was close to four thousand dollars gone, quietly, on one dish out of a hundred and forty.

The decision Zenzo would take back sits in that finance meeting, not in the kitchen. Routing the substitution job to the cheap model felt like a clean fix to a cost problem that was real. Nobody in that room asked the one question that actually mattered: does this job need arithmetic, or does it need a person's kind of reasoning about ratios? The routine reprice job needed arithmetic. The substitution job never did.

One alternative got seriously considered the week the mistake surfaced, and it's worth naming because it looked like the responsible fix: move every PriceThyme call, routine and rare alike, back onto the large model, for good. It lost. Twenty nine hundred routine calls a day on the large model would have cost about eighteen thousand seven hundred dollars a year for zero improvement on jobs the small model was already getting right, and it would have added real lag to a live margin alert that kitchen staff check mid service.

Run the same five weeks again, with a job type flag that routes substitution calls to the large model and leaves the routine reprice job exactly where it was. The large model correctly scales the purée to one point seven times the weight, on the first suggestion, at a cost of about sixty cents a month across all nineteen kitchens. The Copperpot Smash holds at twenty eight percent food cost. Nobody notices, because there's nothing to notice.

What Zenzo would tell himself, back in that finance meeting: a cheap model is not a smaller version of an expensive one. It's a different tool, built to skip exactly the kind of thinking that a ratio problem needs. We asked it to skip that thinking on the one job where skipping it cost real money.

PICK, routed by the job

Not a ranking of which model wins. PICK only works here if you refuse to crown one size, and instead say, out loud, which job belongs to which model.

One mistake sits in the budget in plain view. The other hides inside a prep card that looks, on the surface, like it went fine.

Three branches, one question asked every time a call comes in. The routine reprice answers known number. The garlic swap should have answered ratio to work out.

The trade off worth saying out loud: routing substitution calls to the large model adds about two seconds of extra time compared to the small model's instant answer, and it costs roughly sixty times more per call. Both were accepted on purpose, because the calls are rare enough, about forty a month, that the total extra cost barely clears sixty cents, while getting one of those calls wrong quietly cost close to four thousand dollars on a single dish.

And if you want to be sure it really works, try it somewhere else

Same four letters, a loading dock instead of a kitchen, and this time the thing that gets under quoted is a truckload instead of a sandwich.

Loadstone Freight brokers truckload shipments, and its quoting tool prices a load the moment a shipper posts one. Suleika Balint runs product there, and the tool splits into the same two kinds of job PriceThyme does: quoting a known, common lane in under a second, and pricing a load that needs real judgment, hazmat, multiple stops, or temperature control, where a straight per mile rate misses what the load actually costs to move.

Same split as Copperpot's kitchen, a completely different industry. The tool that fits each job doesn't change with the trade.

Loadstone pointed both jobs at its small model to keep quotes instant across the board. A temperature controlled load with two extra stops got quoted using the same flat per mile rate as a simple one stop lane, missing the reefer surcharge and the deadhead miles between stops entirely. The quote came in at two thousand one hundred fifty dollars. The load actually cost two thousand eight hundred ninety dollars to run. Loadstone ate the difference to keep the shipper, on a load that should never have needed a discount in the first place.

Mapped onto PICK: the position holds its shape, known lanes stay on the small model, hazmat and multi stop pricing needs the large one. The impact splits the same way, a stale simple quote is a minor annoyance, an under quoted reefer load is real money handed back on a single load. The cost asymmetry lands the same too, routing the rare hard quotes to the large model costs a small amount of extra compute; guessing on them cost seven hundred forty dollars on one load, invisible until a dispatcher noticed margins on multi stop reefer loads had been thin for weeks. The kill criteria transfers without changing a word: does this call involve a ratio or a conversion a person would have to think through.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: route anything with a ratio or a conversion in it to the larger model, before touching cost, no matter how tempting the cheap default sounds.
Cost: no budget this quarter for two model tiers. Fine, but get a written rule that nobody points a substitution or conversion job at the cheap model until the budget exists, full stop.
The model got better, for real: say the small model's overall accuracy improved on a fresh benchmark. Still doesn't matter much. A better score on ordinary requests says nothing about whether it can now handle a ratio conversion it was never trained to reason through.

Where people run it wrong.
They treat "the small model is cheaper" as the whole argument, and never ask what specific job it's cheaper at doing.
They assume a model that's accurate on thousands of easy calls will stay accurate on the one rare hard one, because the dashboard has looked fine for months.
They fix a cost overrun by moving everything to one tier, instead of asking which specific calls actually needed the move.

How to use it live. Before answering, ask yourself one thing: does this call need a person's kind of reasoning, a ratio, a conversion, a judgment, or is it really just arithmetic on a known number? That single question decides the model size. Everything else in the answer is just proving it.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0