Fast output
Some models can generate tokens noticeably faster when you ask for it, at a higher price per output token. Use it where a person is watching the text appear and seconds matter, such as an IDE assistant or a live support reply. Speed mode changes how quickly tokens are produced, not what the model says.
Request
{
"model": "Syntic Code",
"speed": "fast",
"messages": [{ "role": "user", "content": "Write a unit test for parse_invoice()." }]
}| Field | Values | Default |
|---|---|---|
speed | standard, fast | standard |
Today the same effect is available by choosing the Syntic Code Fast model by name. Once speed ships, Syntic Code Fast stays as an alias for Syntic Code with speed: "fast", so existing code keeps working.
Which models support it
GET /v1/models lists capabilities.fast_output: true for models that accept speed: "fast". Other models refuse the field with 400 unsupported_parameter rather than silently ignoring it.
Price
Fast output is billed at the model’s fast rate, shown as a separate row on Pricing. For Syntic Code that is the Syntic Code Fast row: 4.50 / 0.70 / 20.00 dollars per million input, cached and output tokens, against 2.50 / 0.25 / 12.50 at standard speed. Input and cached input are priced higher too, because the faster path uses dedicated capacity end to end.
Measuring the gain
Compare time to last token, not time to first token: first-token latency is dominated by prompt length and is similar in both modes. Log x-syntic-processing-ms and the stream’s end time for a sample of requests in each mode before deciding.
Combining with other options
| Option | With speed: "fast" |
|---|---|
service_tier: "priority" | Allowed; the commitment must cover the fast variant. |
service_tier: "flex" | Refused; the two goals conflict. |
| Batches | Ignored; batches always run at standard speed and batch price. |
| Prompt caching | Works; cached reads use the fast cached-input rate. |