Prompt Management

• Iterate without shipping code. Product or prompt engineers refine prompts in the dashboard; the app keeps calling the same slug.
• Safe rollouts & instant rollback. Every change is a new version. Publish when ready; if it misbehaves, roll back in one click.
• Test before you ship. Run a prompt version against a suite of test cases and see pass/fail before it ever reaches a user.
• One template, many environments. Point a @production label at a tested version while @staging points somewhere newer.

A prompt is a container; the real content lives in versions. Every save creates a new, immutable version — you never overwrite history. Versions move through three states:

A version bundles the messages and the model settings to run them with, so the prompt — not the app — owns how the model behaves.

Put {{variable_name}} placeholders anywhere in your messages; the caller supplies their values at request time. Declaring each variable lets the editor validate inputs and supply defaults.

To preview the filled-in messages without calling a model, post the variables to POST /v1/prompts/{slug}/render — useful for debugging a template.

A label is a movable pointer to a version — e.g. @production, @staging, @dev. Promote a tested version to production by moving the label, with no code change. When calling a prompt you choose which version with version_ref:

Run a prompt at POST /v1/prompts/{slug}/completions, authenticated like any inference call — a virtual key or a routing config. Pass the variable values (and optionally a version_ref); VectorAxis fills the template and runs it with the version’s model settings.

POST /v1/prompts/summariser-9a1b2c3d/completions
Authorization: Bearer vk-1a2b3c4d5e6f7a8b

{
  "variables": {
    "tone": "concise and professional",
    "document": "..."
  },
  "version_ref": "@production"     // optional; defaults to the published version
}

A test case pairs a set of variable values with an expected-output pattern. Run the whole suite against any version to catch regressions before publishing.

Run the suite at POST /v1/prompts/{slug}/test-cases/run. The result reports per-case pass/fail, the actual response, latency, tokens, and cost, plus an overall pass/fail count — shown in the dashboard so you can compare versions at a glance.

• Per-prompt analytics — total requests, cost, average and p95 latency, and cache-hit rate over a time window, broken down by version, so you can see whether a new version is cheaper, faster, or more cacheable. Every prompt completion is also tagged with prompt_slug and prompt_version in your request logs.
• Audit log — every create, publish, rollback, and label change is recorded with who did it and when, for a full change history.

Creating, editing, publishing, and rolling back prompts takes a workspace admin; workspace members can view, render, run test suites, and call prompts. The full breakdown is on the Access Control page.