Skip to main content
One number to remember: ₹3 per minute. That is the 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 to t1. Its voice catalogue is two voices — ashu and aishe, 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.
You never have to compute this — 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.
A campaign of 50,000 dials at a 35% answer rate and 80 seconds mean talk time, on t3:
Unanswered dials cost nothing, so the 32,500 that rang out are free. Because the boundary is the minute, the lever is which side of a boundary your calls land on. Trimming an 80-second call to 55 seconds halves its cost; trimming it to 70 saves nothing. Look at the distribution of 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.
See the Wallet reference for the full API.

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-Key is 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.
Alert on balance yourself, hourly, at a threshold covering a day of traffic. A 402 mid-campaign is an expensive way to find out.

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:
Override downward per call when a particular job is simple enough for 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
Design against it if you like — the field name and the values will not change — but do not ship a code path that depends on it until we tell you it is live. Current target: t5 with node graphs in Q4 2026. See the roadmap, and ask your account contact to confirm before you plan a launch around it.