How to Connect Ollama or LM Studio to BYOKchat

You can connect BYOKchat to Ollama or LM Studio through their OpenAI-compatible API endpoints. In BYOKchat, use the Custom OpenAI-compatible provider, enter the server’s base URL, choose or discover a model, and leave the API key empty when the local server does not require authentication.

For the common default local setups:

Ollama
Base URL:  http://localhost:11434/v1

LM Studio
Base URL:  http://localhost:1234/v1

Those addresses work only when BYOKchat and the model server are running on the same machine and the server is using its default port. A phone cannot use localhost to reach a server running on your Mac.

This guide focuses specifically on connecting local servers to BYOKchat. For a broader comparison of the two runtimes, read Ollama vs LM Studio for API Clients.

How the connection works

BYOKchat does not need a special model format to talk to Ollama or LM Studio. It talks to the HTTP API exposed by the local server.

┌─────────────────┐
│ BYOKchat        │
│ custom provider │
└────────┬────────┘
         │ OpenAI-compatible HTTP
         │ /v1/models
         │ /v1/chat/completions
         ▼
┌─────────────────┐
│ Ollama or       │
│ LM Studio       │
└────────┬────────┘
         │
         ▼
     local model

The model runs behind the server. BYOKchat is the client and conversation workspace.

Before you start

Make sure you have:

1. Ollama or LM Studio installed;
2. at least one model available locally;
3. the local API server running;
4. BYOKchat on a device that can reach that server;
5. browser CORS configured if you are using BYOKchat Web.

The final point is the one most likely to surprise web users.

Option A: connect Ollama

Ollama exposes its native API at http://localhost:11434/api by default, and it also provides OpenAI-compatible endpoints under /v1.

BYOKchat’s custom provider uses the OpenAI-compatible surface, so the base URL should normally be:

http://localhost:11434/v1

Ollama’s official OpenAI-compatibility documentation uses that same /v1 base path.

Official documentation:

• Ollama API introduction
• Ollama OpenAI compatibility

1. Confirm Ollama is running

Test the local service outside BYOKchat first.

For the native Ollama API:

curl http://localhost:11434/api/tags

Or test the OpenAI-compatible model listing if supported by your installed version:

curl http://localhost:11434/v1/models

If the server is not reachable from a terminal on the same machine, fix Ollama before debugging BYOKchat.

2. Make sure a model is installed

Use Ollama’s normal model commands. For example, after choosing an appropriate model from the current Ollama library:

ollama pull <model>

Then verify it appears in the local model list.

Do not copy a model name from an old tutorial without checking your current Ollama installation. Model names and tags evolve.

3. Add the provider in BYOKchat

Create a Custom OpenAI-compatible connection.

Use:

Name:      Local Ollama
Base URL:  http://localhost:11434/v1
API key:   <leave empty for unauthenticated local Ollama>
Model:     <your Ollama model ID>

The current BYOKchat OpenAI-compatible transport only adds an Authorization header when an API key is present, so an empty key is appropriate for a local server that intentionally requires no authentication.

Ollama’s official documentation says its default local API does not require authentication.

4. Test a short prompt

Start with text only:

Reply with exactly: local connection works

Do not begin troubleshooting with images, tools, reasoning, or a huge context. First prove that basic transport and streaming work.

Option B: connect LM Studio

LM Studio exposes OpenAI-compatible endpoints from its local server. Its current documentation uses port 1234 in examples.

The common BYOKchat base URL is:

http://localhost:1234/v1

Official documentation:

• LM Studio OpenAI Compatibility Endpoints
• LM Studio API overview

1. Start the LM Studio server

In current LM Studio versions, you can start the API server from the Developer interface or via the lms CLI where available.

LM Studio’s documentation also shows:

lms server start

The exact UI can change, so use the current Developer/server controls in your installed version.

2. Load or make a model available

LM Studio distinguishes downloaded models from models currently loaded/available for inference depending on configuration.

Before connecting BYOKchat, verify the server can list models:

curl http://localhost:1234/v1/models

LM Studio’s OpenAI-compatible /v1/models endpoint returns models visible to the server.

3. Add the provider in BYOKchat

Create another Custom OpenAI-compatible connection:

Name:      Local LM Studio
Base URL:  http://localhost:1234/v1
API key:   <empty unless you enabled LM Studio API-token auth>
Model:     <model identifier returned by the server>

Newer LM Studio releases can support authentication configuration in the native server stack. If you explicitly enabled an API token, enter the credential required by your server setup. Otherwise, do not invent a secret just because cloud APIs normally require one.

4. Test text generation

Again, begin with a minimal prompt. Once basic generation works, test more advanced capabilities one at a time.

Why use the OpenAI-compatible endpoint?

Ollama and LM Studio each have richer native APIs, but BYOKchat’s custom-provider path intentionally targets a common Chat Completions-style interface.

That gives one integration point for many servers:

Custom OpenAI-compatible
├── Ollama
├── LM Studio
├── llama.cpp-style servers
├── private gateways
└── other compatible runtimes

