If you ship AI features behind credits, you are doing two jobs at once: product pricing (what feels fair to the user) and unit economics (what you can afford per action). The mistake is collapsing both into a single panic spreadsheet, or worse, exposing provider tokens in the UI.
This note is for founders, PMs, and engineers who already decided to meter events and need a sane way to attach credit costs to chat, image, and agent surfaces — without locking yourself into a model you cannot explain next quarter.
You will leave with a first-pass matrix, a simple decision rule for when to split events, and a clear sense of when Chargly’s Pricing Advisor earns its place in the loop.
Why credits need a deliberate first map
Credits are not magic; they are a layer of indirection. Users see “8 credits for a reply”; you map those credits to wallet deductions and, internally, to provider spend. If the map is arbitrary, support tickets explode. If it is too literal to token receipts, you recreate token chaos with extra steps.
A working first map does three things:
- Keeps one vocabulary across marketing, product, and ledger (same event names users see in history).
- Makes relative prices intuitive — a reply is cheaper than an image; an agent run costs more than a single reply.
- Leaves room to move when models or prompts change, without renaming the product.
A concrete starting matrix (then tune)
Assume you meter chat.reply, image.generate, and agent.run (or equivalents). A common first pass looks like order-of-magnitude spreads, not precision engineering:
| Surface | Why it often costs more | First-pass instinct |
|---|---|---|
| Chat reply | High volume, lower marginal cost per user turn | Lower credits per action |
| Image gen | GPU / provider step cost, fewer calls | Several × chat |
| Agent run | Tools, loops, variable context | Highest bucket, or split later |
Example (illustrative only — your numbers depend on your margin and pack price):
chat.reply→ 8 creditsimage.generate→ 40 creditsagent.run→ 25 credits
The absolute numbers matter less than ratios and explainability. Users should roughly understand why an image “costs more” than a message.
Start simple
Ship a small table, document it internally, and meter consistently. You are calibrating a product surface, not proving a theorem on day one.
Chat vs image vs agent: what usually breaks
Chat fails when you under-price high-context threads or expensive models while pretending every reply is identical. If power users hammer long contexts, either split events (e.g. “long thread reply”) or raise the default cost once you see data.
Images fail when you blend standard and premium generation under one price. If users pick quality or resolution in-product, different user-visible tiers usually deserve different events — same rule as billable events: would a user understand two prices?
Agents fail when one agent.run hides ten tool calls. Sometimes a per-run price is still right for UX; sometimes you need per-step metering for fairness. Choose based on whether users experience the agent as one action or many.
Connecting back to provider cost (without showing it)
You still need a private story: “At these credit prices and our pack economics, we target roughly X margin on chat and Y on images.” You do not need to show that story to customers.
When provider invoices move, you want a controlled response: adjust credit costs, adjust pack sizes, or absorb margin temporarily — not ad-hoc patches in three places. That is where versioned pricing rules and a deterministic advisor help: suggestions you can accept or reject, with history.
How Chargly fits without taking over your judgment
Chargly holds wallets, metered events, and pricing rules in one place. Pricing Advisor looks at cost signals, margin targets, and usage and proposes credit-cost changes you can apply or reject — no silent overwrite, no black-box autopricing.
That matters because pricing is a product decision, not a nightly cron. The tool should reduce spreadsheet time and alignment friction, not remove your team from the loop.
Use Pricing Advisor when you have enough usage to see skew — not before you have a baseline matrix and stable event names.
Adjusting over time
Provider costs change. Usage patterns shift. Pricing Advisor surfaces recommendations with explanation; you choose what ships. Applied changes become new immutable rule versions, so you can answer “what did we charge last month?” without archaeology.
If you are early, your best investment is still clean events and honest first costs. Intelligence layered on messy metering only recommends faster confusion.
When your matrix is stable and your ledger language matches your product, pricing work starts to feel like iteration instead of firefighting — which is the whole point of credit-first billing done well.