Cost scales with tokens per call (input plus output), which model you pick, how often the game calls the API, and whether you cache repeated context. Cut cost by using a cheaper model for routine calls, caching static prompt parts, and running smaller models in-browser with WebGPU when latency and privacy matter more than quality.
At a glance
| Fact | Value | Source |
|---|---|---|
| Token billing | input and output tokens | platform.claude.com |
| Prompt caching reuses processed prompt portions | lowers cost, latency | platform.claude.com |
| In-browser inference needs WebGPU support | no server calls | github.com |
The main cost drivers are: how many tokens go in and out per call, which model you call, how often the game triggers a call, and whether you cache repeated context. Models are priced per million tokens (MTok), with separate rates for input and output, and cheaper/faster tiers alongside more capable ones – check the current rates on your provider’s pricing page before you commit to a design, since “prompt caching reduces costs and latency by reusing previously processed portions of your prompt across API calls”.
If you build your browser game using an AI coding agent like Claude Code or Cursor, Playgama MCP connects your agent directly to the developer cabinet to upload builds and publish a playable sandbox.
What actually pushes the bill up in a browser game
- Call frequency – a chat-style NPC that responds to every keystroke costs far more than one that responds per turn. Batch or debounce calls.
- Context size – resending game state, history or long system prompts on every call multiplies input tokens. Trim what you send, and cache the static parts.
- Output length – capping max output tokens keeps runaway generations (and cost) in check.
- Model tier – route routine, low-stakes calls to a smaller/cheaper model and reserve the stronger model for moments that need it.
- Extra tool costs – some providers charge separately for tool use like web search, on top of standard token costs.
For some game logic, in-browser inference avoids server calls entirely: WebLLM runs a model directly in the browser with WebGPU acceleration and an OpenAI-compatible API, with no server support needed, but it needs a WebGPU-capable browser and shifts cost to download size and device performance instead of API billing.
Never put a paid API key in client-side code shipped to players; proxy calls through your own backend and control access with server-side checks, the same principle Supabase documents for securing table and function access by role.
Sources
- Pricing – Claude Platform Docs
- GitHub – mlc-ai/web-llm
- WebLLM Javascript SDK โ mlc-llm documentation
- Securing your API | Supabase Docs
- Playgama Bridge SDK docs
Related questions
Should an LLM call happen client-side or server-side in a browser game?
Server-side, through your own backend that holds the API key. Calling the provider directly from browser code exposes the key to any player who opens dev tools.
Does running a model in-browser with WebLLM avoid API costs entirely?
Yes for that call, since it runs on the player’s device with WebGPU and no server request, but it shifts cost to download size and requires a WebGPU-capable browser.
How do I reduce token cost without changing the model?
Cache static prompt parts, trim context sent each call, cap output length, and batch or debounce calls instead of triggering one per player action.
Last updated: 30 September 2026