Connection

The browser's cross-origin restriction (CORS) decides whether a web page may read the response of an API. Many relays and third-party APIs do not allow web pages to call them directly, so the requests have to go through a server. That server is the forwarding proxy. On a direct call, your API key passes through no third party. Through a proxy, your API key, the challenges, and the model's answers pass through that server on their way to the API.

The four connection modesCopy Anchor Link

"Connection" at the bottom of the API configuration has four options, with one sentence below the selected option that explains it. It is a browser-level setting. It applies to all profiles and is not written to exported configuration files.

The route is fixed when a run starts. Changing the connection mode during a run does not affect the requests in progress.

The check in Auto modeCopy Anchor Link

Auto checks once before each sampling or probing run. During the check, the main button shows "Checking connection…" and the configuration is locked. The check takes at most about 8 seconds; if the API does not respond, Auto treats it as not allowed and uses this site's proxy. The result is not kept, so the next run checks again.

The check does not use up quota. Its request carries a dummy API key (sk-cors-check) and an empty body {}, and the API rejects it before it runs any model, so no model runs and no tokens are billed.

The check does not leak your real API key either, because the real key appears only in the requests that follow. Neither the check request nor a direct request carries cookies or a Referer, and neither follows redirects, so a redirect cannot send the API key elsewhere.

If the check reads any HTTP status from the API, even a rejection, web pages can call it directly. If it cannot read one, the API may refuse web pages, or the address or network may be wrong. The browser cannot tell these apart, and Auto uses this site's proxy in both cases.

flowchart TD
    A["Start sampling or probing"] --> B{"Connection"}
    B -->|Direct| C["Direct call, no proxy"]
    B -->|This site's proxy| D["Forward through this site's proxy"]
    B -->|Own Worker| E{"Valid Worker address?"}
    E -->|Yes| F["Forward through your Worker"]
    E -->|No| G["No request is sent; the page asks for the address"]
    B -->|Auto| H["Check whether the API allows direct calls from web pages"]
    H -->|Allowed| C
    H -->|Refused or unreachable| D

When a direct call failsCopy Anchor Link

When a direct request fails at the network level, the page names both possible causes: the API address or the network is wrong, or the API does not allow cross-origin calls from web pages (CORS). The browser cannot tell which one it is. Check the address and your network first; if they are fine, switch the connection to "This site's proxy" or "Own Worker". A failed direct request is not switched to a proxy automatically.

This site's proxy and your own WorkerCopy Anchor Link

"Check proxy" sends one GET health check to the Worker address you entered, without the API key. The result applies only to that address:

What the browser storesCopy Anchor Link

The connection mode and the Worker address are stored in the browser, and so are the API configuration and the API key. None of this is uploaded to this site. Your API key leaves the browser only when a request is sent, to the API or to a forwarding proxy, as the selected connection mode decides. Clearing this site's browser data removes all of it, and the connection mode returns to Auto.