ChatGPTNextWeb / ChatGPTNextWeb/NextChat
Proposal: AnyLLM as a provider preset — one OpenAI-compatible endpoint for 24+ Chinese & international models
- Dominant language
- TypeScript
- Stars
- 88.8k
- Forks
- 59.1k
- PR merge metrics
- No merged PRs in 30d
Description
Hi NextChat team 👋
NextChat remains the go-to self-hosted chat UI, and its custom-endpoint support is a big reason why — a huge share of the community runs NextChat with BASE_URL pointed at DeepSeek, SiliconFlow, or an OpenAI-compatible gateway (there are dozens of tutorials for exactly this pattern).
That said, the custom-endpoint path today is a hand-typed three-field exercise:
Endpoint / BASE_URL — users must know the exact endpoint format (and on older frontends, protocol sniffing mis-detects non-OpenAI providers, which is why guides tell people to also set OPENAI_BASE_URL)
API Key — a separate key per upstream
Custom model names — model IDs typed by hand, comma-separated, no validation, and stale the moment the upstream ships a new model
I'd like to help fix all three at once by contributing an AnyLLM provider preset. AnyLLM is a unified OpenAI-compatible API gateway — one API key, one Base URL, 24+ leading models from both sides of the firewall:
Chinese: DeepSeek V4 Flash/Pro, Qwen3.7-Plus, GLM-5.2/5.1 (up to 2M context), Kimi K2.5/K2.6, MiniMax M3/M2.7, Xiaomi MiMo v2.5 Pro/v2 Pro
International: GPT-5.6 Luna, GPT-5.4 Mini/Nano, Gemini 3.5 Flash (multimodal)
Pass-through pricing, no markup; international cards and crypto accepted — so NextChat users outside China can finally reach DeepSeek / Qwen / GLM / Kimi without a Chinese phone number or Alipay, and don't need separate OpenAI / Google accounts either.
What I'd contribute (all low-maintenance by design):
A built-in provider preset (same pattern as the existing provider dropdown): default Base URL pre-filled, so users only paste an API key — no more hand-typed endpoints or protocol-sniffing workarounds
A maintained default model list for the preset, kept in sync as the gateway adds models (I maintain it; it's just a comma-separated string update)
A docs/README recipe for the zero-code path that works today: set the endpoint to the AnyLLM URL, paste the key, done — useful even if the preset isn't merged
Optional enhancement (happy to discuss separately): the custom-model field could optionally fetch GET /v1/models when a custom endpoint is configured, turning the hand-typed list into a picker. The gateway side returns a standard OpenAI model list, so this would work for any OpenAI-compatible upstream, not just AnyLLM — it directly addresses the most common misconfiguration reports ("model name 404 after typo").
Before opening a PR, a few questions:
Would a provider preset be a welcome addition, given the project's current maintenance cadence? I'll keep the diff minimal — a preset entry plus a docs section, no core logic changes.
Model list handling — for existing setups, would you prefer the preset's model list shipped in code, or fetched at runtime from /v1/models (cached, with the hand-typed field as fallback)?
Any branding/contribution guidelines for provider presets I should follow — anything beyond CONTRIBUTING.md?
I'll provide free API credits for any maintainer who wants to test the integration, and maintain the preset long-term.
More about AnyLLM: [URL]
Thanks for keeping NextChat alive — it's still the first thing I recommend to anyone who wants a private ChatGPT.
— Leo Bennett [leo.indiedev@gmail.com](mailto:leo.indiedev@gmail.com)
Contributor guide
No contributing guide indexed for this repository
Research direction
No implementation files or tests are named. Start by locating the existing provider dropdown and reading CONTRIBUTING.md; confirm the preset conventions and maintainer answers before choosing a scope. Done would be an agreed AnyLLM preset with its default endpoint and model list, plus the requested documentation recipe, while treating runtime model fetching as a separate enhancement.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- nextjs, react, typescript
- Domain
- api, documentation, frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100