Provider logging

MyIP OpenRouter sends requests to two kinds of backend: our own GPUs and external providers. How far your prompt travels, and who can see it, depends entirely on which one served the request.

Local GPU models never leave

google/gemma-4-26b-a4b and lgai/exaone-4.0-32b are inferred on GPU nodes we operate ourselves.

• Prompts and responses stay inside our network.
• Nothing is handed to a third party.
• We do not store the bodies either — see Data collection.

If your requirement is that prompts must not leave our infrastructure at all, use only these models. That is the strongest guarantee available.

{
  "model": "lgai/exaone-4.0-32b",
  "messages": [{ "role": "user", "content": "..." }]
}

The X-MyIP-Provider response header tells you, per request, who actually answered.

When a request goes to an external provider

Requesting a model we do not host locally routes the call to an external provider we have an account with. From that moment your prompt is also subject to that provider's data policy: whether they train on it, how long they retain it, and what they log varies by provider, and we cannot guarantee it on their behalf.

What we do and do not do:

• We do relay the request, and record which provider answered on the usage record and in the response headers.
• We do not keep a copy of the prompt body on our side.
• We cannot control what an external provider retains on their own servers.

Controlling where requests go

The provider object in the request body restricts the candidates. Full syntax is in Provider routing.

Allow only specific providers

{
  "model": "lgai/exaone-4.0-32b",
  "messages": [{ "role": "user", "content": "..." }],
  "provider": { "only": ["local-gpu"] }
}

If only leaves no candidates, the request does not quietly go somewhere else — it fails with 404 no_endpoints_found. That is the point: it fails rather than leaking to an unintended provider.

Exclude specific providers

{ "provider": { "ignore": ["some-provider"] } }

Disable fallbacks entirely

{ "provider": { "allow_fallbacks": false } }

Only the first candidate is tried; if it fails, nothing else is attempted.

An honest note about data-policy filters

We accept provider.data_collection and provider.zdr in the request body for compatibility with OpenAI-shaped clients. However, our model catalogue does not yet carry per-provider data-policy metadata, and the rule for unknown metadata is that the candidate passes the filter. So today these two options do not actually exclude anything.

{ "provider": { "data_collection": "deny" } }

We do not publish a table of third-party retention policies. Reproducing figures we have not verified would read as a guarantee. Check each provider's own terms directly.

Verifying where a request went

Response headers

X-MyIP-Model: lgai/exaone-4.0-32b
X-MyIP-Provider: MyIP Local GPU
X-MyIP-Generation-Id: gen-01J...

After the fact

curl -s "https://openrouter.myip.co.kr/api/v1/generation?id=$GEN_ID" \
  -H "Authorization: Bearer $MYIP_API_KEY" | jq '{model, provider_name, provider_responses}'

provider_responses lists the fallback candidates in the order they were tried, so a first candidate that failed before a second succeeded is visible there too.

Ahead of time, from the catalogue

curl -s "https://openrouter.myip.co.kr/api/v1/models/lgai/exaone-4.0-32b/endpoints" | jq '.data.endpoints[].provider_name'

What we forward to a provider

• The request body — messages and parameters, as given
• Our own account credentials — never your API key
• Our request identifier

The HTTP-Referer and X-Title headers you set stay on our usage records and are not forwarded upstream. Your account details, such as your email address, are never sent to a provider.

Related

• Data collection — what we keep on our side
• Provider routing — the full provider object
• Local-first routing — when a local candidate is preferred
• Privacy Policy