What Does an AI Fitness Feature Cost to Run?

Every few weeks someone posts a number: "our AI coach costs us three cents per user per month." It is a useless number, and not because the person is lying. It is useless because per-user LLM cost is almost entirely determined by the shape of the feature they built, and you are not building their feature.

So this page does not give you a number. It gives you the arithmetic, the two or three places where the arithmetic surprises people, and the levers in rough order of how much they actually move the bill. Substitute your own measurements and you will have an answer that is worth something.

The cost equation, spelled out

For a single API call:

call cost = (input tokens x input rate) + (output tokens x output rate)

Input and output are priced separately, and output is the more expensive side. Then:

cost per user per period = call cost x calls per user per period
total cost per period    = cost per user per period x active users

That is the whole model. The interesting question is what goes into input tokens, because that is the term people underestimate.

Per request, your input is:

The provider's API is stateless. Nothing you sent last turn is remembered for you. So a carefully written 4,000-token system prompt with safety rules and worked examples is not a one-off cost you pay at build time; it is a tax on every call for the life of the feature. Teams who have only ever prototyped in a chat UI consistently get this wrong, because the chat UI hides the resend.

Two consequences worth internalising now. First, the effort you put into a long, careful prompt has an ongoing price, which is a real argument for moving stable rules into deterministic code where you can. Second, structured outputs are not free either — constraining the response to a JSON schema adds an internal system prompt explaining the format, which increases your input tokens.

Feature shape decides everything

Here is the thing the "three cents per user" post cannot tell you: whether the author built a plan generator or a chat coach. Those differ by more than an order of magnitude and it is not close.

The chat coach is a different business, and the reason is worth understanding precisely. Because history is re-sent every turn, turn n pays for turns 1 through n-1 again. Cumulative input tokens across a session therefore grow with roughly the square of the turn count, not linearly. Double the average session length and your input bill for that session more than triples. Nothing about your prompt engineering changes that; it is a property of statelessness plus a growing message list.

This is the single most important thing to know before you commit to a conversational feature. A plan generator's cost is a line item. An unbounded chat coach's cost is a function of user enthusiasm, which is exactly the users you least want to throttle.

A worked example — with entirely made-up inputs

Read this carefully: every token count below is invented for the purpose of showing the arithmetic. They are not measurements of any real product, ours or anyone else's. Do not quote the results. Replace them with numbers from a token-counting endpoint run against your actual prompt — that endpoint exists precisely so you do not have to guess.

Rates used are Anthropic first-party API rates as cached mid-2026. Verify current pricing in the provider's docs before you build a model on them; cloud-marketplace rates can differ.

We deliberately do not print a rate for Sonnet 5: a promotional introductory price is in effect at the time of writing, and quoting it would mislead you the moment it ends. Read it off the current pricing page.

Scenario A — weekly plan generation (hypothetical)

Suppose, hypothetically, one plan generation call looks like this:

• system prompt, safety rules, tool and schema definitions: 2,000 input tokens
• 60 filtered candidate exercises enumerated into the prompt: 3,000 input tokens
• user profile, constraints, recent training summary: 1,000 input tokens
• generated plan as structured JSON: 1,500 output tokens

On claude-opus-5:

input:  6,000 / 1,000,000 x $5.00  = $0.030
output: 1,500 / 1,000,000 x $25.00 = $0.0375
per call                           = $0.0675

One plan a week is four calls a month, so $0.27 per user per month, and at a hypothetical 10,000 active users, $2,700 a month. Run the identical prompt on claude-haiku-4-5 and the same call is $0.0135, so $0.054 per user per month and $540 at 10,000 users. Generate the plans overnight through the batch API instead of on demand and the Opus figure halves again. Batched on Haiku, the same hypothetical feature lands at $0.027 per user per month. None of this is a claim about what your feature will cost. It is a demonstration that identical prompts span a 10x range on model tier and batching alone, before you have trimmed a single token.

Scenario B — chat coach, same hypothetical arithmetic

Now suppose a stable prefix of 3,000 input tokens (persona, safety rules, tools, user profile), and each exchange adding roughly 500 tokens to the history — say 150 from the user and 350 from the assistant.

Turn n sends 3,000 + 500 x (n - 1) input tokens. Over a 20-turn session:

input tokens  = 20 x 3,000 + 500 x (0 + 1 + ... + 19)
              = 60,000 + 95,000 = 155,000
output tokens = 20 x 350 = 7,000

input:  155,000 / 1,000,000 x $5.00  = $0.775
output:   7,000 / 1,000,000 x $25.00 = $0.175
per session                          = $0.95

One hypothetical 20-turn session costs roughly fourteen times a hypothetical plan generation call. Three sessions a week is $11.40 per user per month — which, against a typical consumer subscription price, is the whole business. And notice what happens if sessions run to 40 turns instead of 20: cumulative input goes from 155,000 to 510,000 tokens, more than triple, for twice the conversation.

Images are priced by pixel dimensions

Scenarios A and B are both text. Images are the third cost shape, and unlike the other two the arithmetic is fully deterministic: an image costs ceil(width / 28) x ceil(height / 28) visual tokens, subject to a per-model long-edge and visual-token ceiling above which the image is downscaled. The provider's own worked examples: a 200 by 200 image is 64 tokens; a 1000 by 1000 image is 1296 tokens.

