ChatGPTNextWeb / ChatGPTNextWeb/NextChat

Proposal: AnyLLM as a provider preset — one OpenAI-compatible endpoint for 24+ Chinese & international models

Open
#6,881 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.