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.
Questions people ask on this page
- Do I have to redeploy to change a prompt?
- No. Prompts are addressed at runtime by name, and the SDK polls the config every 60 seconds with an immediate refresh when an ingest ack reports a newer version. Save a new version and it is live on the next poll — no branch, no build, no release.
- What happens to my app if LLMJury is down?
- It serves the prompt you shipped. get_prompt takes an in-code default and returns it whenever the config is not cached, assignment fails, or the variant has no prompt. An LLMJury outage degrades to your own literal; it never becomes an error on your request path.
- Can I use prompt versioning without running experiments?
- Yes, and most teams start there. Versioning, the audit trail, side-by-side compare, and one-click rollback are all on the Free plan, and none of them require you to define an experiment. The point at which they become an experiment is when you add a second variant.
- Who can change a prompt, and is it recorded?
- Every save is a version carrying the editing account's email, a timestamp, a field-level diff, and the justification they typed. Privileged operations like key rotation and statistical method overrides require an organization admin, enforced server-side rather than hidden in the interface.
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.