That means a single meal photo carries more input tokens than most short text prompts, and photo logging is a high-frequency feature — three meals a day is around 90 calls per user per month, versus four for weekly plan generation. Multiply it out with your own numbers before you decide the feature is cheap.

The good news is you control this cost exactly, because you control what the client uploads. Sending a full-resolution phone camera image when a roughly 1000-pixel long edge would suffice is pure waste, and higher-resolution tiers can consume several times the visual tokens for the same picture. The provider's docs recommend downsampling client-side when the extra fidelity is not needed. Do it by resizing rather than by dropping JPEG quality — the cheaper-looking route also costs you accuracy, for reasons worked through in the accuracy side of photo logging.

The levers, in rough order of impact

A few notes on the ones with sharp edges.

Prompt caching is a prefix match rendered in the order tools, then system, then messages. Content up to a cache breakpoint is cached; everything after it is reprocessed each request. Break-even is a small number of reuses of the same prefix — check the current docs for the exact read and write multipliers rather than trusting a figure from a blog post. There is also a minimum cacheable prefix length, model-dependent and in the hundreds-to-thousands of tokens, below which caching silently does nothing and returns no error. Verify hits with the usage fields on the response: if cache_read_input_tokens stays at zero across identical-prefix requests, something in your prefix is varying.

The most common way teams get a zero percent hit rate in this domain is interpolating today's date, a request ID, or the user's name into the system prompt. Other documented prefix-breakers: non-deterministic JSON serialisation, conditional system-prompt sections, and a tool set that varies per user — tools render first, so a varying tool set means nothing caches across users at all. Put the coaching persona, safety rules, schema definitions and any shared catalogue slice in the stable prefix. Put the user's profile, today's readiness numbers and the current question after the last breakpoint.

Batching is the textbook case for scheduled generation. If your product model is "here is your week", nobody is waiting on the response, so generate every user's next week overnight through the async batch endpoint. Your eval suite is batchable for the same reason. Interactive coaching obviously is not.

Routing to a smaller model works well for high-volume mechanical calls: is this message a food log, a workout request, a data question, or something safety-relevant? That is a cheap classification with a tiny output. The trap is that caches are scoped per model, so "route every turn to the cheapest adequate model" fights directly with "keep the cached prefix warm". Keep the main conversational loop on one model and spawn separate cheap calls for sub-tasks, rather than switching the main thread's model turn to turn.

And the cheapest token is the one you never send. "What did I lift last Tuesday?" is a database query. Routing it through a language model is paying for a lookup and adding a hallucination risk to a question that had none.

What you still own

Cost optimisation in this domain has a failure mode that cost optimisation in, say, a summarisation tool does not: several of the levers above trade tokens against safety, and it is easy to make that trade without noticing.

History summarisation is the clearest case. A user who mentions a knee injury on turn 2, a pregnancy on turn 3, or a beta blocker on turn 4 has given you facts that must survive the entire session. If your compaction strategy loses them by turn 15, the model will confidently recommend something contraindicated, and it will not know that it used to know better. The fix is not a longer summary. It is to persist safety-relevant facts as structured profile fields that are always injected into the prompt, and to test explicitly whether a stated constraint still holds after a long conversation.

Similarly, a safety pre-screen is exactly the kind of cheap, mechanical, high-volume call you would route to a small model — and that is fine, provided you have evaluated it as a distinct classifier rather than assuming the cheap model inherits the expensive model's judgement. Better still, do the first pass deterministically: a rule costs nothing per call, which makes it the one lever on this page that improves cost and safety in the same move. Why it also has to be a rule rather than an instruction is the guardrail architecture's subject.

Two other things no amount of cost engineering changes. Nothing a language model produces about exercise or nutrition is medical advice, and the app publisher, not the model vendor, owns what the app tells a user. And if you are sending a user's health profile to an external LLM API, Apple's App Store Review Guidelines require you to clearly disclose where personal data is shared with third parties, including third-party AI, and get explicit permission first (guideline 5.1.2(i)) — that obligation is unaffected by which model tier you routed the call to. See App Store health data rules.

Work it out before you design the feature

The business framing is simple and unforgiving. Per-user LLM cost sits inside your subscription margin alongside infrastructure, payment processing, support and acquisition. A feature that costs a dollar a month per user against a ten-dollar subscription is a decision. A feature that costs eleven dollars is a mistake you find out about in your third month of growth, when unit economics stop being theoretical.

So do the arithmetic at design time. Sketch the prompt, run it through a token-counting endpoint, estimate calls per user per period honestly — including your power users, not your median — and multiply. If the number is uncomfortable, change the feature shape before you build it. Turning an unbounded chat coach into a bounded structured intake plus a generated plan is a product decision available to you on day one and painful to make on day two hundred.

Model choice matters less than most of this, but it is not nothing, and the tiering question deserves its own treatment: see choosing an LLM for fitness apps. If you are also budgeting the data plumbing underneath the feature — wearables, health aggregation, exercise content — our fitness API pricing page covers that side.