Every render in your Vault has a seed recorded next to it. Here is what that number is for, why the same seed will not always give you the same image, and how to get as close as the models allow.
Teo Brandao
Infrastructure
A seed looks like a promise: same seed, same prompt, same image. On a model you run yourself, it often is. On ockeeper it is something more modest, and we would rather say exactly what.
We do not train or host the models that make your images. Every render is a call to a third-party model through OpenRouter, on hardware we never see. Whether the same inputs come back pixel for pixel is up to that model and its provider, not to us.
Reproducibility is what turns a generator into a tool. It is how you test a single word in a prompt, and how you come back months later to a shot a client suddenly wants.
So we keep the full record of every render, even where we cannot guarantee the replay. Without it, every render is a one-off, and your Vault is a museum rather than a working archive.
On a model you do not run, a seed is closer to a receipt than a promise. We keep the receipt.
— engineering note
Every turn in a thread keeps the recipe that made it:
Prompt — Your words, and the full prompt that was sent, with the key's paragraphs in front.
Key — The character key that was attached, if any.
Model — Which of the four image models rendered it.
Settings — Aspect ratio and batch size.
Seed — A seed number, stored with the render and shown on its page.
Even with every input identical, a third-party model can return a different image. Providers update model versions and run requests on hardware we cannot see or choose. The seed is part of our record of the render; it does not control the third-party model, and sending the same inputs again can give you a close sibling rather than a copy.
None of that is something we can pin from our side, so we do not claim to.
Use Continue from this on the render you like. The next turn starts from that render with the same key and the same model, and the thread keeps the link between the two, so a series grows from the frame you chose.
Let the key do the heavy lifting. A precise subject paragraph and a short, measurable prompt narrow what a model can return far more than any seed number does.
And when a render is right, keep it. Everything that renders successfully is already in your Vault; the image itself is the only guaranteed copy.
4 — image models, all third-party
1 — recipe kept with every render
0 — models we train or host ourselves
We cannot promise that the same seed and prompt will reproduce an image, today or later. Providers can change or retire a model version, and that changes what the same inputs return.
What we can promise is the record: the prompt, key, model and seed behind every render stay with it in your Vault.
Seeds are shown on every render's page. If something you expected to reproduce does not, that is usually the model rather than your prompt — keep the image you liked, and continue from it.
FILED UNDER
Teo Brandao
Looks after the render pipeline at ockeeper. Writes about waiting times, seeds, watermarks and which parts of a render we control and which we do not.
We do not run the models that make your images — every render goes to a third-party model through OpenRouter. Here is an honest account of where the waiting comes from, the few levers that are actually ours, and the estimate we show before you press Generate.
3 min read
What we actually put on your images: a visible mark on the free plan, nothing on paid plans, and a commercial licence certificate number for every image. No invisible signal and no C2PA manifest — and why we would rather say so.
2 min read
Ten phrasings we see again and again that quietly wreck a composition, and the small edit that fixes each one.
3 min read