The Cost Equation

By Syncfusion®, Inc. · Last updated November 2, 2026

Write the full LLM cost equation in TypeScript or C#: calls per step, cached input, output and reasoning tokens. Forecast 10K, 100K and 1M requests a month, cost per user and per case, and find the driver that moves the bill most.

What you will learn

• Price one request from average calls per step, cached input, output and reasoning tokens
• Forecast monthly cost, cost per user and cost per case at 10K, 100K and 1M requests
• Project compound monthly growth
• Rank cost drivers with a sensitivity check

How Much Will This Cost at Launch?

Your manager asks a simple question: "What will the support agent cost at a million tickets a month?"

You have one ticket's records from the last lesson. Now you need an equation you can trust, and that you can change when the design changes.

A request is not one call. It is several steps, and some steps run more than once.

Press Play, or use Next to go one step at a time.

• Frame 1: the five steps of one ticket, as a stacked bar.
• Frame 2: the same ticket with "thinking" turned on for the reply.
• Frame 3: the monthly bill at three volumes.

Simple lesson: cost per request is a sum over steps, and each step has its own calls and tokens.

A Real-World Example

A team priced their agent from one call: "about $0.0004 per request". The real bill was six times higher.

The agent ran its tool step two or three times. Retries added more. Their number was one call, not one request.

Simple lesson: use average calls per step, from your records.

What You Will Build

In this lesson, you will learn:

1. the full cost equation: calls, cached input, output and reasoning tokens
2. how to forecast cost per month, per user and per support case
3. how to find which driver moves the bill most

You will finish three files in the forecast folder:

• Equation (src/forecast/requestCost.ts, or Forecast/RequestCost.cs): dollars per request.
• Forecast (src/forecast/forecast.ts, or Forecast/Forecast.cs): volumes and growth.
• Sensitivity (src/forecast/sensitivity.ts, or Forecast/Sensitivity.cs): what moves the bill.

Open the Code tab. The harness has the ticket as five steps, with average calls per step from your records, and the price table.

Simple lesson: the equation is code, so the forecast changes when the design changes.

The Full Equation

For each step:

• uncached input tokens × the input price
• cached input tokens × the input price × the cached share (25% in the lab)
• output and reasoning tokens × the output price
• all of it × calls per request

Then add the steps together.

Run the cell. The agent step is most of the bill, because it runs 2.3 times with a large prompt. One request costs about $2.57 per 1,000.

Simple lesson: count every token you pay for, not only the ones the user sees.

Forecast the Month

From cost per request:

• monthly cost = requests a month × cost per request
• cost per user = monthly cost ÷ active users
• cost per case = cost per request × requests per case (a first message plus follow-ups)
• growth compounds: month 12 has (1 + growth)^11 times the traffic of month 1

Run the cell. At 15% growth a month, month 12 costs more than four times month 1.

Simple lesson: volume times cost per request, with growth compounding.

What Moves the Bill Most?

A sensitivity check changes one input at a time and measures the effect. It tells you where to optimise first.

The harness has five what-ifs: more input tokens, more output, one more agent step, reasoning on the reply, and caching the agent prompt.

Run npm run forecast (or dotnet run -- forecast). Input tokens move the bill most: +50% input is +47% cost. Caching the agent prompt saves 46%. Output tokens barely matter for this agent.

Try it on a real model. Send the same question with and without a long prompt, and see the real token counts in the usage block. Switch Model to Real in the lab's top bar. It runs an open model in your browser with WebLLM, and needs WebGPU. It is not graded.

Simple lesson: measure which driver matters before you pick a lever.

Put It in Your App

• Feed it from records. Average calls, input and output per step come from your cost records, per feature.
• Keep prices in one dated file. Prices change. The forecast should read the same table your meter uses.
• Re-run on design changes. A new tool, a longer prompt or a reasoning model changes the forecast. Run it in the design review.

Simple lesson: the forecast is a living model, fed by real records.

Common mistakes

Check Your Understanding

Exercises

Build It in the Project

The other files of this lesson's project are optional practice. Finish them to run the lesson's script on your own code.

What to Remember

• Cost per request is a sum over steps, times calls per step.
• Cached input is cheaper, and reasoning tokens are billed as output.
• Forecast per month, per user and per case, with growth.
• A sensitivity check shows which lever to pull first.
• Feed the equation from your records, and keep prices in one dated table.

Next: Pricing an AI Feature. You will turn cost per user into a price that covers the heaviest users.