Solutions

Prompt management and versioning

Move your prompts out of string literals and into one place with full history, an audit trail, and one-click rollback — useful on day one, before you test anything.

Who this is for: Teams whose prompts live in string literals across the repo, where changing a comma means a redeploy and the version history is `git blame`.

What most teams do today — and where it stops working

A prompt starts as a constant in one file. Then there are four of them, in three services, two of which drifted apart during a hotfix nobody wrote down. The person who owns the words is not the person who owns the deploy, so every wording change is a pull request, a review, and a release.

When something regresses, the question is "what did the prompt say last Tuesday?" — and the honest answer is a `git log` on a file that has been reformatted twice since. Rolling back means a branch, a build, and a deploy, at exactly the moment you want none of those things.

How LLMJury does it

Every version kept, with a field-level diff

Each edit is a version: what changed, who changed it, when, and the justification they typed. You can read the whole history of one prompt on one screen instead of reconstructing it from commits.

Roll back without a deploy

Promote any earlier version and the SDK picks it up on its next config fetch. No branch, no build, no release — the fastest path back to known-good is a click.

Change the prompt without touching the repo

The engineer who owns the model call and the person who owns the words stop stepping on each other. The prompt is addressable at runtime by name, so wording changes stop being deploys.

Your in-code default always survives

The SDK takes a fallback prompt as an argument and uses it whenever it cannot reach us — a network problem, an outage, or a plan limit. An LLMJury failure degrades to the prompt you shipped, never to an error.

The version you edit is the variant you test

Versioning is not a separate product bolted alongside the experiments. When you promote a version into an experiment, that exact version is the arm the verdict is about — there is no step where the tested text and the shipped text can diverge.

What you would set up

1Create the prompt in LLMJuryPaste the text you already have. That becomes version 1 — nothing else changes yet.
2Replace the literal with a `get_prompt` callTwo lines on the request path, with your existing string passed as the in-code default so the behaviour is identical the moment you deploy it.
3Edit in LLMJury from then onEvery save is a version with an author, a timestamp, and a justification. Diff any two, roll back to any one.

from llmjury import Client

client = Client(experiments=["checkout-prompt"])

# The prompt now comes from LLMJury — and your old literal is the fallback,
# so the first deploy of this line changes nothing about what users see.
p = client.get_prompt("checkout-prompt", user_id,
                      default="You are a helpful assistant.")

response = llm.messages.create(
    model="claude-haiku-4-5",
    system=p.prompt,
    messages=[{"role": "user", "content": user_input}],
)

The whole path, in all three SDKs, is on the five-minute quickstart.

What this does not do

Prompts are fetched and cached by the SDK, not read on every call. A newly promoted version reaches your fleet on the next config fetch, not the same millisecond.
There is no approval workflow yet — any member of your organization with access can save a new version. The audit trail records who did, which is what makes it reviewable after the fact rather than gated before it.
Prompt text is stored as you send it. If your prompts embed customer data, that data reaches us; see the security page for what we do and do not keep.

Try it on the thing you are arguing about this week

Free plan, no credit card, and the sample experiment is already in your account so there is something to read before you have any data of your own.

Prefer to look first? The interactive demo is a real verdict with no sign-up.