This keeps the provider layer small and avoids adding one brand-specific adapter when the shared protocol is sufficient.

Read What Is an OpenAI-Compatible API? and OpenAI-Compatible Does Not Mean OpenAI-Identical.

“OpenAI-compatible” does not guarantee every BYOKchat feature

Compatibility is not all-or-nothing.

A local server may support:

✓ /v1/chat/completions
✓ streaming text
✓ /v1/models

but maybe
?  image input
?  tool calling
?  reasoning fields
?  structured output
?  specific sampling parameters

Capabilities can also depend on the model, not only the server.

For example, a server can implement tool calling correctly while the model you loaded cannot reliably produce tool calls.

BYOKchat should therefore treat capability metadata as guidance and avoid assuming every custom endpoint behaves exactly like OpenAI.

Web users: CORS is part of the setup

If you use chat.byok.pro, the browser must be allowed to call your local server.

A server can be completely healthy and still fail in BYOKchat Web because the browser rejects the cross-origin response.

The request path is:

https://chat.byok.pro
        │
        │ browser CORS + network policy
        ▼
http://localhost:11434/v1
or
http://localhost:1234/v1

Potential blockers include:

• the local server’s allowed-origin configuration;
• preflight OPTIONS handling;
• mixed-content restrictions between HTTPS pages and HTTP endpoints;
• browser private-network protections;
• firewall rules;
• server binding;
• browser-specific security policy.

Read Why Some AI APIs Don’t Work in the Browser: CORS Explained before using a random public CORS proxy.

A public CORS proxy would put an unknown server in the middle of your local-AI traffic and is generally the wrong fix.

Native BYOKchat avoids browser CORS

The iOS and macOS apps do not make requests through browser JavaScript, so they do not face browser CORS enforcement.

That often makes custom/local provider connections easier in native clients.

You still need:

• a reachable address;
• the correct port;
• a server listening on the relevant interface;
• firewall permission;
• valid TLS if using HTTPS;
• authentication if the server requires it.

CORS disappearing does not make networking disappear.

See BYOK Web App vs Native App: What Changes?.

localhost only means “this device”

This is the most common local-AI networking mistake.

On your Mac:

localhost → your Mac

On your iPhone:

localhost → your iPhone

So this setup does not work from the phone:

iPhone BYOKchat
      │
      ▼
http://localhost:11434
      │
      └── looks for Ollama on the iPhone

To reach a server on the Mac, use a reachable LAN/private-network address and configure the server to listen beyond loopback when appropriate.

Conceptually:

Mac
192.168.1.50
├── Ollama :11434
└── LM Studio :1234

       ▲
       │ Wi-Fi / LAN
       │
iPhone BYOKchat

Then the base URL could look like:

http://192.168.1.50:11434/v1

or:

http://192.168.1.50:1234/v1

Do not blindly expose a local unauthenticated model server to every network interface just to make this work. Understand the network you are opening it to.

See How to Connect an iPhone to an AI Server on Your Mac and Why localhost Does Not Work From Your Phone.

Secure the server before exposing it beyond one machine

Ollama’s default local API does not require authentication on localhost. That is convenient when only local processes can reach it.

The risk changes if you bind it to a LAN interface:

loopback only
127.0.0.1
    → only this machine

LAN binding
0.0.0.0 / LAN address
    → other reachable devices may connect

If the endpoint can perform expensive inference, access private models, use tools, or expose other capabilities, network exposure matters.

Use appropriate combinations of:

• host firewall rules;
• trusted private network boundaries;
• server authentication where supported;
• TLS or a secure private network where appropriate;
• Tailscale/VPN-style private access for remote devices;
• least-privilege exposure.

Read How to Secure a Local OpenAI-Compatible Endpoint and How to Run a Private AI API Over Tailscale.

HTTP vs HTTPS on a local network

Local AI servers commonly start as plain HTTP endpoints.

That can be acceptable for loopback-only traffic because packets do not traverse the LAN:

app → 127.0.0.1 → local server

Once traffic crosses a network, the threat model changes:

phone → Wi-Fi/LAN → Mac server

Credentials, prompts, and model responses can traverse that network path. If the endpoint is unauthenticated and contains sensitive data, you should understand who can observe or connect to the network.

See HTTP vs HTTPS for Local AI Servers.

Model discovery vs manual model IDs

BYOKchat attempts model discovery for custom OpenAI-compatible providers, but manual model entry remains important.

Not every compatible server exposes /v1/models identically. Some return incomplete metadata. Some local setups expose models only when loaded.

A resilient setup strategy is:

Try live discovery
      │
      ├── works → choose returned model ID
      │
      └── fails → enter exact server model ID manually

Do not assume discovery failure means generation itself cannot work.

Read How AI Model Discovery APIs Work.

Ollama API key field: should it be blank or ollama?

Ollama’s OpenAI SDK examples sometimes pass a placeholder API key such as ollama because the OpenAI SDK expects an api_key value even when the local Ollama server ignores it.

