feat(provider): add AnonRouter - #2328
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe change adds AnonRouter as a disabled OpenAI-compatible provider with API-key authentication, model discovery, default metadata, renderer icon support, and test coverage. ChangesAnonRouter provider integration
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Feature Suggested reviewers: Merge Risk: ⚪ Minimal · up to The AnonRouter provider integration and icon registration are consistent with their runtime and renderer contracts, with no established merge-blocking risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
zerob13
left a comment
There was a problem hiding this comment.
Review: Approve ✅
This PR adds AnonRouter as a disabled-by-default built-in OpenAI-compatible provider. It follows the exact same pattern as recent provider additions (cheaper-inference, RunInfra, Synthorai): a DEFAULT_PROVIDERS entry, an OPENAI_BASE + api-key registry definition, a monochrome icon wired into modelIconRegistry, and two test blocks mirroring the existing ones. 6 files, +118/−1. No over-engineering, no breaking changes, no scope creep.
Verified against the live AnonRouter API
The registry definition matches what AnonRouter's compatibility mode actually exposes:
| Capability (per docs.anonrouter.ai/compatibility) | PR config | OK? |
|---|---|---|
POST /v1/chat/completions (stream + non-stream) |
openai-completions + OPENAI_BASE |
✅ |
GET /v1/models (bearer call) |
modelSource: 'openai', checkStrategy: 'fetch-models' |
✅ |
POST /v1/embeddings supported |
embeddingStrategy: 'openai' (default) |
✅ — correct, unlike cheaper-inference/api-route which disable it |
Live endpoint checks: POST /v1/chat/completions returns 401 without a key (route exists); GET /v1/models returns 401 authentication_error with an ar_-prefixed key (route exists, auth-gated — an unauthenticated GET falls through to a generic 404, so don't be fooled when testing without a key). All four website URLs (official / api-keys / docs / models) return 200.
Validation run
vitest run test/main/provider/basicApiKeyProviders.test.ts test/main/provider/defaultProviders.test.ts→ 35/35 passpnpm run typecheck(node + web) → cleanoxfmt --checkon the 5 changed TS files → cleananonrouter.svg→ valid XML,fill="currentColor"only, correctly added tomonoIconUrls
Non-blocking notes
- README provider table not updated. Precedent is mixed — Synthorai and OrcaRouter are listed in the table, RunInfra and cheaper-inference are not. If the table is meant to track notable providers, consider adding AnonRouter to the three READMEs; if it's best-effort, ignore this.
- Inherent provider limitations worth knowing (no action needed in this PR): AnonRouter rejects array/multimodal message content and unknown fields (
n > 1,logprobs,logit_bias), so sending images to an AnonRouter model will fail with a 400 from their side. This is a server-side contract, not something the client wiring can fix. websites.modelspoints to the marketing pageanonrouter.ai/models; the browsable catalog with privacy labels lives atdocs.anonrouter.ai/models. Either is fine — just flagging the difference.
Detailed verification log
- Review basis: PR head
293bd6e2c, merge-base diff againstdev(6 files, +118/−1) - Registry parity:
anonrouterdefinition is...OPENAI_BASE, credentialStrategy: 'api-key'— identical shape tocheaper-inference/api-routeminus theembeddingStrategy: 'none'override, which is correct here because AnonRouter documentsPOST /v1/embeddingsas supported - Endpoint probes (2026-09-19):
GET https://anonrouter.ai/→ 200;/models→ 200;https://docs.anonrouter.ai/quickstart→ 200;https://anonrouter.ai/home/api-keys→ 200;GET api.anonrouter.ai/v1/models(no auth) → 404 catch-all, (withBearer ar_test) → 401authentication_error;POST api.anonrouter.ai/v1/chat/completions(no auth) → 401 - Compat-mode gating:
GET /v1/auth/capabilitiesrequires auth, so operator-levelcompat.enabledcould not be verified without a key; docs state new keys are compatibility-enabled by default, which this integration relies on (plain bearer, no ticket flow — DeepChat cannot do the ticket dance) anonrouteris not in the PublicProviderConf DB (checked local + remoteall.json), somodelSource: 'openai'is the right choice- Tests: the
basicApiKeyProvidersblock mirrors the RunInfra test (fetch mock, definition match, discovery assertions,check(), no generate-text); thedefaultProvidersblock mirrors the cheaper-inference one. Proportionate to existing coverage — no over-testing.
I maintain AnonRouter and added it as a disabled built-in provider following DeepChat’s existing OpenAI-compatible provider pattern.
What changed:
Users need an AnonRouter key with OpenAI-compatible access enabled. No AnonRouter-specific transport was added.
Checks:
Summary by CodeRabbit
New Features
Tests