Sarvam API n Greater Than 1 Error: How to Get Multiple Completions

If a Sarvam Chat Completions request with n: 3 now returns 400 invalid_request_error, remove n or set it to 1. Sarvam's November 7 change allows only one completion per request across models on both /v1 and /v2. Multiple candidates now require separate requests.

This matters for applications that generate several drafts, rank possible answers or sample model behavior for an evaluation. The model can still generate alternatives, but the application has to manage how those requests finish, fail and consume its budget.

Confirm that n is the failing parameter

The Sarvam changelog records the one-completion rule. The current Chat Completions documentation gives the message 'n' must be at most 1. and lists the same restriction across its V2 model table. This is a request-validation error. Retrying the unchanged payload will not make it valid.

Inspect the serialized request your application sends, not only the code where you call the SDK. A shared generation helper or evaluation framework may insert n after your own configuration has been applied. Log parameter names and safe configuration values while keeping prompts, credentials and private customer data out of diagnostic output.

Make the smallest diagnostic change first: send the same chat request with n: 1. If it still fails, read the returned error instead of assuming every 400 comes from this change. An unsupported parameter or malformed message can produce a separate failure.

Do not copy the chat fix into Responses

Chat Completions and Responses have different parameter contracts. For open-weight models on Sarvam's Responses endpoint, n is unsupported even when its value is 1. Omit it rather than using the chat repair unchanged.

Keep request builders specific to the endpoint. A generic configuration object that spreads every generation setting into both APIs makes small compatibility changes much harder to diagnose. The application should know which fields it supports before it makes a network request.

Generate candidates as separate operations

Suppose a product currently asks for three possible release-note introductions in one call. Replace that operation with three one-completion calls and assign each a stable local candidate number. The following is orchestration pseudocode, not a tested Sarvam SDK example:

for candidate_id in [1, 2, 3]:
    request = copy(base_chat_request)
    request.n = 1
    try:
        response = send_chat_request(request)
        save(candidate_id, response, status="completed")
    except RequestError as error:
        save(candidate_id, error_category(error), status="failed")

Start sequentially because the behavior is easy to inspect. Once that works, introduce bounded concurrency if the latency matters and your account limits allow it. Three successful calls can return similar text; separate requests do not guarantee three distinct ideas. If variety is a product requirement, define different editorial constraints for each candidate and evaluate whether they actually produce useful alternatives.

For the release-note example, candidate one might lead with the developer problem, candidate two with a concrete workflow and candidate three with the deployment constraint. That is a deliberate change in the generation task, not a claim that it reproduces the old sampling distribution.

Handle partial success without regenerating everything

Imagine candidates one and three finish but candidate two receives a transient error. Keep the two completed results. If retrying candidate two is appropriate, retry that candidate alone, within a bounded attempt count and deadline. Restarting the entire group creates extra cost and can replace good results unnecessarily.

Make the completion policy explicit. An interactive interface might show two candidates with a clear indication that one failed. An evaluation job may require all three and should mark the group incomplete until the missing result is resolved. Neither policy should silently count a failed generation as an empty successful answer.

Candidate generation should not execute candidate actions. If an agent generates multiple proposed tool calls, retain them for selection or evaluation. Running every candidate's side effects could create duplicate tickets, messages or purchases. Keep sampling separate from the layer that is authorized to act.

Recalculate request pressure and cost

Sarvam's rate-limit documentation says limits apply across the account, so multiple API keys do not create separate capacity pools. A workflow that used one request for three choices now uses three requests for the same candidate count. It can hit a request limit sooner even if the number of user tasks stays unchanged.

As an illustrative capacity calculation, ten user tasks per minute with three candidates each require thirty generation requests per minute before retries. Reserve headroom for other workloads rather than setting concurrency from that average alone. Bursts, long requests and retry traffic still need controls.

Each separate request also carries the prompt again. Record input, cached-input and output usage from the actual responses instead of assuming the old request's bill simply divides into three equal parts. Use the same evaluation set before and after migration so that a change in candidate quality is not mistaken for a pricing improvement.

A small regression test prevents a recurring failure

Add a request-builder test that rejects chat n values above one and removes n from Responses payloads. Add an orchestration test where one candidate fails while the other two succeed, then confirm that only the failed candidate is retried. These tests can use mocked responses without spending API credits.

The lasting improvement is a candidate pipeline with explicit completion rules, bounded retries and a visible budget. That makes the application less dependent on a provider offering several samples behind one request.

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

I help technical founders turn API changes and developer workflows into clear, useful technical content.

Book a 30-minute call