Sarvam Prism: API Pricing, Benchmarks and the Open-Weight Decision Model

Sarvam released Prism on November 3, a decision model that chooses between supplied options rather than writing an answer. Available through an API and open weights, it targets workflows such as routing support tickets and checking agent runs, where a probability can be more useful than another paragraph.

The release makes a practical distinction. A support system may need a long answer when speaking to a customer, but choosing which team should handle the ticket is a smaller problem. Asking a generative model to explain that choice adds work the application may never use.

How Sarvam Prism makes decisions

Prism is a LoRA fine-tune of Sarvam 105B. You supply the context, a question and possible answers. A scoring head produces probabilities in one forward pass, without generating tokens one after another.

Sarvam's release explanation describes training that penalises confident mistakes, alongside an attention design that separates the options before comparing them. This matters when the output becomes a routing decision rather than something a person reads first.

For a support ticket, the choices might be billing, technical support and delivery. The application can send clear cases to a queue and reserve uncertain ones for review. The model supplies a score; the team still has to decide what mistakes it can afford.

Sarvam Prism API pricing and limits

The API documentation lists the following:

Detail	Hosted Sarvam Prism API
Input price	₹4 per million tokens
Output price	₹0 per million tokens
Context limit	32,768 tokens per question
Choice options	2 to 255
Ordered score levels	2 to 10
Modalities	Text only
Streaming	Not supported

The shared context is counted once per request, even when the request contains several questions. Grouping checks avoids resending the same ticket.

The API's context limit is smaller than the downloadable model's. The open model supports 131,072 tokens per question, so a long agent trace that fits locally may still exceed the hosted endpoint's limit.

What the 44-millisecond benchmark means

Sarvam reports a 71.8 average across three evaluation indices, with a 44 ms median response time on one B200 GPU. It says Prism has the best average among the tested models answering in under 100 ms, not the highest score overall.

These are Sarvam's evaluations. The composite includes its recreation of the Artificial Analysis index and an internal Indian-language benchmark, so it should not be read as an independently published leaderboard result.

The model card adds an important number: the 95th-percentile latency was 420 ms. Testing used 1,000 requests sent one at a time after loading. The median is useful, but it does not establish how the service behaves under concurrent production traffic.

For a queue-routing application, that difference may be acceptable. For a decision on the critical path of a live voice conversation, the slower tail deserves its own test.

Confidence is not one interchangeable number

The API returns both option probabilities and a rescaled confidence field. Calibration thresholds apply to the top option probability. With three options, probability 0.80 gives confidence 0.70.

Use the probability when implementing a probability threshold. Treating the two fields as identical changes which requests your application sends for human review.

Calibration on a benchmark also does not guarantee the same error rate on your customers' tickets. A useful first test would run Prism on previously resolved cases, compare the outcomes with your existing process and measure how many cases still need review. Low inference cost has limited value if the review queue grows faster than the work it removes.

Open weights come with a deployment requirement

Prism's weights use the Apache 2.0 licence. The model card specifies an FP8-capable NVIDIA GPU with about 120 GB of free memory and roughly 106 GB of disk space. B200 is tested; H200 is also listed as suitable hardware.

The weights use a custom layout and the supplied inference code. They cannot simply be loaded through AutoModelForCausalLM or served by a general-purpose inference server.

That makes the hosted API the easier starting point for many teams. Self-hosting becomes worth examining when control of the data, sustained utilisation or integration requirements justify operating a large model.

The useful question now is how much of an existing workflow can move from generated explanations to explicit, measurable decisions. Start with a narrow choice whose errors you can inspect, then decide whether the cheaper call actually makes the whole process cheaper.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI founders turn technical launches and product thinking into clear stories developers can use and share.

Book a 30-minute call.