Prompts, variables and A/B

Why managed prompts

• Edit prompts without redeploying your app.
• Pin a label (production) and swap which version it points to in one click.
• Version history with diff + rollback.
• Inject runtime data from your DB/system via {{variables}}.
• Run experiments without writing routing code.

Call by slug

{
  "model": "gpt-4o-mini",
  "prompt": {
    "slug": "welcome-email",
    "label": "production",
    "variables": { "name": "Ada" }
  }
}

messages is omitted; the server renders it from the template. If you do send messages, your messages win over the rendered ones — handy for appending the live user turn while still inheriting the system prompt from the registry.

Template syntax

Hello {{name}}, welcome to {{product}}.

Using your own data

You fetch from your DB/system, then hand the result to odnoga as variables. See the full Supabase Edge Function recipe in Using your own data in prompts.

Quick shape:

const user     = await db.users.findUnique({ where: { id } });
const invoices = await db.invoices.findMany({ where: { userId: id }, take: 5 });

await ai.prompts.chat({
  slug: 'billing-assistant',
  label: 'production',
  variables: {
    tenant_name:     user.tenant.name,
    user_full_name:  user.full_name,
    plan:            user.plan,
    invoices_context: invoices.map(i => `- #${i.number}  $${i.amount}`).join('\n'),
  },
});

Versions, labels, ids

Lookup order: version_id > label > active A/B > production > latest version.

A/B experiments

In Prompts → Experiments, attach two or more versions of the same slug with a traffic share. odnoga picks a version per request and sticks the user to that version using a hash of x-airouter-end-user. Without an end-user id, stickiness degrades to per-request — fine for testing, bad for production.

Each request records the experiment and the bucket it fell into, and results aggregate in the experiment view.

Errors