To test an OpenAI-compatible chat client with a local Ollama model, set its base URL to http://localhost:11434/v1/ and choose the exact installed model tag. Start with one short message and check that the client actually talks to your local server. Ollama supports a subset of the OpenAI API, so test the features your application needs before switching a real workflow.
Establish a working local server
Run Ollama on the same computer as the first test client. Choose an installed text model, verify its name with ollama list, and run an ordinary prompt. If you have not installed a model, our local AI setup guide covers the initial steps. Write down the exact model name and server address. This baseline is useful when a third-party app offers several providers or hides part of the network configuration behind a preference screen.
Keep the first test on loopback. A browser app, a native desktop program and a container can interpret localhost differently depending on where the request runs. A native app on the same host is often a convenient first check. Verify where your application executes before changing its connection settings. If you later need another computer to connect, follow your environment’s documented networking and access controls. There is no need to expose a local service publicly just to check the compatibility layer.
Set the base URL and model name
Open the client or SDK settings where you can specify a base URL. Use the Ollama compatibility path ending in /v1/. Do not enter the full chat completion route into a base URL field when the client appends that path itself. If the application has a separate model field, enter the exact local model tag. A model picker showing familiar cloud names does not establish which of those names are installed on your server.
Ollama’s OpenAI compatibility reference shows using an OpenAI SDK with a local base URL and an example placeholder key. Some clients require a nonempty value even when the local endpoint ignores it. Use a harmless placeholder in that case. Keep a real provider credential out of the local test configuration. A placeholder is a client setting, not an access-control mechanism. If the application silently falls back to a hosted provider, stop and confirm its routing before testing with private material.
Send one simple request and inspect the result
Use a plain user message such as asking for one example of a local backup. For a direct REST test, the chat completions endpoint is http://localhost:11434/v1/chat/completions. A body such as {"model":"YOUR_MODEL","messages":[{"role":"user","content":"Give one example of a local backup."}],"stream":false} makes the starting assumptions explicit. Substitute the installed name and use the JSON content type. Review the returned status and the response body together. Check whether the response includes the assistant message the client expects.
Compare the result with one request to Ollama’s native API if you need to identify the failing layer. Our Ollama Chat API guide covers /api/chat. The native and compatibility endpoints can use different response shapes. Code that expects a native message field will need to inspect the structure it receives from the compatibility endpoint. If the native test works but the compatible call fails, concentrate on the base path, request fields and model name before reinstalling Ollama.
Test optional features individually
Once a plain call works, enable streaming only if the application uses it. Confirm that partial output appears, the completed answer is retained, and an interruption does not produce a misleading success state. Next check any tools, response formatting or image input the application needs. Refer to Ollama’s compatibility table for supported endpoints and options. A client that can display ordinary chat may still depend on a feature outside the supported subset.
Keep one working nonstreaming request available so you can return to it. Add one field at a time when diagnosing problems. If your task requires a particular structure, test it with realistic input and validate the response in application code. Our structured JSON guide explains validating the output rather than relying on its appearance. When using images or tools, verify the model’s own capabilities separately from the route accepting the request. A successful connection does not make each model interchangeable.
Recognize common connection and model errors
A connection refusal points first to the server, host or port. Check that Ollama is running on the computer where the request arrives. A path error suggests the client may have omitted /v1/ or added part of the endpoint twice. A model error points to the exact tag the service sees. Confirm these values with a known-good local request. Avoid replacing the model while you are still diagnosing a malformed network path.
For a slow reply, compare a cold first request with a second request while the model is loaded. Keep the prompt short and check whether the problem is only in one client. A long conversation can introduce a separate context and memory problem. Our Ollama processor diagnostics guide shows how to inspect the loaded model and its reported CPU or GPU placement. Record the differences before changing several parameters at once.
Keep local and hosted configurations distinct
Use descriptive configuration names so you can tell which endpoint is active. Keep a known test prompt and expected behavior for each application. If you switch a project between local and hosted providers, confirm its destination before sending real data. Review logs and any intermediary that might retain requests. Running the model on loopback does not determine where the client saves its own history or whether other integrations send data elsewhere.
Before using the configuration for work, test one ordinary prompt, one obvious error and one case that uses any optional features you rely on. Then restart the client and verify the endpoint again. Write down the model tag, base URL, and settings you actually used so a later update does not force you to guess which configuration worked. Keep the instructions with the project, without embedding sensitive credentials in them.
If you use a settings file, keep the base address and model tag together for each profile. Review which profile is active at startup and whether an environment variable can replace the saved address. Restart with a harmless prompt and examine the client’s connection information or the local server log. A successful reply alone cannot establish which endpoint answered. Repeat the same check after changing the profile, especially if both configurations use similar model names or one is selected automatically.
Frequently asked questions
Does this use an OpenAI-hosted model?
The example sends the request to an Ollama server on localhost. Verify that your particular application honors the base URL and does not use a hosted fallback.
Can I use a regular OpenAI SDK?
Yes, if it supports overriding the base URL and your workflow uses the compatible features. Check the current Ollama documentation.
Why does the client require an API key?
Some clients require a value for initialization. The documented local example uses a placeholder. Keep real credentials in the configuration where they are needed.
