Most AI iPhone apps discover their OpenAI bill the week after launch. The first week is a trickle, the second week a stream, and by the time week six arrives the number is a line item you were not planning to defend to anyone.
That is not an OpenAI problem. It is a scoping problem. The bill is predictable before you ship, if you model it the way you would model any other variable cost. We do it on every AI build; most founders are never shown the math.
Here is the actual model. It takes about fifteen minutes and prevents the only kind of post-launch surprise that is both expensive and avoidable.
Model it per user, not per month
The monthly bill is an outcome, not a lever. The lever is cost per active user per week. Pick one real session — not a demo, not a happy path — and count the calls.
For MedLogsRx, a typical scanning session is two OpenAI calls: a vision call to read the prescription label and a smaller text call to normalize the output into our schema. For IngrediCheck, built with FungeeLLC, one scan is a single streaming call. For KIN, parsing a spoken sentence into a calendar event is one call with a short system prompt and a short completion.
Multiply the per-session calls by the sessions you expect from a typical weekly active, then by the price per million tokens for the model you plan to use. That is the per-user weekly cost. Multiply by your target active base. That is your bill.
If the number does not scare you at a thousand weekly actives, it will not scare you at ten thousand. If it scares you at a hundred, you have a product-economics problem that no prompt engineering will fix.
The frontier model is rarely the right default
A pattern we see on nearly every intake: the founder has prototyped on the newest model because it worked first try, then budgeted the launch at the same model's price. On a feature where the model is making a real judgment call that sells the product, that is correct. On classification, extraction, formatting, light reasoning and most generation, a smaller model with a tight system prompt is usually within a point or two of the frontier model's accuracy and costs an order of magnitude less.
A useful exercise: pick your top three AI features, honestly rate how much the model's judgment carries that feature on a one to ten scale, and reserve the top model for the features above seven. The rest should run on something cheaper.
This is also why how an agency answers the first AI question matters. A team that has shipped AI to real users at real volume will not reflexively reach for the most expensive model just because it worked in a demo.
Caching is cost control, not an optimization
A startling share of real-world AI calls are repeats. The same user scanning the same label twice because the first attempt looked wrong. The same prompt applied to a cached image. The same system prompt repeated on every call because nobody deduplicated it.
Three cache layers that pay for themselves in the first week:
- Deduplicate the system prompt. If you send the same 400-token system prompt on every call, you are paying input tokens for it every time. OpenAI's prompt caching reduces the repeat cost significantly; even without it, keeping the system prompt tight is free money.
- Cache deterministic replies on the server. If the same input produces the same output (classification, extraction), hash the input and store the result. The second user asking the same thing is a free call.
- Short-circuit retries. A flaky network should not trigger three identical paid calls within a second. Idempotency keys and client-side retry windows are a one-afternoon fix.
Stream, so a cancelled thought is a cancelled cost
Streaming does two things at once. It makes the feature feel fast, which we care about for product reasons, and it lets you abort the request when the user backs out of the screen. A non-streaming call bills you for the full completion whether the user is still looking or not. A streaming call cancelled at token 40 bills you for forty tokens.
On IngrediCheck we stream the scan result over Server-Sent Events so product details appear before the analysis finishes. Beyond the user experience, it is cost discipline: a user who swipes away sees a result instantly and does not get billed for one they never read.
You cannot shrink an AI bill after launch without touching the product. You can shape it to any size you want before launch by choosing the model, the call pattern and what you cache.
Hidden costs most founders miss
- Retry storms. Mobile networks are flaky. Without rate limiting on the server, one offline-online transition can trigger a cluster of identical paid calls.
- Image inputs. Vision calls count more tokens than text — sometimes dramatically more at higher image resolution. Resize before uploading.
- Long system prompts. A 2,000-token system prompt attached to every call is a hidden tax. Half of them can usually be moved out of the prompt and into the function schema.
- Model deprecations. The model you scoped against may be deprecated within twelve months. Budget for a mid-year model swap, especially a jump to a more expensive one.
- Abuse testing. Someone will inevitably send the same long prompt a thousand times in a day to see if the AI breaks. If you cannot throttle them, you pay for their curiosity.
Never call OpenAI directly from the phone
A 2026 study found 64 percent of LLM-powered iOS apps leaked working credentials. Many of them were calling the model provider directly from the client. There is no way to ship an API key inside the app binary safely; shipping it is also shipping it to everyone who ever installs the app.
Routing calls through your own backend solves four problems at once: credentials stay off the client, you can meter per-user usage, you can cache and deduplicate, and you can swap models or change pricing without an App Store update. The cost of a small backend is trivial next to the cost of the first time a stranger uses your API key to burn through your credits overnight.
What a realistic AI bill actually looks like
For a founder-led AI iPhone app with a thousand weekly actives, a mid-complexity feature and the model choices we recommend, the OpenAI bill usually lands in a reasonable band for a seed-stage product. For a scaled consumer AI app with sustained generation, the number is materially larger and should be modeled against revenue, not against a vibes budget.
The right question is not what will my bill be, but what per-user cost makes the product's economics work. Model that, pick models to hit it, cache aggressively, stream everything, route through a server you control. The bill becomes a planning variable, not a surprise.
FAQ
How do I estimate my mobile app's OpenAI bill before launch?
Model it per-user. Count the API calls one real user makes in a typical session, multiply by expected tokens in and out, apply the model's current input and output prices, and multiply by your expected weekly actives. If the number scares you at week one, it will break you at week twelve.
Is GPT-4 or GPT-5 always worth the price in a mobile app?
No. For simple classification, extraction, formatting and reply generation, a smaller model with a good system prompt is usually within a point or two of the frontier model and costs an order of magnitude less. Reserve the top model for the one or two features where its judgment actually sells the product.
How can I cap my app from blowing up my OpenAI bill?
Route calls through your own server, meter per-user tokens, and refuse or downgrade when a user crosses a daily threshold. Cache deterministic replies. Stream partial results so a user cancelling early also cancels the token spend. We do all four on MedLogsRx and IngrediCheck.
What are the hidden OpenAI costs founders miss in a mobile app?
Retry storms when the network is flaky, long system prompts repeated on every call, image inputs that count more tokens than text, model deprecations forcing you onto newer pricier models mid-year, and support users who stress-test the AI feature by sending it the same prompt a hundred times.
Should an iPhone app call OpenAI directly or through my own server?
Never direct. The API key cannot ship inside the app binary; a 2026 study found 64% of LLM-powered iOS apps exposed credentials. Routing calls through your own server also lets you cache, meter, swap models and change pricing without an App Store update.
Modeling an AI feature before you build it? Book a free 30-min call →
