Migrating Chat Completion from Fireworks AI to Sarvam
Last updated: October 23, 2026
This guide covers moving Fireworks AI Chat Completions and Responses calls for open-weight
models to Sarvam’s /v2 API.
In short: change base_url, api_key, and model. Reasoning comes back in
reasoning_content on both platforms. Remove Fireworks-only fields such as
prompt_truncate_len and perf_metrics_in_response, because Sarvam returns 400 for
request fields it doesn’t support. Set max_tokens explicitly, and send the full history
on every Responses call.
Migration checklist
- Create an API key in the Sarvam dashboard.
- Change
base_urltohttps://api.sarvam.ai/v2andapi_keyto your Sarvam key. - Replace each model ID using the model ID table. Fast, US, and deployment IDs map to the same Sarvam ID.
- Use string values for
reasoning_effort(low,high,max, ornone) (Reasoning). - Remove Fireworks-only fields:
prompt_truncate_len,context_length_exceeded_behavior,perf_metrics_in_response, and others (list). - Set
max_tokensexplicitly: onlyglm5.3defaults to2048on Sarvam. - Trim long conversations yourself: Sarvam doesn’t truncate prompts.
- If you use the Responses API, follow Migrating the Responses API.
- Run your tests and watch for
400responses that name a field.
Quick start
Before (Fireworks)
After (Sarvam)
Reasoning
On Fireworks, a json_schema response format turns reasoning off. On Sarvam, reasoning
models keep reasoning when you use response_format, so leave room in max_tokens, or
turn thinking off on models that support it.
Fireworks-only fields to remove
Sarvam validates request fields and returns 400 invalid_request_error with
Unsupported parameter(s) for fields it doesn’t support, so leftover Fireworks options fail
loudly instead of being ignored.
Parameter concept map
Responses API
Fireworks stores responses and chains them with previous_response_id; Sarvam’s Responses API is stateless, so you send the history in input instead. For base URL and field changes, reasoning items, function tools, and server-side tools, see Migrating the Responses API from Fireworks.
What’s different by design
- No deployments to manage. Models that need an on-demand deployment on Fireworks, such as Gemma 4 31B and DeepSeek V4 Pro, are called by model ID on Sarvam.
- Strict request validation. Unsupported fields return
400with the field named, instead of being dropped silently.gemma4is less strict: it accepts some fields, such aspredictionandlogit_bias, and ignores them. - No silent truncation. Sarvam rejects a prompt that doesn’t fit, rather than cutting
old messages or lowering
max_tokensfor you. - Stateless Responses. Your app keeps the conversation history, as with Chat Completions.
Platform features without a direct equivalent
Full example
A wrapper with retries on 429 and 503, which Fireworks returns when it sheds load and
Sarvam returns when a model is overloaded:
Common mistakes
Keeping the accounts/fireworks/models/ prefix
accounts/fireworks/models/kimi-k3 returns 404 on Sarvam. Use kimi-k3. See the
model ID table.
Relying on the 2048-token max_tokens default
Fireworks caps output at 2048 tokens when max_tokens is omitted. On Sarvam only glm5.3 does, so
long answers can run much longer. Set max_tokens explicitly, leaving room for reasoning
tokens.
Expecting long prompts to be truncated
Sarvam returns an error instead of truncating. Trim the conversation before sending.
Chaining Responses calls with previous_response_id
Sarvam doesn’t store responses. Keep the history in your app and send it in input, as
in the Responses example.
Leaving Fireworks fields in extra_body
Fields like prompt_truncate_len and perf_metrics_in_response are often passed
through extra_body. Sarvam returns 400 with the field name; remove each one it names.
See also
- Migration overview: base URL, auth, and model IDs
- Chat Completion overview
- Responses API guide
- Open-Weight Models
- Errors & Troubleshooting