Models overview

Every request to the Syntic API is answered by one model from the Syntic catalog. You choose it by name in the model field of POST /v1/chat/completions. This page lists the models, explains how the API settles on the model that actually answers, and points to the pages on price, limits and retirement.

The catalog

Prices only apply to requests paid from usage credits; requests inside your plan allowance carry no per-token charge. See Pricing.

Shared characteristics

max_tokens above a model’s maximum output is lowered to that maximum, not refused. When max_tokens is left out, no ceiling is sent and the model’s own default applies. GET /v1/models returns the same figure as max_output_tokens.

Model names are exact strings

Model names contain spaces and capital letters. Send them exactly as they appear in the table:

{ "model": "Amara Quick", "messages": [{ "role": "user", "content": "Hi" }] }

amara-quick, Amara quick and AmaraQuick are not recognized. An unrecognized name does not produce an error; see the next section.

How the answering model is chosen

Today the API never refuses a request because of the model name. Instead it walks through these checks:

Not live yet — on develop: the API stops guessing. A name that is not a catalog name is refused with 404 model_not_found, and a catalog model your plan does not include with 403 model_not_in_plan (with an upgrade_url); the x-syntic-model-downgraded header is retired. A missing model still uses the default. Names must be ids that GET /v1/models returns.

Plan requirements

Each model carries a minimum plan level. Plans map onto three levels:

An organization can use any model whose minimum level is at or below its own. Organizations with a contract or comped plan are checked against that plan.

Zero data retention

Organizations that run in zero-data-retention mode cannot use models that depend on standard upstream retention. Requests for such a model are rejected before anything is billed:

{
  "error": {
    "type": "invalid_request_error",
    "code": "model_unavailable",
    "message": "This model requires standard data retention and isn't available for your organization's zero-data-retention configuration. Choose a different model.",
    "param": null,
    "request_id": "req_6f1c2a9e0b7d4c3a8e5f1b2d"
  }
}

Pick another model from the catalog and resend.

Check which model answered

# -D - prints the response headers before the body.
curl -s -D - https://app.syntic.ai/v1/chat/completions \
  -H "Authorization: Bearer $SYNTIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "Amara Deep", "stream": false,
       "messages": [{"role": "user", "content": "Name one prime above 100."}]}' \
  | grep -i '^x-syntic'

import os
from openai import OpenAI
 
client = OpenAI(base_url="https://app.syntic.ai/v1", api_key=os.environ["SYNTIC_API_KEY"])
 
raw = client.chat.completions.with_raw_response.create(
    model="Amara Deep",
    stream=False,
    messages=[{"role": "user", "content": "Name one prime above 100."}],
)
fallback = raw.headers.get("x-syntic-model-downgraded")
if fallback:
    print(f"Plan does not include Amara Deep; {fallback} answered instead.")
print(raw.parse().choices[0].message.content)

import OpenAI from 'openai'
 
const client = new OpenAI({ baseURL: 'https://app.syntic.ai/v1', apiKey: process.env.SYNTIC_API_KEY })
 
const { data, response } = await client.chat.completions
  .create({
    model: 'Amara Deep',
    stream: false,
    messages: [{ role: 'user', content: 'Name one prime above 100.' }],
  })
  .withResponse()
 
const fallback = response.headers.get('x-syntic-model-downgraded')
if (fallback) console.warn(`Plan does not include Amara Deep; ${fallback} answered instead.`)
console.log(data.choices[0].message.content)

Do not rely on the model field inside the response body to identify the catalog model; use the header and the name you sent.

Listing models from code

There is no endpoint that lists models yet. Keep the model name in configuration (an environment variable or a settings file) so you can switch models without shipping new code, and check Release notes for catalog changes.

Related pages

• Choosing a model: a method for picking and re-evaluating a model.
• Pricing: per-token prices, plan allowances and worked examples.
• Limits: request rate, request size and usage windows.
• Deprecations: how models are retired and what to do about it.