Bolt.diy with a Custom OpenAI-Compatible Endpoint

Bolt.diy runs a full development environment in the browser and asks a model to write the application. Pointing it at a gateway means setting two environment variables, but the variables alone will not put a provider in the model picker — and once it is there, the model list is not something you type.

OpenAI-Like sits under Local Providers and is disabled by default, so a perfectly correct .env.local looks like it did nothing. There is no model-id field: ids are discovered by requesting {base_url}/models and used exactly as returned. And every discovered model is assigned an 8000-token limit in the source, regardless of what your endpoint reports for its context length.

This page covers the two variables, the toggle they depend on, what the browser does to your endpoint's requirements, and what a month of app generation costs.

The two variables, and the toggle they need

# .env.local
OPENAI_LIKE_API_BASE_URL=https://gw.example.com/v1
OPENAI_LIKE_API_KEY=sk-your-gateway-key

Then open Settings, go to Providers, and switch OpenAI-Like on under Local Providers. It is off until you do.

The environment variables are read at server start, so changing .env.local requires restarting the dev server — saving the file is not enough, and nothing in the UI tells you the values are stale.

The ordering trips people up in a specific way: configure the variables, restart, and still see no OpenAI-Like models, then conclude the base URL is wrong and start editing it. The URL was fine; the toggle was off.

Model ids are discovered, not typed

There is no text box for a model id anywhere in the provider settings. Bolt.diy requests {base_url}/models with your key and builds the picker from the response, using the ids verbatim.

Two consequences follow. If your gateway does not expose /models, or returns something that is not a list the client can read, the picker stays empty and no amount of editing the base URL changes that. And if the ids your gateway reports differ from the ones its /chat/completions route accepts, you cannot correct them from the UI — you get to send whatever /models said.

There is an escape hatch: declaring models through OPENAI_LIKE_API_MODELS uses the limits you write there instead of the discovered ones, but the discovery step still has to produce something first.

The 8000-token limit is not your model's

Every model discovered from /models is assigned maxTokenAllowed: 8000 in the source. The context_length field your endpoint returns is never read, so a model with a million-token window still shows as roughly 8k in the picker.

This number feeds the picker label and a server-side warning log. Nothing in the streaming path clamps the request or truncates the chat — so treat it as a display artifact, not as a ceiling you are hitting. Seeing 8k next to a large model is expected, not a misconfiguration.

One related quirk, because it looks like a failure and is not: the health badge for local providers performs a browser-side request to {base_url}/models with no Authorization header at all. An endpoint that requires a key rejects it and the badge goes red, while generation keeps working fine. A red badge with working output means the badge, not the gateway.

The browser is the client, and that changes the requirements

Bolt.diy is the only tool in this matrix where the request originates in a browser tab rather than from your machine or your server. Two things follow.

Your endpoint has to answer cross-origin requests. The built-in example is LM Studio, whose documentation note is explicit: enable CORS. A gateway that only accepts same-origin or server-side calls will fail with a fetch error in the console rather than with an API error, because the request never gets as far as your key.

Use 127.0.0.1, not localhost. The shipped example file says so directly, citing IPv6 resolution issues. A local endpoint written as localhost is a plausible-looking source of "Failed to fetch".

Also worth noting if you copy from the example file: HYPERBOLIC_API_BASE_URL is a full URL including /chat/completions, while OPENAI_LIKE_API_BASE_URL is a base URL that must not include the operation path. Two variables, same file, opposite conventions.

What generating applications costs

Bolt.diy asks for a lot of output: it writes files, so a single prompt can produce thousands of tokens of code, and the default output allowance is 8000 tokens. Input is large too, because each turn carries the project state the model needs to keep editing consistently.

A day of work on this page's workload is 380k input and 50k output tokens — 7.6M input and 1M output across 20 working days. This is the heaviest profile in the tool matrix, and it is output-heavy enough that the output rate matters more here than in a chat session. See output vs input pricing for why that flips which model is cheapest.

One day = 380k input + 50k output on this page's workload. 20 days = 7.6M input and 1M output. Rates checked 2026-10-11 — gateway rates move with upstream promotions, so verify the current number in your dashboard before committing to a budget.

Verifying the route

1. Set both variables, then toggle OpenAI-Like on under Settings → Providers → Local Providers.
2. Restart the dev server. Environment changes are read at start.
3. Check {base_url}/models yourself with your key. If it returns nothing usable, the picker will be empty no matter what the base URL says.
4. Ignore the 8000 in the picker and ignore a red health badge that accompanies working generation.
5. For a local endpoint, use 127.0.0.1 and confirm CORS is enabled — a console fetch error is a browser rejection, not an API error.

FAQ

FAQ

Related

• Jan with a custom endpoint — desktop client, where the API format is a separate choice from the URL
• Cherry Studio with a custom provider — another GUI, with its own URL-appending rule
• OpenAI-compatible error codes — what a 401 or 404 from your gateway means
• Tools that take one endpoint — the full matrix

Get API access