Set the OpenAI-compatible endpoint from the settings panel #8

Merged
colcaroli merged 1 commits from feature/configurable-openai-base-url into main 2026-08-23 14:14:16 +00:00
Owner

Pointing OPENAI_BASE_URL at a local llama-server or Ollama sends every gpt-*
call there instead of to OpenAI, and litellm reports that as a bare
"Connection Error" — which reads like a network problem even though the host
can reach api.openai.com fine. Deploying a .env that still carries the local
endpoint reproduces it on the server, with nothing in the message naming the
culprit.

Add OPENAI_BASE_URL and OPENAI_API_BASE to the settings allowlist so the
endpoint can be corrected without editing .env and recreating the container.
Both are listed because litellm reads OPENAI_API_BASE while the OpenAI SDK
reads OPENAI_BASE_URL, so fixing one can leave the other in effect. Neither is
a secret, so the panel shows the current value.

No cache invalidation is needed alongside this: litellm keys its client cache
on the endpoint, so a changed value takes effect on the next call.

Document the trap where it will be read — a commented template in .env.example
and a note in the Lightsail deploy guide about carrying a local .env over.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Pointing OPENAI_BASE_URL at a local llama-server or Ollama sends every gpt-* call there instead of to OpenAI, and litellm reports that as a bare "Connection Error" — which reads like a network problem even though the host can reach api.openai.com fine. Deploying a .env that still carries the local endpoint reproduces it on the server, with nothing in the message naming the culprit. Add OPENAI_BASE_URL and OPENAI_API_BASE to the settings allowlist so the endpoint can be corrected without editing .env and recreating the container. Both are listed because litellm reads OPENAI_API_BASE while the OpenAI SDK reads OPENAI_BASE_URL, so fixing one can leave the other in effect. Neither is a secret, so the panel shows the current value. No cache invalidation is needed alongside this: litellm keys its client cache on the endpoint, so a changed value takes effect on the next call. Document the trap where it will be read — a commented template in .env.example and a note in the Lightsail deploy guide about carrying a local .env over. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
colcaroli added 1 commit 2026-08-23 14:14:13 +00:00
Pointing OPENAI_BASE_URL at a local llama-server or Ollama sends every gpt-*
call there instead of to OpenAI, and litellm reports that as a bare
"Connection Error" — which reads like a network problem even though the host
can reach api.openai.com fine. Deploying a .env that still carries the local
endpoint reproduces it on the server, with nothing in the message naming the
culprit.

Add OPENAI_BASE_URL and OPENAI_API_BASE to the settings allowlist so the
endpoint can be corrected without editing .env and recreating the container.
Both are listed because litellm reads OPENAI_API_BASE while the OpenAI SDK
reads OPENAI_BASE_URL, so fixing one can leave the other in effect. Neither is
a secret, so the panel shows the current value.

No cache invalidation is needed alongside this: litellm keys its client cache
on the endpoint, so a changed value takes effect on the next call.

Document the trap where it will be read — a commented template in .env.example
and a note in the Lightsail deploy guide about carrying a local .env over.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
colcaroli merged commit 3b30dab650 into main 2026-08-23 14:14:16 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: colcaroli/playchat#8