Token economics
What a chat costs Rezide, how we count usage, what a broker sees, how a plan is sized, and how we get from charging for usage to charging for results. Written so anyone on the team can follow it. Figures measured on this agent, 16–19 Sep 2026 · prices as listed that week · ₹95.7 per US dollar.
The one-minute version
- AI models charge by the token, a piece of text about three-quarters of a word. We pay for what we send and for what the model writes back.
- We moved the agent from Claude Opus 5 to OpenAI's GPT-5.6 Luna and cut the prompt by more than half. A listing chat went from about ₹41 to about ₹0.45, and replies got about 31% faster.
- Brokers see a percentage of their plan, never token counts. Underneath, we count tokens weighted by what each kind costs us, so the percentage moves exactly in step with our bill.
- A ₹500 plan at a 20% margin is sized at 10 million counted tokens a month, 1 million a day. A ₹100 voice pack is 120 minutes.
- We do not promise "listings left", because one listing can cost two to four times another. Charging per listing is the goal, and the last section explains how to get there safely.
1. What we actually pay for
Every time the agent replies, it sends the model three things: its instruction sheet (the skills and the tool descriptions), the conversation so far, and the broker's new message. The model then writes a reply. Providers price these differently:
| Kind of token | What it is | GPT-5.6 Luna, per million | Relative price |
|---|---|---|---|
| Fresh input | New text the model has not seen: the broker's message, a tool's result | $0.20 · ₹19 | 1× |
| Cached input | Text the model saw moments ago and the provider kept warm: mostly our instruction sheet, re-read on every call | $0.02 · ₹1.9 | 0.1× |
| Output | What the model writes: the reply and its tool requests | $1.20 · ₹115 | 6× |
Cached tokens are cheap, but there are a great many of them. Measured across 79 real chats on Luna, this is where the money went:
So 93% of all tokens were cached, and they still made up nearly half the bill. That single fact drives every decision below.
2. What we did to bring the cost down
| Change | What it did | Effect |
|---|---|---|
| Prompt caching (already in place) | The instruction sheet is billed at the cached rate after the first call | 95–98% of tokens cached |
| Primary model: Claude Opus 5 → GPT-5.6 Luna | Tested five models on the same 41 broker conversations. Luna held the confirmation step every time and never tried to create a listing unprompted. GPT-5.4 mini, Sarvam-105B and Claude Sonnet 5 were rejected on behaviour, not price. | ₹125 → about ₹3 per million tokens |
| Load only the property type in play | A flat listing no longer carries the office, shop, land and warehouse instructions and tools | prompt 57% smaller · replies 31% faster |
| Provider chain with failover | If OpenAI is down, Claude picks up mid-conversation. The broker never sees an error. | reliability, at a cost we reserve for |
| Luna-specific instructions + a code safeguard | Stops a guessed price reaching the draft, and drops any listing feature the broker never gave. These protect trust, not cost. | 39 of 41 scenarios |
3. How we count usage, with a worked example
We need one number that says "how much of the plan did this use". We tried three ways of counting and measured how well each tracked what the chat really cost us:
| Way of counting | Problem | Cost per counted unit varies by |
|---|---|---|
| Only full-price tokens (ignore cached) | Ignores half our bill. A broker with long chats costs us far more than the count shows, yet pays the same. | 8.9× |
| Every token, counted one for one | Overcharges cached tokens tenfold. A typical chat shows 77,000 tokens instead of 5,300: alarming and unfair. | 2.4× |
| Tokens weighted by cost — what we use | Fresh input counts 1, cached 0.1, output 6: the model's own price ratios. The cached charge is passed on at its true discounted rate. | 1.0× (exact) |
Example: one ordinary turn
A broker types "Tower B, unit 1204". The agent looks the unit up and replies. Say the model call used 800 fresh tokens, re-read 11,000 cached tokens of instructions and history, and wrote 150 tokens:
Because the weights are the model's own price ratios, our cost on Luna is always ₹19.14 per million counted tokens, whether the chat is short or long. A real turn from the portal, right after the cache had gone cold: 22,400 tokens in total, 11,000 cached, counted as 13,300, cost ₹0.254.
The weights stay fixed to our primary model on purpose. If OpenAI has an outage and Claude serves the turn at forty times the price, the broker is charged exactly the same. That risk is ours, and section 5 shows where we reserve for it.
4. What a broker sees, and what Rezide sees
The broker sees a percentage
The same way Claude shows usage: how much of the limit is gone and when it resets. Voice the same way, in minutes.
Never shown to a broker: token counts, the cached and fresh split, which model answered, failovers, or our costs. A token means nothing to a broker, and "why did saying hi cost 12,000 tokens?" is a conversation nobody needs.
Not shown yet: "listings left". See section 6.
Rezide ops sees everything
For every model call: broker, organisation, chat, turn, provider, model, all four token buckets, the cost at the provider's own rate, tokens counted against the plan, voice seconds, and whether it was a failover.
The portal has a temporary Dev / Prod switch in the sidebar. Dev adds a panel under the chat with this turn and this chat broken down; Prod is exactly the broker's view. It only appears when the gateway is started with REZIDE_DEV_USAGE_VIEW=true, which production must never set.
Making our numbers match the provider's invoice
We already record the provider's own token counts and cost on every call, which is the hard part. What is still needed for the totals to tally line by line:
| Step | Why | Status |
|---|---|---|
| Separate API keys for production | Tests and development share keys with everything else today, so an invoice can never match | to do · a settings change |
| One ledger row per model call | A turn that fails over mid-way is currently tagged with only the last model | metering integration |
| A stable broker ID and an organisation ID on every row | Limits hang off a login-token hash today, which changes at each login, so a monthly window would restart | metering integration |
| Calls the provider billed that we never recorded | Timeouts after partial output, and retries | metering integration |
| Voice seconds and web lookups in the ledger | Voice is tallied per chat now, but not in the ledger and not enforced | partly done |
| A daily reconciliation job | Compare our totals with each provider's usage report; alert beyond 1% drift | metering integration |
5. Sizing a plan
"20% margin on our price" means that of every ₹500 a broker pays, ₹100 is ours and ₹400 is what we can spend on models.
- Why the reserve is so large. A call served by Claude Opus costs roughly forty times a Luna call. If just 2% of calls fail over, our cost nearly doubles. A cheaper Claude fallback would let us shrink the reserve and offer more tokens for the same price.
- Why 10% a day. A broker who uses the whole plan over 22 working days averages about 450,000 a day. One million leaves more than double that for a busy day, while making sure a runaway session or a shared login cannot burn the month in under ten days.
- If ₹500 includes GST, the net is ₹424 and the plan becomes about 8.5 million tokens. Payment gateway fees of around 2% also come out of the margin unless priced in.
- A voice note is also a chat turn, so its tokens come out of the token plan. The voice pack covers transcription only.
6. Why we do not promise "listings left"
It is the number a broker would most like to see, and the one we cannot honestly give yet.
| Test conversations that reached a complete draft | Counted tokens |
|---|---|
| The cheapest tenth | about 17,000 |
| Typical | about 22,000 |
| The most expensive tenth | about 40,000 |
That is a 2.4 times spread, and these are scripted test brokers who give everything in one or two messages. Real brokers take more turns, correct themselves, change their mind about the property type, send voice notes, ask questions, and abandon drafts halfway, which cost us tokens and produce no listing. Depending on the assumption, ₹500 works out to anywhere between about 140 and about 600 listings. We commit to the percentage, which is exact and auditable. A listings estimate can come later, per broker, from their own history, worded as an estimate.
7. Next steps
- Top up the Anthropic account. It ran out of credit on 18 Sep, so the Claude fallback cannot serve until it is funded. Then run the test suite on Claude with the shortened prompt, which has not been verified there.
- Separate API keys for production with each provider, so invoices can be matched.
- Integrate the metering service (built separately on Lago): per-call ledger rows, a stable broker ID and organisation ID, voice and web lookups metered, limits fed from the broker's plan, and a daily reconciliation against provider invoices. It replaces the temporary Dev view.
- Enforce the voice limit. Minutes are counted today, but nothing stops a broker at 120.
- Tune a cheaper Claude fallback. Claude Sonnet 5 costs 40% of Opus but needs its own instructions before it behaves. It would shrink the reserve in section 5.
- Run a two to four week pilot with real brokers with the ledger switched on. Everything in section 8 depends on that data.
8. From usage-based to outcome-based pricing
Today a broker buys capacity: a share of a token plan. What a broker actually wants to buy is a result: a listing that goes live, or better, a listing that brings leads. Outcome-based pricing charges for that result and keeps tokens entirely behind the curtain. It is easier to sell and easier to understand. It also moves the risk of an expensive conversation from the broker to Rezide, so it has to be earned with data.
Usage-based, shown as a percentage
What is built today. Its real job for the next month is to collect data safely.
Measure the cost of an outcome
Tag every chat in the ledger with how it ended: listing created, approved by moderation, rejected, or abandoned. Then the true cost of one successful listing is its own tokens plus its share of the drafts that went nowhere.
These inputs are from test data and an assumed abandonment rate. The pilot replaces them with real ones.
Shadow pricing
Keep charging by plan, but calculate in the background what each broker would have paid per listing. Look for the brokers on whom a per-listing price would lose money, and learn why: abandoned drafts, very long chats, heavy voice use.
Hybrid: a plan that includes listings
For example "₹500 a month includes 100 listings, then ₹5 each". The token percentage stays, but only as a quiet fair-use guard. Brokers think in listings; we stay protected.
Pure outcome pricing
Pay per published listing, or later per qualified lead. Usage disappears from the broker's view altogether. Internally we watch cost per outcome and alert when it drifts.
The point the numbers make
Even a hard listing costs us about ₹2 in AI. So the price of a listing should not be set by our cost; it should be set by what a live listing is worth to a broker. Cost only tells us the floor and how much abuse we can absorb. That is the real argument for outcome pricing: it lets Rezide charge for value, where token pricing forces a conversation about cost.
Rules to settle before charging per listing
| Question | A sensible starting answer |
|---|---|
| What counts as a listing? | Created and approved by moderation. A rejected listing is not charged. |
| Who pays for abandoned drafts? | Rezide, built into the per-listing price, as in the Stage 1 sum. |
| What stops one endless conversation? | A fair-use ceiling per listing, around 80,000 counted tokens, twice the hardest listing seen in testing. Beyond it the agent offers the listing form. |
| Are edits after publishing free? | A small number per listing, then counted, so a listing cannot become a free chat line. |
| Is voice included? | Bundle a fair allowance per listing; do not meter it separately. |
| What if the fallback model serves the chat? | Same price to the broker. The reserve covers it, as it does today. |
What must be true first
- A stable broker ID and organisation ID, so an outcome can be attributed and billed.
- Outcome events in the ledger: created, approved, rejected, abandoned, and later leads received.
- A cost-per-outcome view for ops, per broker and per organisation.
- At least four weeks of real broker data. Without it, a per-listing price is a guess.
Words used on this page
| Token | The unit models read and write in, about three-quarters of a word. |
| Cached token | Input the provider has kept warm from a moment ago, billed at a tenth of the price or less. |
| Counted (plan) token | Our unit for limits: fresh input ×1, cached ×0.1, output ×6. In the code: planTokens. |
| Failover | When the primary model's provider fails and the next model in the chain answers. |
| Margin on price | The share of the price that is ours. 20% margin on ₹500 leaves ₹400 for costs. Not the same as a 20% markup on cost. |
| Outcome-based pricing | Charging for a result, such as a published listing, not for the capacity used to produce it. |
Sources: this repository's eval runs and gateway sessions (16–19 Sep 2026); OpenAI, Anthropic and Deepgram price lists as of that week. Detailed reports: docs/evals/model-comparison-2026-09-17.html and docs/evals/sarvam-105b-eval-report-2026-09-16.html.