t3 conversational
tier, it is what a new key is issued at, and it is what every example in these
docs uses unless it says otherwise.
t5 is published so you can plan against it. Requesting it today returns
501 tier_unavailable — see when it arrives.
Why t3 is the default. It is the always-on path: it speaks through a
premium third-party voice catalogue with no dependency on our own GPU fleet, so
it is the tier that is up whenever the API is up. t1 runs on the Mira stack at
a third of the price and a smaller voice catalogue — a deliberate trade, and the
right one for high-volume transactional work. Ask for it explicitly:
Feature matrix
What the tier buys is not a discount, it is what the call can do.
Every call is opened. On every tier, each completed call gets an AI summary
and a QA score — 100% of calls, not a sample. Warm transfer to a human is part
of the same lattice: any tier can hand a caller to a person. See the
roadmap for rollout status of both on
t1.
Read the ❌ as a contract. A ❌ is not “degraded”, it is “absent”. On t1
there is no node-graph runtime and no IVR navigation — the call is one prompt,
start to finish. That simplicity is what makes ₹1 possible.
Picking a tier
t3(default) — start here. Premium voices, no dependency on our GPU fleet, and the tier every example in these docs is written against. If you are not sure, you want this.t1— one job, under two minutes, no branching, at volume. Order confirmations, delivery windows, appointment reminders, OTP-adjacent notifications, “are you still interested?”. If you can write the whole call as one prompt, it ends when the customer says yes or no, and the volume makes ₹2 a minute worth optimising for, drop tot1. Its voice catalogue is two voices —ashuandaishe, see Voices.t5— you want to author the flow yourself, node by node, and version it like code. Not live.
What a minute costs
Billing is per-minute blocks, rounded up, with a one-minute minimum. The minute is the billing unit, not just the price: a call is not prorated to the second, and a part-minute is a whole minute.Metering
duration_secs on the call object is the true
media duration in seconds. The charge is that duration rounded up to the
next whole minute, never fewer than one, times the tier rate. A call that
never connected is not billed at all — see the table below.
cost_inr on the call object and the
debit row in the ledger are authoritative. Use
the formula to forecast, not to reconcile.
What is and is not billable
The rule underneath: if media went live, you pay for it. A voicemail
consumed a real dial, real TTS and real minutes of carrier time, so it is
billed. A call our own pipeline broke is not.
Forecasting a month
Take your answer rate and your mean answered-call duration: Round each answered call up to a whole minute first, then multiply. Averaging the seconds and dividing by 60 will under-forecast, because the rounding happens per call and never cancels out.t3:
duration_secs,
not the mean — a cluster sitting just past 60 or just past 120 is the cheapest
thing you will ever fix, and a prompt that caps reply length is usually what
moves it.
Wallet
Billing is prepaid against one INR wallet per workspace.- Debits happen at call end, one ledger row per billable call, carrying the
call_id. - Top-ups are not self-serve yet — see the roadmap. Your Mirai contact credits the workspace; it lands within minutes and applies immediately.
- The ledger is the source of truth for reconciliation:
GET /v2/wallet/transactions.
At zero balance
Before dialling, we check the wallet can cover at least one minute at the call’s tier. If it cannot:402 Payment Required
- No phone rings. No charge. No call object is created.
-
The
Idempotency-Keyis not consumed — retry with the same key after topping up. - Calls already in flight are not killed. A call that started with credit runs to its natural end and then debits. Your balance can therefore dip below what the pre-dial check implied during a busy minute.
-
Inside a campaign this is not an error. The campaign
pauses itself with
pause_reason: "insufficient_balance", keeps every contact’s place, and continues from there once you top up and start it again.
402 mid-campaign is an expensive way to find out.
- Python
- Node.js
Setting the tier
Your key carries a default tier —t3 unless you asked for something else.
Every call and every campaign inherits it unless you override:
t1.
There is no way to set a tier per agent: the same agent can be run at either
rate.
The call object reports the tier it ran at alongside cost_inr, so you can
always see which rate card a given call was billed under. A
campaign sets its tier once, at create time, and every call it
places inherits it.
Coming soon
t3 went live in August 2026 and is now the default.
t5 is in the contract but not in production. Today:
501 Not Implemented
t5 with node graphs in Q4 2026. See the
roadmap, and ask your account contact to confirm before you
plan a launch around it.