Prompt Iteration Tracker

Track prompt iterations and parameter changes with notes and ratings

Local browser tool for systematic prompt iteration. Log each attempt with prompt text, model, settings, seed, a 1-5 rating, and notes, then export your full iteration history as CSV or JSON for comparison. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Where is my iteration data stored?

Everything is saved in your browser's localStorage, so your log survives page reloads and stays on your device. Nothing is uploaded to a server.

Prompt iteration tracker

Good prompt engineering is empirical: you change one variable, regenerate, and compare. Without a log it is almost impossible to remember which model, seed, or temperature produced your best output three attempts ago. This tracker gives you a structured place to record every attempt so iteration becomes a measurable process instead of guesswork.

How it works

Each time you generate something, fill in the prompt text, the model you used, any settings (temperature, steps, CFG, etc.), the seed, a 1-5 rating of the result, and free-form notes. The attempt is appended to a table with a timestamp and saved to your browser’s localStorage, so the history persists between sessions. Because the data lives only on your device, you can log sensitive or proprietary prompts without anything leaving the browser.

Why systematic logging beats memory

Most prompt engineers work from mental notes. The problem is that small variable changes blend together after five or six iterations, and the best result from attempt three becomes invisible by attempt ten. Systematic logging addresses three specific failure modes:

The “what did I change?” problem. Without a log, you know the latest prompt text but not the delta that made it better than the previous version. A row-by-row log makes every delta visible.

The false plateau problem. It is common to hit a run of mediocre outputs and conclude the prompt is stuck, when in fact attempt four was a 4/5 result that got buried under later experiments. A timestamp and rating column lets you resurface it.

The reproducibility problem. Image models are particularly sensitive to seed: two otherwise identical runs produce completely different outputs. Logging the seed means a 5/5 result can be reproduced exactly, not lost to the stochastic process.

What to log beyond the obvious

The prompt and the model are the obvious entries. The high-value fields that most people skip:

  • Temperature (or CFG scale for image models) — the same prompt at 0.2 and 0.9 can produce near-opposite characters. This is the most commonly forgotten variable.
  • Seed — for image generation this is essential; for text generation it allows exact reproduction of a result when the model supports fixed seeds.
  • The change note — a one-line “what did I try this time” is more useful than the rating when you return to the log later. “Added role constraint” or “shortened to one sentence” is searchable; “4/5” is not.
  • The failure reason — for low-rated attempts, noting why it failed (“hallucinated a citation”, “ignored the length constraint”) builds a personal taxonomy of what breaks for this particular task.

Tips for effective iteration

  • Change one variable at a time. If you alter the prompt and the temperature together, you cannot tell which one moved the output. The log only helps if each row isolates a single change.
  • Always record the seed. A fixed seed makes a result reproducible; logging it lets you return to a near-miss and tweak just the prompt.
  • Rate honestly and consistently. A 1-5 scale only works if a “4” means the same thing across the session. Sort by rating to find your front runners before the next iteration.
  • Export before clearing. CSV opens in any spreadsheet for side-by-side comparison; JSON is better if you want to feed the history into another tool or share it with a collaborator.
  • Treat the log as a dataset. After ten or twenty iterations on a hard problem, patterns emerge: certain instruction structures consistently score higher, certain models handle the task differently. The log is your evidence base.