Pricing, Credits & Rate Limits
What you pay and how much you can use, on one page: plans, credits, per-API prices, and per-API rate limits. All prices are in Indian Rupees (₹) and exclude GST. Usage is rounded as described in the billing notes for each service.
Plans
Business includes everything in Growth, plus ₹1,99,999 worth of credits included and the best public API rates.
Choose or change a plan from the Sarvam Dashboard. For Enterprise pricing, contact us.
Credits
Sarvam offers ₹100 worth of free credits for every verified user on signup. These credits can be used across any of our APIs, explore, prototype, and build without upfront cost.
Credits are universal and never expire. Once exhausted, add more credits or upgrade your plan from the Sarvam Dashboard.
For commercial production rights when you ship generated audio (Bulbul v3, Content Studio exports, cloned voices), see Commercial Licensing.
If your credits are exhausted, API requests fail with 402 (insufficient_quota_error), which is separate from a 429 rate limit. You can add credits at any time, adding credits does not change your plan or rate limits.
- Add Credits: Top up from the Billing page at any time. Credits never expire.
- Upgrade Your Plan: Higher plans include bonus credits and increased rate limits.
- Enterprise: For volume discounts and custom billing arrangements, email support@sarvam.ai.
Prices by API
Rates are listed for each self-serve plan.
Language Models
The open-weight models (Gemma, GLM, DeepSeek, Kimi, MiMo) are served by Token Factory.
All prices are ₹ per 1M tokens and are the same on every plan. Reasoning tokens, where applicable, are billed as output tokens.
Sarvam Models
Sarvam Prism is billed on input tokens only: output is ₹0 because it returns probabilities, not text. The state is counted once per request, so asking 3 short questions about a 1,000-token state bills a little over 1,000 input tokens. See Token usage.
Open-Weight Models
DeepSeek V4 Pro, Kimi K3, MiMo V2.6 Flash, and MiMo V2.6 Pro are in beta.
Speech to Text
Priced per minute, billed per second.
Text to Speech
Priced per 1,000 characters, rounded to the nearest character. Rates apply to REST, HTTP streaming, and WebSocket streaming.
Text Processing
Priced per 1,000 characters, rounded to the nearest character.
Document Intelligence
Priced per page.
Document Translation
Priced per 1,000 billable characters, per target language. Character count is computed after parsing; each target language in a job is billed separately. Charges round up to the nearest rupee; minimum ₹1 when any billable text is present.
Dubbing
Priced per minute of source media, multiplied by the number of target languages. Duration is rounded to whole seconds before billing.
Editor Flow costs about twice the standard API rate and should only be enabled when the interactive editor workflow is required. See the Dubbing overview.
Rate Limits
Rate limits restrict the number of API requests your account can make within a given time window. Key points:
- Per-account enforcement: limits apply to your account as a whole, not individual API keys. All keys share the same rate limit pool.
- Continuous replenishment: capacity refills steadily over the window period rather than resetting all at once (token bucket model).
- Per-API granularity: each API has its own independent rate limits. WebSocket, Document AI, and LLM APIs have different limits from standard REST APIs. Check your specific API below.
Your current limits are on the Dashboard → Rate Limits page.
Rate limits vary significantly by API type and plan. Review the limits for each API below before building your integration.
Speech to Text limits
Real-time REST
WebSocket Streaming
Batch
For batch endpoints, avoid tight polling loops. Poll no faster than your plan’s rate limit allows, for example every 3 seconds on Pay as you go’s 20 req/min.
The SDK’s wait_until_complete() uses safe defaults out of the box:
- Batch STT / Speech-to-Text-Translate: 5-second poll interval. See Polling Defaults.
- Document Digitization (legacy
document_intelligence): 2-second poll interval.
Document AI has no wait_until_complete() helper. You poll get_status() yourself, so pick your own interval (the examples use 5 seconds).
If you poll manually instead of using the SDK helper, match or exceed these intervals.
Text to Speech limits
Limits are the same for Bulbul v3 and Bulbul v4 Flash.
Real-time REST and HTTP Streaming
WebSocket Streaming
Instant Voice Cloning limits
The sustained figure is the steady-state rate; short spikes are allowed up to the burst figure before requests are rejected with a 429. Limits are subject to change.
Translation & Text Services limits
Text translation (POST /translate)
Transliteration and Language Identification share the same limits.
Document Translation
Job lifecycle endpoints (POST /translate/document/jobs, start, live-status, export, export/status):
Document Translation is asynchronous. Poll live-status every 10–15 seconds (see the overview) rather than tight loops that burn your per-minute quota.
Language model limits
Default models
Applies to: gemma4, glm5.3, deepseekv4.1-flash-1017
Sarvam-105B model
This large model has lower limits due to its compute requirements.
Applies to: sarvam-105b, sarvam-105b-conversations
Dubbing limits
Document AI limits
Document AI limits are set per operation and scale with your plan. Each limit assumes the number of pages per request shown below.
Exceeding Your Limits
REST rate limits (429 / 503)
When your account exceeds a rate limit, the API returns a 429 Too Many Requests response:
A 503 Service Unavailable can also occur under high backend load. Retry it the same way you would a 429, using a fixed exponential backoff. See Retry with exponential backoff for a reference implementation.
Exhausted credits (402)
A 402 Payment Required is not a rate limit. It means the organisation’s credit balance is empty, and no retry will clear it. Add credits on Settings → Billing and the account resumes immediately, with no key rotation or redeploy. See Billing & payments and Out of credits.
WebSocket connection limits
The limiter reacts to how fast new connections are opened, not how many are held open at once:
- Connections opened in a fast burst can be rejected well below the concurrent ceilings listed above.
- The same number of connections opened gradually (for example, 300ms apart) and held open simultaneously can succeed past those ceilings.
A rejected connection is closed, not queued. The close code is 1003, with this reason text:
This differs from the 4xxx range described elsewhere on this site for application-specific closures.
The burst threshold is not a fixed number and can vary between runs at the same burst size. Space out new connections rather than relying on a specific count.