How to Use Ollama with a GUI (and a Hosted Fallback)

Why Ollama needs a separate GUI

If you want to know how to use ollama with a gui, the first fact to accept is that the Ollama project is a server and a command-line tool. It pulls models and answers requests on a local port. The chat window is someone else's job, and there are several good ones.

That split is useful. Because Ollama exposes an OpenAI-style API on your own machine (by default on port 11434 under /v1), any front end that lets you set a custom OpenAI base URL can use it. The same property means you can point that front end somewhere else later. This article walks through the local setup first, then adds a hosted endpoint as a second connection.

Pick a front end

Three families of tools cover most people. Check each project's own documentation for current install steps, because they change often.

• Open WebUI. A self-hosted browser interface. It supports Ollama directly and also accepts any OpenAI-compatible connection. Usually installed with Docker or pip.
• Desktop clients. Native apps such as Chatbox or Msty let you add an Ollama server or an OpenAI-compatible provider through a settings screen. No server to run.
• Roleplay and writing front ends. SillyTavern lets you add an OpenAI-compatible endpoint, and similar tools exist for long-form fiction and companion characters for adults.

If you do not want a Docker container, a desktop client is the shortest path. If you want a shared interface for several people on one network, Open WebUI is the usual pick.

Step by step with Open WebUI

1. Install and start Ollama, then pull a model with the ollama pull command. Confirm it responds from the terminal before going further.
2. Start Open WebUI. With Docker the usual pattern is to publish a port and mount a volume for its data.
3. Open the web page, create the first local account (it becomes the admin), and look for the connections area in the admin settings.
4. Check that the Ollama URL points at the machine where Ollama runs. When both are on the same host this is normally the local address on port 11434. When Open WebUI runs inside a container, localhost means the container itself, which is the most common reason the model list stays empty.
5. Reload, choose a model from the drop-down, and send a message.

That is a complete local GUI. Nothing leaves your computer, and speed depends on your GPU or CPU.

Adding a hosted OpenAI-compatible connection

Now the fallback. Suppose the model you can run locally is too small for a long scene, or your GPU is busy rendering. You can add a second connection to the same GUI. For this you need an API key, which you can claim from the API key page after signing up with Google or with email and password. A one-time $0.50 trial credit is available with one click, needs no payment, and lasts 7 days.

In Open WebUI, add an OpenAI connection with these values:

• Base URL: https://api.ollamansfw.com/v1
• API key: your key, sent as Authorization: Bearer
• Model: uncensored

If you prefer environment variables when launching the container, Open WebUI documents OPENAI_API_BASE_URL and OPENAI_API_KEY for this purpose:

Copydocker run -d -p 3000:8080 \
  -e OPENAI_API_BASE_URL=https://api.ollamansfw.com/v1 \
  -e OPENAI_API_KEY=YOUR_KEY \
  -v open-webui:/app/backend/data \
  --name open-webui ghcr.io/open-webui/open-webui:main
# model to pick in the UI: uncensored

After a reload, uncensored should appear in the model drop-down next to your local models. The front end finds it through GET /v1/models. You can now switch between a local model and the hosted one inside the same conversation list.

Test the endpoint outside the GUI first

When a GUI shows a vague error, the quickest way to tell whether the problem is the key or the interface is a direct call. Here is a streaming request with curl:

Copycurl -N https://api.ollamansfw.com/v1/chat/completions \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "stream": true,
    "messages": [{"role": "user", "content": "Write two sentences about a lighthouse keeper."}]
  }'

You should see a series of data: lines ending with usage information. If that works, the key and the URL are fine and the problem sits in the front end. The troubleshooting page covers typical slips like a missing /v1 or a trailing space in the key.

The same client settings you use for local models mostly carry over. Temperature, top_p, stop sequences, seed and the penalties are passed through to the model.

Using the hosted endpoint from your own code

A GUI is one client. Scripts and small apps are another, and the hosted endpoint works with the standard OpenAI SDKs. Tool calling and JSON mode are supported, which matters if your GUI or agent uses them.

Copyfrom openai import OpenAI

client = OpenAI(base_url="https://api.ollamansfw.com/v1", api_key="YOUR_KEY")

resp = client.chat.completions.create(
    model="uncensored",
    response_format={"type": "json_object"},
    messages=[
        {"role": "system", "content": "Reply with a JSON object with keys title and summary."},
        {"role": "user", "content": "A short story about a lighthouse keeper."},
    ],
)
print(resp.choices[0].message.content)

In Node the pattern is identical:

Copyimport OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.ollamansfw.com/v1",
  apiKey: process.env.API_KEY,
});

const stream = await client.chat.completions.create({
  model: "uncensored",
  stream: true,
  messages: [{ role: "user", content: "Name three sailing knots." }],
});
for await (const part of stream) {
  process.stdout.write(part.choices[0]?.delta?.content ?? "");
}

The quickstart has more examples, including tool calls with tool_choice.

Common problems and fixes

Most failures in a GUI setup come from a short list of causes.

• Empty model list for the local connection. The front end cannot reach Ollama. Check the address, and remember that a containerized GUI does not see your host as localhost.
• 401 from the hosted endpoint. The key is missing or wrong. Paste it again without spaces, and make sure the GUI sends it as a bearer token.
• 404 on every request. The base URL probably lacks /v1, or has it twice.
• Replies stop or the UI hangs. Some front ends buffer streamed output through a proxy. Try the direct curl test above, and if it streams, check the proxy settings in front of your GUI.
• Slow local replies. The model is too large for your VRAM and is spilling to system memory. Pick a smaller quantization, or switch that chat to the hosted connection.

Keep one rule in mind for fiction and companion apps for adults: the hosted model answers without content refusals for lawful adult use, but sexual content involving minors is never allowed, and the service enforces that as a hard limit.

Limits and costs to know about in a GUI

Front ends can fire several requests at once, for example when they generate a chat title in the background while the main reply streams. A full key allows 8 concurrent requests and 300 requests per minute. A trial key allows 2 concurrent and 60 per minute. A streamed request holds its slot until the stream ends. If you exceed a limit you get HTTP 429 with the code rate_limited or concurrency, and on temporary overload a 429 with Retry-After: 5. Turning off background title generation in the GUI is a simple fix on a trial key.

Cost is per token: $0.15 per 1M input and $0.50 per 1M output. A chat turn with 2,000 tokens of history and a 500-token reply costs $0.0003 plus $0.00025, which is $0.00055. The response headers include X-Balance-USD, so you can watch your credit shrink. Details on top-ups are on the pricing page. This site is crypto only: USDT on TRC20 or USDC on Base, any whole amount from $20 to $500.

The context window is 100,000 tokens, so very long chats will cost more per turn as history grows, because the whole history is sent each time. Most GUIs have a setting to trim or summarize old messages.

More guides

• Ollama Software Alternatives: Hosted Uncensored API
• Ollamansfw API Pricing: Token Costs Explained
• Uncensored LLM API Guide