"LLMs are too expensive for a hobby game" and "LLMs are basically free now" can't both be true.
The answer depends on one design choice: generate once per day, or once per player.
I wanted a way to reason about this without trusting vibes, so I sketched a cost model for a toy project, "Riddle of the Day": one short text riddle, a few hints, an answer check. Everything below is a model with illustrative numbers. Plug in your own provider's current prices.
The formula
For any LLM feature, the cost per day is:
cost_per_day = calls_per_day × (input_tokens × input_price + output_tokens × output_price) where prices are per token (providers usually quote per million). Everything interesting hides inside calls_per_day.
Three architectures
A. Generate once per day
A scheduled job writes today's riddle and hints. Every player gets the same one, served from a database or a static file.
- calls_per_day: 1, plus any retries and checks
- cost is independent of the number of players
B. Generate once per player
Each player gets a personalized riddle.
- calls_per_day: number of active players
- cost scales linearly with players
C. Generate on every interaction
The model writes a custom hint after every wrong guess, or judges free-text answers.
- calls_per_day: players × average interactions per player
- cost scales with players and engagement
A worked example with made-up numbers
To make the shape visible, assume a hypothetical model priced at $1 per million input tokens and $4 per million output tokens. These numbers are invented for illustration and are not any provider's actual price. Assume 800 input tokens (instructions plus examples) and 300 output tokens per call.
Cost per call: 800 × $1/1M + 300 × $4/1M = $0.0008 + $0.0012 = $0.002.
| Architecture | Calls per day (1,000 players, 5 interactions each) | Cost per day |
|---|---|---|
| A. Once per day | 1 | $0.002 |
| B. Once per player | 1,000 | $2.00 |
| C. Every interaction | 5,000 | $10.00 |
Same model, same prompt, a 5,000× spread. The architecture is the price.
The hidden costs people forget
The formula above is the optimistic number. Real pipelines add:
- Retries. Output that fails validation (wrong format, answer leaked in the hint, too easy) gets regenerated.
- Judge calls. Many setups use a second model call to check the first. That can double the count.
- Moderation. User-facing free text often needs a safety check.
- Context growth. Per-interaction designs often resend the conversation so far, so input tokens grow with every turn.
- Human review. For architecture A, a person can actually read each day's riddle. That's the most expensive line and usually the most valuable one.
A useful habit: multiply your naive estimate by a safety factor until you have a week of real logs.
Quality is the real constraint
Cost is easy to model. Quality isn't. With one generation per day, you can afford to:
- generate several candidates and pick the best
- run automated checks (is the answer unique? do the hints leak it?)
- have a human approve it
With per-interaction generation, every output goes straight to a player. No review, more variance, more chances for a confidently wrong hint.
That's why my default for a daily game would be architecture A, with the model as a drafting tool behind a review step, and live generation only where it clearly improves the experience.
Latency, the other cost
Architecture A serves from a cache: effectively instant. Architectures B and C put a model call in the critical path of the user experience. A hint that takes several seconds to appear feels broken in a game. Streaming helps; precomputing helps more.
Decision rules
- If every player should see the same content: generate once, cache, review.
- If personalization is the product: budget per player and cap interactions.
- If you need per-turn generation: cap turns, keep context short, measure retries.
- In all cases: log tokens per call from day one. You can't optimize what you didn't record.
A spreadsheet you can copy
You don't need a tool for this. Five columns are enough:
| Column | What goes in it |
|---|---|
| calls_per_day | 1, players, or players × interactions |
| input_tokens | measured from a real prompt, not guessed |
| output_tokens | the average of real outputs |
| price_in / price_out | from your provider's current pricing page |
| safety_factor | start at 2 until you have real logs |
Then add one row per architecture and one column per audience size you care about: ten players, a thousand, a hundred thousand. Watching the per-player architectures grow down the column while the once-per-day row stays flat is the whole argument of this post in one glance.
Update the price cells whenever your provider changes prices. The structure won't change; the conclusion might.
Takeaways
- Cost per day = calls × tokens × price. Calls dominate.
- Generating once per day makes cost independent of audience size.
- Per-interaction generation scales with players and engagement; cap it.
- Retries, judge calls, moderation and context growth can multiply the naive estimate.
- Precomputed content can be reviewed by a human; live content can't.
Your turn
If you've shipped an LLM feature in a game or a side project: which architecture did you choose, and what was the cost line you didn't see coming?
I write about practice, feedback and the AI-readable web while building NEXO, a daily learning game.
