Prompting each Syntic model

The techniques in this section work on every Syntic model. This page adds what to keep in mind for each model in the catalog, so the same feature can move between models without surprises. Always confirm with your own test set; a prompt tuned for one model is a starting point for another, not a guarantee.

What all models share

• One context window of 262,144 tokens for prompt and reply.
• Text in, text out, with tool calling.
• Sampling settings are fixed, so prompt wording carries all of the control.
• A short Syntic identity line precedes your system message.

Amara S1.2 (default)

General work: drafting, analysis, coding help and conversation. It is the model that answers when model is missing or unrecognised.

• A good default for a new feature. Build your test set on it first, then try lighter or specialised models against the same set.
• Handles long system messages with many rules well; still number the rules and give reasons for the important ones.
• For multi-step tool use (agents, support assistants with lookups) it is the usual starting point.

Amara Quick

Short, frequent exchanges where a fast answer and a low bill matter most.

• Keep each request to one narrow job: one label, a few extracted fields, a short reply.
• Give fixed output formats and two or three examples; it benefits more from a precise template than from long explanations.
• Use it for the cheap steps of a chain (screening, routing, query rewriting) and hand the hard step to a larger model. See Chain prompts.
• Keep max_tokens small to match the job.

Amara Deep

Problems that take several steps of reasoning to get right.

• Give it room: allow generous max_tokens, because working through a problem uses output tokens.
• Ask for the final result in a tagged section (<answer>) so code can find it after the working. See Ask for step-by-step reasoning.
• Reserve it for the requests that need it; route easy requests to Amara S1.2 or Amara Quick to keep latency and cost down.

Syntic Code and Syntic Code Fast

Software work: reading code, writing patches and running tool loops. Syntic Code Fast does the same work with faster turnaround at a higher price.

• Give file paths and line numbers; prefix file contents with line numbers so answers can cite them.
• Offer narrow tools (read a file, search, run tests) instead of pasting a repository into the prompt. See Build a coding assistant.
• State the language, framework and conventions (“TypeScript, React 18, tests with Vitest”).
• Ask for patches in unified diff format when your code applies them, and validate with git apply --check.

Switching models

When you move a feature to another model:

1. Run the full test set on both models and compare scores, cost from usage, and latency.
2. Look at the failures that are new on the target model; usually one or two instructions need to be more explicit.
3. Keep the model name in configuration and log x-syntic-model-downgraded, so a plan change cannot silently switch the model. See Models overview.

Related pages

• Choosing a model
• Deprecations: moving to a replacement
• Test your prompts