Choosing a model

The catalog is small on purpose, so the choice is mostly about three trade-offs: how hard the task is, how quickly the answer must arrive, and what each request may cost once you are paying from usage credits. This page gives you a repeatable way to decide, and to revisit the decision later.

Start from the task, not the model

Before comparing models, write down what a good result looks like for your feature:

Question	Why it matters
How many steps of reasoning does a correct answer need?	Single-step tasks (rewrite, classify, extract) rarely benefit from a heavier model.
Is someone waiting on screen for the answer?	Interactive features feel slow quickly; background jobs can wait.
How many requests a day, and how long are they?	Volume multiplies every cent of per-token price once the plan allowance is used.
Does the task involve source code or tool calls?	The Syntic Code models are tuned for that kind of work.
What does a wrong answer cost you?	Expensive mistakes justify a stronger model and a review step.

Quick recommendations

If your feature is mostly…	Start with	Consider instead
Chat, drafting, summarizing, general Q&A	`Amara S1.2`	`Amara Quick` if answers are short and volume is high
Labelling, routing, short extraction, autocomplete-style suggestions	`Amara Quick`	`Amara S1.2` if accuracy on your test set is too low
Planning, multi-step analysis, careful comparison of options	`Amara Deep`	`Amara S1.2` if the extra depth does not change outcomes
Code review, patch writing, agent-style tool loops over a repository	`Syntic Code`	`Syntic Code Fast` when wall-clock time matters more than price

A method that holds up

Collect 20 to 50 real inputs

Take them from production logs, support tickets or the documents your feature will actually see. Include a handful of awkward ones: very long, badly formatted, off-topic.

Decide how you will score the output

For classification, compare against a known label. For writing tasks, write a short checklist (correct facts, right length, right tone) and score each item yes or no. Write the scoring down before you look at any model output.

Run the cheapest plausible model first

Send every input to the lightest model that might work, usually Amara Quick or Amara S1.2. Keep the prompt identical across runs so only the model changes.

Move up only where it fails

If the score is good enough, stop. If not, look at the failures: are they caused by the prompt (fix the prompt first, see Prompting tips) or by the model genuinely missing steps? Only the second justifies a heavier model.

Record the decision

Note the model, the score, the date and the prompt version next to your configuration, so the next person can repeat the comparison.

A small comparison script:

import os
import requests
 
URL = "https://app.syntic.ai/v1/chat/completions"
HEADERS = {"Authorization": f"Bearer {os.environ['SYNTIC_API_KEY']}"}
 
SYSTEM = "Label the customer message as billing, bug, feature_request or other. Reply with the label only."
CASES = [
    ("I was charged twice for October.", "billing"),
    ("The export button does nothing in Safari.", "bug"),
    ("Could you add a dark theme to the mobile app?", "feature_request"),
    # ... add the rest of your test set here
]
 
def score(model):
    correct, tokens = 0, 0
    for text, expected in CASES:
        res = requests.post(URL, headers=HEADERS, timeout=60, json={
            "model": model,
            "stream": False,
            "max_tokens": 10,
            "messages": [{"role": "system", "content": SYSTEM}, {"role": "user", "content": text}],
        })
        res.raise_for_status()
        if res.headers.get("x-syntic-model-downgraded"):
            raise SystemExit(f"{model} is not in this plan; results would be for the default model.")
        body = res.json()
        correct += body["choices"][0]["message"]["content"].strip().lower() == expected
        tokens += body["usage"]["total_tokens"]
    return correct / len(CASES), tokens
 
for model in ("Amara Quick", "Amara S1.2"):
    accuracy, tokens = score(model)
    print(f"{model:12}  accuracy {accuracy:.0%}  tokens {tokens}")

The script stops if a model falls back to the default because of your plan. Without that check, two runs could quietly compare the default model against itself.

Combining models

Using more than one model in a single feature is often cheaper than using the strongest one everywhere:

Triage then answer. Amara Quick decides whether a message is simple; only complex ones go to Amara Deep.
Draft then check. Amara S1.2 writes a draft; a second short request asks a model to list factual problems in it.
Plan then act. In an agent loop, a stronger model writes the plan once, and a cheaper one carries out the routine steps.

Each request is billed separately, at the price of the model that answered it.

When to revisit the choice

A new model appears in Release notes.
A model you use is announced on Deprecations.
Your usage moves from plan allowance to usage credits (watch the x-syntic-billing-source header), which makes per-token price matter.
Your quality score drifts on fresh production samples.

Models overview: the catalog and fallback rules.
Pricing: what each model costs on usage credits.
Control costs: more ways to reduce spend.

Syntic Code Fast Pricing

Was this page helpful?