Prompt engineering is iterative, and the hard part is remembering what you changed and why. A single reworded sentence can swing an LLM’s output from useless to excellent — and then a later “improvement” quietly regresses it. The AI Prompt Version Tracker gives each prompt a version history with labels and notes, lets you compare any two versions side by side, and lets you star the one that actually worked, all stored locally in your browser.
How it works
You paste a prompt, give it a label (like “v3 — added role + examples”) and a note describing what changed, and save it. As you iterate, each save becomes a new entry in your history. Select any two entries to see them side by side with a quick summary of how many characters and words were added or removed, so you can gauge how much a version really changed. Star your best performer to pin it, and export the whole history as JSON for backup. Everything is read from and written to your browser’s localStorage — nothing leaves your machine.
Tips and examples
Treat the note field as a lab log: record not just what you changed but what the change did to the output (“v4 — added 2 few-shot examples; cut hallucinated dates”). When a version works, star it immediately — it is much harder to reconstruct later from memory. Use the side-by-side compare before discarding an old version, because a “worse” prompt sometimes contains a phrasing worth keeping. Export to JSON periodically as a backup, since clearing your browser’s site data will wipe the local history; the export is your only safety net.
Why prompt versioning matters more than it looks
A one-sentence change to a prompt can move a model’s output from consistently useful to consistently wrong, and without a record you have no way to reproduce the good version or understand what you changed. This is especially true when:
- You share prompts with a team. Someone “improves” a prompt that was already working, the new version underperforms, and nobody can reconstruct the original.
- A model is updated. Behaviour can shift on the same prompt across model versions. A dated version history lets you bisect the regression.
- You A/B test approaches. Running two structural variants of a prompt for the same task and noting which output you preferred is exactly the kind of signal a version history captures.
A concrete versioning workflow
For example, suppose you are refining a prompt that extracts action items from meeting transcripts. Start with a minimal zero-shot instruction (v1). If the model includes items that belong to other teams, add a constraint (“include only items assigned to a named person — v2”). If it still misses items buried in side conversations, add a few-shot example (v3). Star the best version and note “v3 — added example from 15-Jun meeting; catches embedded action items, no over-inclusion”. If the model is later updated and v3 regresses, the note tells you exactly what to probe.
The side-by-side diff is most useful between non-adjacent versions. Comparing v1 and v5 makes the structural evolution obvious in a way that reading v4 → v5 does not. That broad view often reveals that a change you made in v3 is doing more work than you thought, and that rolling forward to v5 would have been a mistake if v3 were lost.
Keeping the history clean
Star versions deliberately rather than habitually. A library of starred entries is no easier to navigate than one with none. Reserve the star for the version you would actually copy if you needed the prompt right now, and use labels to explain the rest.