Build the cost-per-interaction model for a feature with a 2,000-token prompt and a 500-token response.

How to answer this, stage by stage

Seven moves. This is arithmetic, not a story, so what the interviewer is grading is whether your structure holds up, not whether your voice cracks at the right moment.

Let's learn

Say we build a feature that looks at a photo of your fridge and turns it into a grocery list and a couple of recipes. The prompt going in is 2,000 tokens. That is the photo, broken into pieces the model can read, plus the person's dietary notes, plus the instructions telling the model what to hand back. The answer coming out is 500 tokens: the list and the recipes.

The equation is short. Cost per interaction equals input tokens times the input price, plus output tokens times the output price. If a feature needs more than one call to finish, you multiply the whole thing by the number of calls. Here it's one call, so that term drops out.

Say a paying user scans their fridge three times a week, about 12 times a month. At the flagship price, that is 12 cents a user a month. Against a $4.99 subscription, that is about two and a half cents on the dollar. It is real money at scale, but it will not sink this feature.

But the price per scan was never really the danger. The danger is what happens when nobody caps how many times the button gets pressed. Section 2 has the number that made that real for one founder.

Now here is the same thing as a story

Skip this part if you already believe a fraction of a cent can put a dent in a company. Read on if you don't.

Mateus Rocha does not trust a feature until he has priced it. Before he writes a line of code, he writes the bill. That habit is the only reason his last two products didn't quietly burn through his savings before he noticed.

His current one is called Larder. Point your phone at your fridge, get a photo back turned into a grocery list and three recipes built around whatever is about to go off. He built the first version alone, most nights after his day job, at the kitchen table, laptop open, a cold mug of coffee going untouched next to it.

To keep the bill small, he started with the cheap model. Fifteen cents a million input tokens felt safe. He tested it on his own fridge, and it worked, mostly. Then he tested it on his sister's fridge, crowded, three jars pushed behind a carton of oat milk, the light bad. The cheap model called the wilted spinach basil and missed the eggs entirely.

He didn't need a cheaper model. He needed a model that could actually see. He switched the vision call to the flagship tier and left everything else the same.

That cost him a cent instead of six hundredths of a cent per scan. He almost didn't bother writing that down. A cent felt too small to be a decision.

Then a friend, over coffee, asked him a small question. "What happens if this actually takes off tomorrow?"

He went home and ran the number he'd been putting off. Say Larder picks up 8,000 free users in its first push, no cap on scans, because he hadn't built one yet. Free users scan more than paying ones do, out of curiosity, maybe twice a day. That's 480,000 scans a month, at a cent each. $4,800 a month, for users who pay him nothing.

He had about $40,000 left. One month of an uncapped free tier could eat eight percent of it, before a single free user ever converted.

So here is what he built instead: five free scans a month, no more, then a nudge to subscribe. Same 8,000 free users, same flagship model, same cent per scan. 40,000 scans instead of 480,000. Four hundred dollars a month instead of forty eight hundred. He can watch that number every day and sleep fine.

The thing I'd want Mateus to say out loud, if he were in the interview: the equation told him the price. It never told him the cap. That was a product decision, not a math one, and he almost skipped it because the math looked too small to matter.

Same equation. The number that mattered was the one he almost didn't write down.

The five moves behind the number

This is an estimation question, so the framework is BOUND. There's no behavior snapping here and no habit fading, just arithmetic, said out loud, with the assumptions named. FLIPS would force a person and a flip onto a question that doesn't have one.

The range, with the number you can actually feel marked next to it

B, break it down. Input tokens times input price, plus output tokens times output price, times the number of calls if there's more than one.
O, own the numbers. 2,000 input tokens, mostly the photo. 500 output tokens, the list and the recipes. Two tiers of published price, cheap and flagship.
U, use a range. $0.0006 to $0.01 per scan, a roughly 17x spread, driven almost entirely by which model tier does the reading.
N, nail the sanity check. 12 cents a paying user a month. About two and a half percent of a $4.99 subscription. Small enough that it was never the real question.
D, direction. Model tier moves the unit price the most. But usage volume, specifically an uncapped free tier, moves the actual bill the most. Those are two different questions, and a good answer keeps them separate.

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

A field-service app has technicians dictate a quick voice note after every job: what they fixed, what parts they used, anything the customer should know. The note gets transcribed, then an AI call turns the rough transcript into a structured summary for the invoice.

B, break it down. Transcript tokens in, summary tokens out, times one call, unless a second call checks the note for a safety-code mention before it's filed.
O, own the numbers. About 1,200 input tokens (the rough transcript plus the formatting instructions), about 300 output tokens (the structured summary). Same two published tiers as before.
U, use a range. Roughly $0.00036 to $0.006 per job summary, cheap to flagship.
N, nail the sanity check. A technician closes about six jobs a day, 132 a month. At the flagship price that's 79 cents a technician a month, against a software seat that already costs $49. Nothing to worry about.
D, direction. Here the call count matters more than the model tier. Add a second call to flag safety-code issues before the summary gets filed, and the bill nearly doubles, still under a dollar a technician. That's the assumption that would actually change the estimate if a compliance team asked for it later.

Swap the trigger and it still runs.
Speed: an interviewer asks how many scans a second the system needs to support at launch. Same equation, solve for tokens per second instead of dollars, and you're sizing infrastructure instead of a bill.
Cost: finance caps the AI budget at $500 a month. Same equation, run backwards: divide the budget by the price per scan to find the real usage ceiling.
The model got better: a new model ships at half the price and better at reading messy photos. Same equation, same two tiers, just re-run the two prices. The method never changes, only the inputs do.

Where people run it wrong.
They price the demo prompt, not the real one, then the production prompt turns out to carry three times the tokens once real dietary notes and history get added.
They state one confident number with no range, then get blindsided the day someone adds a second call and the bill moves without anyone noticing.
They price it once at launch and never again, so eighteen months and two model upgrades later, nobody in the room actually knows what a scan costs.

How to use it live. Say the equation before you touch a single price: "cost per interaction is input tokens times input price, plus output tokens times output price." That sentence buys you ten seconds to actually recall a real number, and it proves to the interviewer you have a method, not a guess.

Flashcards (click a card to flip it)

Check yourself Score: 0 / 0