Before Using a Free Preview Model: Check Data Policies and an Exit Plan
The quick answer
Before sending code to a free preview model, check who can receive it and what happens when the preview ends. Zero token pricing can be useful for experiments.
Build your budget shortlistIn this guide
Before sending code to a free preview model, check who can receive it and what happens when the preview ends. Zero token pricing can be useful for experiments. It doesn't tell you whether the route is suitable for private work or a project with a deadline.
Our deals and free-offer directory can help you distinguish recorded promotions from ongoing plans; read the provider’s data terms separately before using either.
An anonymous model and a limited-time promotion raise different questions. With the first, you may not know which provider is handling the request. With the second, access may end just as you begin depending on it. Check both before making the preview part of your regular workflow.
Map the services receiving the request
Begin with the application where you type. It may store conversation history, collect diagnostics, or attach files. Then identify OpenRouter, the inference provider, and any additional tools or plugins used by the request. Assess each relevant service rather than treating the model's price label as a privacy label.
OpenRouter describes its own prompt retention as opt-in, with separate controls for private input/output logging and use of inputs/outputs. It also retains request metadata. Those statements concern OpenRouter's handling; they do not replace the inference provider's policy. Official data-collection documentation.
Make a compact inventory before connecting a repository:
| Data or function | Question to answer |
|---|---|
| Prompt and attached files | Which services receive the content? |
| Conversation history | Where is it saved, and who can view it? |
| Provider processing | Does the policy permit training or retention? |
| Optional search or tools | Does another service receive a query or file? |
| Diagnostics | Could logs contain prompts, credentials, or outputs? |
If you cannot identify an unnecessary intermediary, remove it from the first experiment. Fewer configured services make the path easier to understand and troubleshoot.
Separate training from retention
“Not used for training” does not mean “never retained.” Ask both questions explicitly. OpenRouter's provider documentation explains that providers have their own policies and that its account settings distinguish paid-model and free-model training preferences. It also points readers to provider terms. Official provider-logging documentation.
Check what your account actually exposes before promising a policy to a teammate. OpenRouter's pricing comparison differentiates features by plan, including data-policy routing. The existence of a request parameter in documentation does not establish that every account can use every related control. Current OpenRouter plan comparison.
For a work project, translate the requirement into a concrete rule, such as “only public sample code may be submitted during this evaluation.” That is easier to enforce than an undefined instruction to be careful. Keep credentials, customer records, and production exports out of the sample.
Read stealth-model terms separately
OpenRouter's Stealth Program terms say anonymous models can be offered temporarily and can be removed without notice. A model's listing identifies whether its provider intends to use submitted content for training; if the listing discloses training use, the terms say submitted content is logged in full and retained by the provider for that training. Ordinary logging preferences should not be assumed to override these special terms. Official Stealth Program agreement, updated September 14, 2026.
Don't guess a provider's identity from writing style, benchmark rumors, or an online guess. An unidentified provider is an unresolved part of the assessment. If knowing the operator is a requirement for your project, use a route whose operator you can establish.
Read the actual listing again when you return to a preview after a break. Save the model ID, source link, and review date in your evaluation notes. This is evidence of what you checked, not a guarantee that the service cannot change.
Design a useful experiment with public material
Try a task whose inputs you are comfortable making available to the services involved: a public documentation excerpt, a synthetic test case, or a small open-source example you have permission to use. Avoid assuming that deleting a name from a production record makes the rest harmless.
Measure the behavior relevant to your purpose. For a coding preview, check whether the proposed patch passes tests. For extraction, verify required fields against a known answer. Keep the test and expected result independent of the provider so you can repeat it elsewhere.
Do not describe these results as a broad security audit or a global quality ranking. A limited evaluation can tell you whether a particular workflow deserves more investigation.
Have an exit before relying on the preview
Store the task state outside the model session: instructions, source files, accepted outputs, and verification results. Identify an alternative route you are willing to evaluate, but do not silently send content there before its policy and price are acceptable.
Use a preview for work you can safely move elsewhere: public examples, synthetic data or an experiment you can pause. For private code or a deadline, choose a route whose provider, terms and fallback you understand. The free price should make the experiment easier, not make an important decision for you.