BYOKchat does not have that SDK requirement in its direct transport. Its OpenAI-compatible request code can omit the Authorization header when the connection API-key field is empty.

So for ordinary unauthenticated local Ollama:

API key: leave empty

If your own gateway or local deployment requires bearer authentication, enter the real credential required by that endpoint.

This distinction prevents a dummy string from being mistaken for a security mechanism.

LM Studio API-token authentication

LM Studio’s current native v1 server supports authentication configuration with API tokens. Whether your OpenAI-compatible endpoint requires a token depends on how you configured the server.

If authentication is enabled:

BYOKchat custom provider
API key → your configured LM Studio/server token

If authentication is disabled on a trusted local-only endpoint, leave the key empty.

Always test the exact server configuration you are running rather than assuming defaults from a tutorial.

Tools, reasoning, and images: test them separately

After plain text works, add advanced features one at a time.

Images

The server, API compatibility layer, and loaded model all need to support the image format the client sends.

Tool calling

The server must map OpenAI-style tool definitions/calls correctly, and the selected model needs reliable tool-use behavior.

Reasoning

Reasoning fields are especially non-standard across local runtimes and model families. Do not assume an OpenAI-compatible endpoint reproduces OpenAI Responses reasoning semantics.

Structured output

Some servers support JSON schema or OpenAI-style response-format controls, but the exact compatibility surface varies.

This is why BYOKchat’s custom provider should be treated as a compatibility path, not a promise that every advanced provider feature exists.

Troubleshooting: a reliable order

When the connection fails, debug from the bottom of the stack upward.

1. Is the model server running?
2. Does curl work on the server machine?
3. Is the base URL correct and does it include /v1?
4. Does /v1/models work?
5. Is the model ID exact?
6. If remote, is the server listening on a reachable interface?
7. Does the firewall allow the connection?
8. On web, does CORS allow chat.byok.pro?
9. On web, is mixed/private-network policy blocking it?
10. Does a basic text generation work?
11. Only then test images/tools/reasoning.

This sequence prevents capability debugging from hiding a basic networking failure.

Which one should you use: Ollama or LM Studio?

For BYOKchat, both can work through the same custom provider surface.

Choose based on the local runtime experience you prefer rather than assuming one is inherently more compatible.

Broadly:

• Ollama is attractive for command-line and service-style workflows;
• LM Studio provides a strong desktop model-management and developer-server experience;
• both expose APIs suitable for OpenAI-compatible clients;
• both continue to evolve, so feature parity changes over time.

For a feature-by-feature API comparison, read Ollama vs LM Studio for API Clients.

A useful hybrid setup

You do not have to choose local or cloud AI.

A multi-provider workspace can keep both:

BYOKchat
├── Local Ollama
├── Local LM Studio
├── OpenAI
├── Anthropic
├── Gemini
└── OpenRouter

Then choose the model based on the task:

Sensitive/offline-ish local task → local model
Frontier reasoning               → cloud model
Fast cheap transformation        → whichever provider fits
Model experiment                 → switch provider/model

The conversation workspace does not have to belong to the inference runtime.

Read How to Use Multiple AI Providers in One Chat App.

Final setup examples

Ollama on the same Mac as BYOKchat

Provider:  Custom OpenAI-compatible
Name:      Ollama
Base URL:  http://localhost:11434/v1
API key:   [empty]
Model:     <installed Ollama model>

LM Studio on the same Mac

Provider:  Custom OpenAI-compatible
Name:      LM Studio
Base URL:  http://localhost:1234/v1
API key:   [empty unless auth enabled]
Model:     <LM Studio model identifier>

Local server on another trusted machine

Provider:  Custom OpenAI-compatible
Base URL:  http(s)://<reachable-private-address>:<port>/v1
API key:   <only if server requires it>
Model:     <server model identifier>

For remote-device setups, solve network exposure, authentication, and transport security before treating the connection as finished.

Bottom line

Ollama and LM Studio fit naturally into BYOKchat because both can expose OpenAI-compatible APIs. Use BYOKchat’s Custom OpenAI-compatible provider, point it at the correct /v1 base URL, choose the exact model ID, and keep authentication aligned with your server’s real configuration.

The biggest differences are platform/network related:

• native BYOKchat avoids browser CORS;
• BYOKchat Web requires a browser-compatible local endpoint;
• localhost works only on the machine actually running the server;
• LAN exposure changes the security model;
• “OpenAI-compatible” does not guarantee every advanced feature.

Get text generation working first. Then add files, tools, reasoning, and more complex local-AI workflows one capability at a time.

Further reading

• Ollama vs LM Studio for API Clients
• How Local AI Servers Expose OpenAI-Compatible APIs
• How to Connect Ollama to an AI Chat Client
• How to Connect LM Studio to an AI Chat Client
• Why Some AI APIs Don’t Work in the Browser: CORS Explained
• How to Debug Local AI Connection Failures
• How to Use Multiple AI Providers in One Chat App