What Direct Connection does

Direct Connection sends the model request from your browser straight to the AI service - Big-AGI's servers never see your request, your data, or your key. Turn it on wherever it is offered: one server less in the path, and sessions can run longer.

The two routes

By default the request goes browser -> Big-AGI fast edge servers -> the AI service. That default exists because of CORS, a browser security protocol. Most AI services do not accept requests straight from a web page, so the edge in the middle makes every service work. With Direct Connection on, your browser calls the service itself.

Route	The key in flight
Via server (default)	travels with each request to the edge, which writes it to no database, log or account
Direct Connection	never leaves the browser; the Big-AGI server does not see the request

Two lanes: the default route passes through the Big-AGI edge; Direct Connection goes from the browser straight to the AI service.

Where the key sits between requests, and what to do if it leaks, is Keep your key safe.

What moves to the browser

For each service you turn it on for: your chat turns, the background model calls it serves, its model list refresh, and reattaching to or deleting a run in progress. Your browser makes each of those calls, so our server has no request to observe. The server features keep their server path, feature by feature, in What leaves the browser. The setting and the executor are identical on Open, Free and Pro. What differs is what gets bypassed: our edge on hosted, your own deployment on your own instance.

Bandwidth and speed

Direct Connection downloads slightly more data. The Big-AGI edge re-encodes each streamed frame into a compact normalized form; the direct route takes the service's own wire format, scaffolding and all. The content is the same, frame for frame. In exchange the path is shorter: the AI service's closest server answers your browser directly.

Prerequisites

Both are checked per service, and the second is that service's decision:

Service	Eligible when
A cloud service	its key is stored in this browser
A service needing more than a key - an endpoint, or an access key and its secret	every field its setup requires is filled in this browser
A model runtime on your own machine	always: the app falls back to the local default host, and suggests turning it on when it detects one
A service that refuses cross-origin browser calls	never: the toggle does not appear

Services whose keys live in server environment variables stay on the server route (Keys and access control).

Four services are exceptions:

• Cerebras ships with Direct Connection on. Its API sits behind bot management that answers our server with a challenge page, while the browser passes cleanly. It is the one case where the browser route is more reliable.
• NVIDIA NIM is eligible only on a custom host; the default endpoint blocks cross-origin browser requests.
• AWS Bedrock shows the row once credentials are set, and the browser call still fails - the service sends no cross-origin headers. Leave it on the server route.
• Sakana is server-only, so the row never appears. A subscription key can be excluded from an eligible service too. Moonshot's coding-subscription keys route to an endpoint that rejects the browser preflight.

Browser access is the AI service's to grant: Anthropic's API requires an explicit opt-in header, which Big-AGI sends on this route.

Where the toggle is

The setting is per service: Models settings -> the service -> Advanced. Connect from browser is on; Via server (default) is off. The Models menu's All Services view carries Enable for all and Disable for all for every eligible service at once. The row appears only once that service meets the precondition above.

The toggle sits in each service's panel under Advanced, with the two options named above.

Related

• What leaves the browser
• Keep your key safe
• Models on your own machines
• Key and access errors