Summary
I prepared a local prototype for first-class AgentRouter support in ForgeCode.
The idea is a single-token agent_router provider with official endpoint behavior:
- default OpenAI-compatible route:
https://agentrouter.org/v1/chat/completions
- model listing:
https://agentrouter.org/v1/models
- Claude model IDs automatically rerouted to Anthropic-compatible:
https://agentrouter.org/v1/messages
This gives a simple UX for users who want one provider entry for:
- Claude models
- GLM/Zhipu models
- DeepSeek models
- other OpenAI-compatible models exposed by AgentRouter
Why this is useful
AgentRouter publicly documents support for:
- Claude Code
- Codex
- Gemini CLI
- RooCode
- Kilocode
- Qwen Code
- Droid CLI
So there is a reasonable case for first-class ForgeCode support as well.
Current blocker
AgentRouter currently rejects ForgeCode/generic client requests with:
unauthorized client detected
I reproduced that against:
/v1/models
/v1/chat/completions
/v1/messages
However, with the same token, the official Claude Code client gets past client auth and reaches quota/model-entitlement errors instead.
That strongly suggests the blocker is on AgentRouter’s side:
- ForgeCode is not currently an allowed client
- official Claude Code is allowed
I opened an AgentRouter issue for that here:
Local groundwork
I already implemented and committed local groundwork:
- commit:
a5d418dff
- message:
feat(provider): add AgentRouter routing groundwork
The local patch includes:
ProviderId::AGENT_ROUTER
- provider config in
provider.json
- routing logic for Claude vs non-Claude AgentRouter models
- tests for provider config and routing behavior
Suggested upstream path
I think the best next step is:
- ask AgentRouter to officially support / whitelist ForgeCode
- once confirmed, open a PR with the existing groundwork cleaned up for upstream review
Notes
This is different from just using generic custom providers because the AgentRouter UX is better as first-class support:
- one login flow
- one token
- one provider entry
- built-in Claude vs OpenAI route handling
If maintainers are open to it, I can convert the local commit into a proper upstream PR once AgentRouter confirms support.
Co-Authored-By: ForgeCode noreply@forgecode.dev
Summary
I prepared a local prototype for first-class AgentRouter support in ForgeCode.
The idea is a single-token
agent_routerprovider with official endpoint behavior:https://agentrouter.org/v1/chat/completionshttps://agentrouter.org/v1/modelshttps://agentrouter.org/v1/messagesThis gives a simple UX for users who want one provider entry for:
Why this is useful
AgentRouter publicly documents support for:
So there is a reasonable case for first-class ForgeCode support as well.
Current blocker
AgentRouter currently rejects ForgeCode/generic client requests with:
unauthorized client detectedI reproduced that against:
/v1/models/v1/chat/completions/v1/messagesHowever, with the same token, the official Claude Code client gets past client auth and reaches quota/model-entitlement errors instead.
That strongly suggests the blocker is on AgentRouter’s side:
I opened an AgentRouter issue for that here:
Local groundwork
I already implemented and committed local groundwork:
a5d418dfffeat(provider): add AgentRouter routing groundworkThe local patch includes:
ProviderId::AGENT_ROUTERprovider.jsonSuggested upstream path
I think the best next step is:
Notes
This is different from just using generic custom providers because the AgentRouter UX is better as first-class support:
If maintainers are open to it, I can convert the local commit into a proper upstream PR once AgentRouter confirms support.
Co-Authored-By: ForgeCode noreply@forgecode.dev