Point opencode's provider block at litellm.home with a virtual key #29
Assignees
haylan (Arthur Erlich)
Clear assignees
haylan (Arthur Erlich)
No Assignees
Notifications
Due Date
No due date set.
Depends on
Reference: haylan/LLM-Server#29
Reference in New Issue
Block a user
Part of #26
Question
No local `opencode.json` currently has a `provider` block at all
(`~/.config/opencode/opencode.json` only configures the
codebase-memory-mcp MCP server). `docs/research/opencode-cli-setup.md`'s
example provider block points `baseURL` at `http://localhost:8080/v1`
(llama-server directly) — stale, since issue #15 closed llama-server's
direct LAN/host exposure; it must go through litellm
(`http://litellm.home`, per this session's own testing) instead, with a
per-workload virtual key per `docs/proxy-key-onboarding.md` (name it
`opencode`, same pattern as `openwebui`) rather than llama.cpp's
no-auth local endpoint.
This is a HITL task (needs a decision on where the config file lives —
project-local checked-in `opencode.json` vs. this machine's
`~/.config/opencode/opencode.json`, and a real virtual key minted against
the running litellm) — blocked on #28's decision for what
`limit.context`/`limit.output` values (and how they're kept in sync) go
into the block.
Resolution should record: which `opencode.json` was edited, the virtual
key's name/where it's stored, the model id used
(litellm's `qwen3.8-27b-local`, not llama.cpp's raw name), and confirmation
that `opencode` can actually complete a request against
`llamacpp/qwen3.8-27b-local` end to end.
Done: provider block added to ~/.config/opencode/opencode.json (baseURL http://litellm.home/v1, model id qwen3.8-27b-local matching litellm's model_name, virtual key supplied directly by the user rather than minted via /key/generate — that endpoint is currently broken, see note below). Set as opencode's default model ("model": "litellm/qwen3.8-27b-local"). Smoke-tested end to end:
opencode run "reply with exactly: pong" --model litellm/qwen3.8-27b-localreturnedpong.Side finding, not fixed here: LITELLM_MASTER_KEY in .env doesn't start with 'sk-', which makes litellm reject it everywhere (/key/generate, /spend/logs, /v1/models, /health all 401 'LiteLLM Virtual Key expected... expected to start with sk-'). Blocks minting new virtual keys via the documented API flow in docs/proxy-key-onboarding.md until either the master key is regenerated with an sk- prefix (needs a litellm container restart on the server) or keys are minted by hand via the Admin UI. Worth its own issue if it keeps biting.