Skip to main content
Prompts are versioned templates that separate prompt content from application code. Edit them in the dashboard, publish a version, and call them by slug from your app — no deploy needed.

Creating a prompt

  1. Go to Prompts → New Prompt (or use the /prompts/new route)
  2. Pick a model (provider/model format)
  3. Write your system prompt and user message template
  4. Define variables (placeholders like {{topic}} that get filled at runtime)
  5. Optionally configure: structured output schema, fallback chain, temperature, max tokens

Variables

Variables are {{double_braced}} placeholders in your prompt template. Define them in the prompt editor with a name, type, and description:
Types: string, number, boolean. Required variables must be passed at runtime — the gateway returns a 400 if any are missing. See Prompt Engineering for details on variables, partials, and fallback chains.

Running a prompt

Or with the SDK:
The promptId field tags the request for log correlation — the prompt’s template content is not used. To execute a prompt’s actual template with variable interpolation, use POST /v1/prompts/{slug}/run.

Versioning

Each edit creates a new draft. When you’re ready:
  1. Click Publish — creates a new version
  2. The published version is cached by the gateway (60s TTL)
  3. Existing API calls continue to use the previously published version until the cache expires
You can view and compare previous versions in the prompt’s Versions tab.

A/B testing

Enable A/B testing on a prompt to split traffic between the published version and a variant:
  1. Create a new version with your changes
  2. Enable A/B testing with a split ratio (e.g., 50/50)
  3. The gateway randomly picks which version to serve per request
  4. Compare results in the Eval tab

Evals and scenarios

Define test scenarios with expected inputs and assertions, then run evals to compare prompt versions. See the Eval tab inside each prompt for the full workflow.

Output schema

Attach a JSON schema to a prompt to enforce structured output. The gateway translates the schema to the provider’s native format automatically. Define the schema in the prompt editor using the visual schema builder or raw JSON.

Fallback chains

Configure fallback models per prompt. If the primary model returns a rate limit, provider error, timeout, or refusal, the gateway tries the next model in the chain:
Without a triggers array, the fallback fires on any error — useful as a last-resort catch-all. Provider enablement is a policy gate, not a fallback trigger: a prompt referencing a disabled provider returns 403 model_not_allowed so the misconfiguration gets fixed — the chain only responds to upstream failures. When a fallback fires, the request log records the full attempt trail (each model tried, why it failed, and its latency) in the expanded log detail. The editor validates your chain as you build it: unknown models, providers without a configured key, duplicates, entries equal to the primary model, and models that can’t produce the prompt’s output format are flagged inline. Use the model selector in the prompt runner’s Ready to test area to run the request against Main, any fallback entry, or a combination — results appear as tabs, one per model, and the primary is only called when Main is selected, so a broken chain entry shows up before it reaches production.
Prompt editor