[Bug] Custom OpenAI-compatible endpoint ignored; always defaults to remote OpenAI or Ollama

[berylm1]

Describe the bug
Codeep does not respect the baseURL (or --api-url) setting when configured to use a local, custom OpenAI-compatible endpoint (e.g., vLLM, LiteLLM). Instead, it continues to route requests to OpenAI's default endpoint (api.openai.com) or defaults to Ollama, ignoring both the configuration file and command‑line overrides. This makes it impossible to use Codeep with self‑hosted or private LLMs.

Steps to reproduce

1. Start a local OpenAI‑compatible server (e.g., vLLM on http://100.88.112.5:8000/v1).
2. Create ~/.codeep/config.json with: {
   "provider": "openai",
   "apiKey": "any-long-dummy-key",
   "baseURL": "http://100.88.112.5:8000/v1",
   "model": "qwen3-coder-30b"
   }
3. Run codeep chat "Hello"
4. Observe that the request goes to https://api.openai.com (resulting in “invalid API key” or “model not found” errors) or the wizard appears.
5. Alternatively, run: codeep --provider openai --api-key "dummy" --api-url http://100.88.112.5:8000/v1 chat "Hello"

The same problem occurs – the --api-url flag is ignored.

Expected behavior
Codeep should send requests to the configured baseURL (or --api-url) using the specified model name, exactly as the underlying OpenAI client library would. A user should be able to point Codeep to any OpenAI‑compatible endpoint (local vLLM, LiteLLM, etc.) without having to use a commercial provider.

Actual behavior
Requests are still sent to https://api.openai.com/v1/chat/completions (observed via network monitoring or error messages like 401 - Incorrect API key provided).
The first‑run provider selection wizard appears repeatedly, even after a valid config file exists.
Setting the OPENAI_BASE_URL environment variable has no effect.
The command fails with errors such as:
API error: 401 - { ... } or the model name reverts to gpt-5.5 / gpt-3.5-turbo.

Screenshots / Terminal output
$ curl -X POST http://100.88.112.5:8000/v1/chat/completions
-H "Content-Type: application/json"
-d '{"model":"qwen3-coder-30b","messages":[{"role":"user","content":"Say hello"}]}'
{"id":"chatcmpl-...","model":"qwen3-coder-30b","choices":[{"message":{"content":"Hello!"}}]}

(vLLM works perfectly)

$ codeep --provider openai --api-key "dummy" --api-url http://100.88.112.5:8000/v1 chat "Hello"

Still shows provider selection wizard or tries to connect to OpenAI.

Environment
Codeep version: latest (installed via npm install -g codeep on 2026‑05‑19)
Node.js version: v20.x (or v22.x)
OS: Ubuntu 24.04 (Minisforum) / also tested on macOS 15
Terminal: bash / zsh
Provider: OpenAI (custom endpoint)

Additional context
The same endpoint works flawlessly with curl, OpenCode, and LiteLLM.
The issue appears to be that Codeep’s configuration parser ignores baseURL and --api-url, likely because the code initialises the OpenAI client with default values before reading user overrides.
Many other users have reported similar problems (e.g., open issue in OpenCode about custom provider options not being passed). This bug makes Codeep unusable for anyone running local or self‑hosted models.

[VladoIvankovic]

Fixed in v2.1.1 (live on npm and Homebrew now) — thanks for the detailed report.

What was going on

Codeep only honored a custom base URL for the Ollama provider; for every other provider (including openai) the endpoint was hardcoded to the official API, so a baseURL key in the config was silently ignored. A few details in the repro were also assumptions that don't match the CLI:

• Codeep is a TUI, not a flag-driven CLI — there's no chat subcommand and no --provider / --api-key / --api-url flags. Config lives in ~/.codeep/config.json and /settings. (That's why the wizard kept reappearing — the flags were ignored.)
• OPENAI_BASE_URL wasn't read.
• The openai provider validates the model against its built-in list, so qwen3-coder-30b fell back to the default gpt-5.5.

What v2.1.1 adds

1. A dedicated Custom (OpenAI-compatible) provider for vLLM / LiteLLM / LM Studio / text-generation-webui. For your setup:

   // ~/.codeep/config.json
   {
     "provider": "custom",
     "customBaseUrl": "http://100.88.112.5:8000/v1",
     "model": "qwen3-coder-30b"
   }

   No API key required (set one only if your server enforces it). Run /model to pick from whatever your server lists at /v1/models, or set it directly as above. You can also select Custom (OpenAI-compatible) from the welcome screen / /provider and set the URL in /settings → Custom Base URL.

2. The openai provider now honors OPENAI_BASE_URL (the OpenAI-SDK convention) — handy for proxies that serve gpt-* model names.

The endpoint is resolved the same way everywhere the agent runs — terminal UI, agent mode, /plan, and the Zed / VS Code (ACP) integrations.

Upgrade:

npm i -g codeep@latest    # or: brew upgrade codeep
codeep --version          # should report 2.1.1

Let me know if your vLLM endpoint works after upgrading and I'll close this out. Thanks again for flagging it — this opens Codeep up to self-hosted setups.

[berylm1]

Yes, it worked. Thank you for your help. I wanted to ask if you know how I can get codeep to get me to view an HTML file I created with it.

[VladoIvankovic]

Glad it's working now!

Codeep doesn't have a dedicated "preview" command — but since the agent can run shell commands, you can just ask it in plain English and it'll open the file for you. For example:

open index.html in my browser

Codeep runs the right command for your OS (open on macOS, xdg-open on Linux, start on Windows). That's all you need for a standalone HTML file.

One gotcha: if your HTML pulls in JS modules, fonts, or makes fetch() calls, browsers block those over the file:// protocol (CORS / module security), so the page may look broken. In that case serve it over HTTP and open the localhost URL:

# from the folder containing your HTML:
python3 -m http.server 8000      # then visit http://localhost:8000
# or, if you have Node installed:
npx serve

Tip: run the server in a separate terminal — it's a long-running process, whereas Codeep's command tool is built for commands that finish, so it'd time out on a server that never exits.

Hope that helps — happy to close this out unless there's anything else!

[berylm1]

Alright thank you for your help.

One last question, what if you were remotely accessing the server would it work the same way where I just have to prompt it to open up or use the python3 command you gave ?