nextlevelbuilder / nextlevelbuilder/goclaw
Add custom provider_type for generic OpenAI-compatible endpoints
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 24
Description
Problem
Provider catalog currently hard-codes known vendors (Anthropic, OpenAI, DashScope, Claude CLI, ACP, Codex). Users running self-hosted or niche OpenAI-compatible gateways (vLLM, LM Studio, LiteLLM,
Ollama proxy, OpenRouter, Together, Groq, Fireworks, local inference) cannot register them without either (a) hijacking the openai type and mismatching defaults, or (b) shipping a new provider_type per
vendor. Neither scales.
Goal
Introduce a neutral custom provider_type that treats any endpoint as OpenAI chat-completions compatible, so ops teams can onboard new backends via config/UI without code changes.
Scope
In scope
- Backend: accept provider_type = "custom" in provider store + HTTP validation.
- Routing: resolve custom through the existing OpenAI-compatible adapter (HTTP + SSE).
- Model listing: expose /v1/models passthrough for custom endpoints.
- UI: add "Custom Provider" entry in provider dropdown with i18n (en/vi/zh).
- Tests: unit + integration contract coverage.
Out of scope
- Non-OpenAI wire formats (Cohere, Bedrock native, Vertex native).
- Per-custom-provider feature flags (vision, tool-use capability negotiation) — deferred.
- UI credential templates per vendor.
Acceptance Criteria
- Creating a provider with provider_type=custom, base_url, encrypted api_key persists and appears in list endpoint.
- Chat completion request routed to custom provider returns streamed SSE response identical in shape to openai type.
- Model listing endpoint returns models reported by the custom backend.
- UI dropdown shows "Custom Provider" in en/vi/zh; selecting it saves provider_type=custom.
- go test ./internal/http/... ./internal/store/... + go test -tags integration ./tests/contracts/http_api/... pass.
- cd ui/web && pnpm test passes.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the provider store and HTTP validation, then trace how the existing OpenAI-compatible adapter handles HTTP, SSE, and model listing. Review the provider dropdown and its en/vi/zh translations under ui/web. Done means custom providers persist and list correctly, route chat and model requests, appear in all three locales, and pass the specified Go integration and pnpm tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend, frontend, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100