# GenUI Run Rate Economics: The Four Cost Drivers

> A GenUI experience costs more than a static UI. We price one retail session step by step, then break the run rate into four drivers you control.

- Source: https://verygood.ventures/blog/gap-3-run-rate-economics/
- Published: 2026-07-29
- Author: Juan Rodríguez
- Tags: GenUI, AI, Engineering

---

Three conversation turns, three tool calls, about $0.083. That is what one GenUI retail session costs against Claude Sonnet 5 in July 2026, and this post shows you the math line by line. The number is made of four things your team can measure and control: model tokens, tool calls, model choice, and prompt caching.

If you are the person who has to defend a GenUI line item before it ships, this is the math to bring to that meeting.

GenUI lets an app build its interface on the fly, using components the app already knows how to render. To understand what this means in practice, see [the GenUI overview](https://verygood.ventures/resources/genui/).

Let's model one scenario. This is only an estimate, used to illustrate the point, and we will use this same scenario for the rest of the post. A shopper opens a retail app and asks for running shoes under $150. The app replies with a `ProductCard` list. The shopper taps the top result and asks if it is in stock. The app replies again, with the same card plus an availability line. The shopper asks for the same shoe in a different color. The app replies a third time, with a variant card. That is three turns in the conversation, and three tool calls: `catalogSearch`, `inventoryCheck`, and another `catalogSearch` for the variant.

## One session costs about eight cents

Using the retail scenario above, and pricing it against Anthropic's Claude Sonnet 5 in July 2026, the cost comes to about $0.083 per session. This includes three conversation turns, three tool calls, and six model round trips in total. This is a modeled number, not a real bill or a quote from a customer.

Per active user, per month, the cost depends on how often people use the app. If a user has three sessions per month, that is about $0.25. If a user has ten sessions per month, that is about $0.83. The lower number matches an e-commerce app where about one in ten monthly users comes back daily. The higher number matches an app with more daily use. Neither of these is a real benchmark. They both come from the same math, just applied at different levels of usage.

You can reproduce this math using three inputs: the model's price per token on a given date, the length of the three-part prompt, and how the session is shaped. Every dollar figure below comes from those three inputs. If you use a different model, or price it on a different date, the overall shape of the run rate will stay the same. The exact numbers will not.

## Driver 1: Your prompt is billed on every single turn

Every GenUI request combines three system prompts, in this order: first the A2UI mechanics, then the catalog prompt, then the system prompt. After that comes the chat history so far, plus the current user message. All of this is billed as input tokens, on every single model call.

In our retail scenario, these three prompts together add up to about 2,500 input tokens. This number stays the same on every turn. What changes is the chat history, which grows as the conversation continues.

To keep things simple, let's imagine there are no tool calls for a moment, so each turn is just one model call. Here is how the input-token bill grows:

| **Turn** | **Prompt + history + user** | **Input tokens** |
| --- | --- | --- |
| 1 | 2,500 + 0 + 30 | 2,530 |
| 2 | 2,500 + 530 + 15 | 3,045 |
| 3 | 2,500 + 1,045 + 15 | 3,560 |
| Sum |  | 9,135 |

The output is a `ProductCard`-shaped A2UI response, using about 500 tokens per turn, or 1,500 tokens across the whole session. This number can be higher or lower depending on how many cards are shown.

Using Sonnet 5's rates ([$3.00 per million input tokens and $15.00 per million output tokens](https://www.anthropic.com/pricing)), the token cost in this no-tool scenario is about $0.050 per session: $0.027 for input and $0.023 for output.

This lever is the three-part prompt itself, because its length decides your input-token bill. Every word you add to the catalog prompt gets billed on every turn, in every session, and the same is true for the system prompt. Each of these prompts has a different job: the catalog prompt decides which component to use, and the system prompt sets the app's voice and audience. Therefore, make sure to keep prompts as small and focused as possible while remaining effective.

## Driver 2: Tool calls are 40% of the bill

A tool call costs more than just calling a backend API. Each one needs a second model call. First, the model reads the prompt and decides to return a `tool_use` request. Then the backend runs that tool, and sends everything back to the model in a second call: the original prompt, the `tool_use` request, and the tool's result. Only after that does the model produce the final A2UI response.

This means that three tool calls in our retail session actually need six model calls in total, not three. Every one of these six calls has to pay for the same ~2,500-token prompt.

Each of the three second-round calls pays for the prompt again, plus the growing chat history, plus the small `tool_use` and tool-result data. Together, these tool round trips add about 11,000 input tokens across the session, which is more than the entire no-tool case from Driver 1.

At Sonnet 5's rates, this full six-call session costs about $0.083. Of that, about $0.033 comes from tool overhead alone, or about 40% of the run rate. [Gap 1](https://verygood.ventures/blog/gap-1-hallucinations-in-genui/) already talked about this trade-off, in Layer 3, where a tool call meant an extra model round trip, and extra latency, on every request. Here, we finally put a dollar amount on that trade-off.

This lever is about using information you already have. Details like the user's locale, home store, or cart contents can go directly into the system prompt, instead of being fetched through a tool call, which saves you a round trip. For example, if the server already knows the user's home store, it might not need to call `inventoryCheck` at all. Using this lever mainly costs a bit of server code, plus one variable added to the system prompt.

## Driver 3: A 10x cheaper model can cost you more

Per-token pricing can be very different between the mid-tier models a GenUI backend can use. Sonnet 5 costs $3.00 per million input tokens. [Gemini 2.5 Flash](https://ai.google.dev/gemini-api/docs/pricing) costs $0.30 per million input tokens, which is 10 times cheaper. Opus 4.8 costs $5.00 per million input tokens, which is 1.7 times more than Sonnet 5.

But cost is not the only thing that matters. The quality of what the model produces is also part of what you are paying for. A cheaper model may fail more often on the structural or semantic checks described in [Gap 1](https://verygood.ventures/blog/gap-1-hallucinations-in-genui/). Those failures cost you through retries, and through a worse experience for the user, so the real cost can be higher than the per-token price suggests. The response validator's retry-once safety check catches structural failures, but it also doubles the model cost each time it triggers. In our retail session, one triggered retry on a single turn adds roughly $0.014, so a model that fails validation 20% of the time can erase most of a 10x per-token discount before you count the user experience cost.

A single environment variable lets you change the model for each deployment, and you choose the provider when you set up the backend. Changing the model is just a configuration change, not a code change. The backend can also choose a different model for each request, so a browsing screen and a checkout confirmation could use two different models, while still using the same catalog.

As a practical rule, choose your model based on the experience. A high-stakes checkout confirmation is a different kind of task than a browsing recommendation. It is worth paying for a stronger model where a bad response is expensive, and saving money where the risk is lower.

## Driver 4: Caching cuts the session 38%, but only if you turn it on

Prompt caching charges a lower rate for input tokens the model has seen recently. Anthropic offers this on Sonnet 5: a cache hit costs $0.30 per million tokens, compared to $3.00 per million for an uncached request, which is 10 times cheaper. The first request that fills the cache pays a small extra fee, $3.75 per million tokens, and this cached version lasts for five minutes.

Our retail scenario is a good fit for caching, because the three-part prompt stays exactly the same on every turn, in every session. The catalog's JSON schemas do not change between turns, so only the chat history grows over time. This means the real savings come from the stable part of the prompt, which is the first 2,500 tokens of every call.

Let's apply caching to that same six-call session and see how the math changes. The first call writes those 2,500 stable-prefix tokens at $3.75 per million, which costs $0.0094. The next five calls simply read those same 2,500 tokens, at $0.30 per million each, costing $0.0038 in total. The remaining input, about 5,200 tokens across the session, is billed normally at $3.00 per million, costing $0.016. Output stays the same, at $0.023.

In total: with caching, the session costs about $0.051. That is a saving of about $0.032, or roughly 38% off the original run rate.

Part of these savings comes from the prompt structure itself. Putting the stable content first, at the start of every request, is exactly the shape that prompt caching rewards, and this is the foundation the whole discount is built on.

The rest is up to you. Prompt caching does not turn on automatically. You need to enable it on the provider's side. For Anthropic, this means adding `cache_control: {"type": "ephemeral"}` breakpoints to the stable system messages inside your LLM client wrapper. This is a single integration point, at the level of the LLM client.

## Learn more

The [GenUI Kit](https://verygood.ventures/resources/genui-kit/) lets you see the input and output tokens for every round trip. You can use these numbers, together with your model provider's pricing, to understand what a GenUI system really costs to run, and to help decide which models are worth it for the ROI you need. If you'd like to read more on this topic, check out the [Very Good Ventures blog](https://verygood.ventures/blog/?tag=GenUI).