Safe vs Mock
The two key modes, and how a mock chooses the response it returns.
Every key is created as either a safe key or a mock key.
Comparison
| Safe | Mock | |
|---|---|---|
| Upstream request | Forwarded to the provider | Never sent |
| Credential used | Your encrypted provider key, decrypted inside the gateway | None |
| PV / UV quota | Consumed | Not consumed |
| Alerts and circuit breaker | Enforced | Not applicable |
| Response | The provider's own | Provider-shaped, generated by the gateway |
| Intended for | Production | Development and demos |
The mode is on the key, not in the URL
A base URL selects the platform. Whether a request is forwarded or answered locally is decided by the credential the request carries, so a mock key and a safe-key are used in exactly the same way.
The gateway only forwards for safe-keys, so a mock key cannot reach a provider.
A key only works on its own platform
The prefix selects the platform and the key has to match it. An OpenAI key
presented to /deepseek/… is refused rather than forwarded somewhere it does not
belong. See Errors for the exact body.
How a mock chooses a response
A mock never forwards, so it derives the response from the request:
| Platform | How the response is chosen |
|---|---|
| OpenAI, DeepSeek | From the path (/chat/completions → text, /images/generations → image), falling back to the key's media type |
| Claude | Always a /v1/messages response |
| fal.ai | From the key's media type; the prefix selects synchronous or queue |
| ByteDance Seedance | The Ark task flow, chosen from the path |
Playground sends a request in either mode and shows the raw response.