Cost estimates

Every generation costs money to run, and supporting iterative prompting or complicated chained-runs or workflows can quickly add up. Most products pay these costs behind the scenes and roll them into metered usage, governed by credits that refresh regularly or can be purchased in bulk. This guards users from the minutiae of managing individual token counts, but also has the effect of turning AI costs into a black box.

Transparent spend lifts the veil, helping users understand the relative costs of different prompt, parameter, and model combinations before anything runs. Estimated costs are shown beside key actions, and users can see in real time how changing their selection adjusts what they will "pay" in equivilent credits.

Common choices that impact run cost

  • Model size and family: Larger models consume more compute per token. Show estimates from a model selector so users balance the power with what they are willing to pay for it.
  • Prompt length and context window: Longer prompts, or more complicated actions like deep research, require more thinking power from the AI. Update cost estimates plainly when users change mode or direct the model to think harder.
  • Expected output length: Expansive or detailed responses use more output tokens. Encourage draft mode so users can spend less when still working through ideas.
  • Number of steps in a chain or agent plan: Workflows and chained actions can quickly run up. Show the full cost of the run as well as costs at a per-step level to help users facilitate an effective process.
  • Number of inference steps or loops: Each computational cycle the model uses to refine its thinking adds to the overall cost. In addition to credit-spend estimates, allow more advanced users to adjust the step count to govern how many cycles should be completed to return a result.

Credits or dollar values?

In AI playgrounds and development environments, credits may be priced in local currency to normalize the cost to a common denominator. This is helpful for technical users, but non-technical users are likely to be confused when seeing a dollar amount on top of the cost of their subscription.

Non-technical users benefit from a clear product-based credit system. However, the tradeoff to using product-specific currency is that there is no standard. Users working across multiple products will not have a consistent way of comparing the relative cost of different iterations of inputs and parameters. This standard may evolve overtime but it currently creates usability risks to be aware of.

Design considerations

  • Make the unit explicit. Tell users exactly what you are estimating, such as “~3,200 input tokens, ~1,000–2,000 output tokens,” or “12 credits for 1 second of Gen-4 video.” People make better trade-offs when they see the base unit and the currency mapping.
  • Anchor estimates in the units people understand. Users reason differently across modalities: tokens in text, characters in TTS, seconds in video, credits in consumer apps. Always map these back to money where possible, and explain any conversion rules so the relationship between effort and cost is transparent.
  • Show ranges for unknowns. You cannot know output tokens before the run. Present a low–high range based on max tokens or typical lengths, and update in real time during streaming. This sets expectations and prevents “estimate drift.”
  • Surface the drivers of cost. Break the estimate into components, for example system prompt, retrieved context, user input, tool calls, and expected output. Call out the heavy parts so users can trim the right thing.
  • Offer cheaper paths when relevant. If the task is non-urgent or batched, propose batch mode with the updated estimate and time window. When caching applies, show the expected cache read savings in the estimate.
  • Reward onboarding. Ensure users have sufficient tokens for onboarding so they can sufficiently work with the program to understand it while interested to do so. Some products reward onboarding and other key flows with a token pack, making up for tokens spent during that initial run and giving users a boost to stay.
  • Put estimates where decisions are made. Inline next to the prompt, per-step in builders, and on action buttons in credit-based tools. Avoid burying the estimate in settings.

Examples

Krea includes the credit cost estimate at the bottom of the builder sidebar so users can understand the weight of different parameters.