OrcaRouter provider support for the LangGraph ReAct Agent template

The LangGraph ReAct Agent template is a clear starting point for building a tool-calling agent in LangGraph Studio: the model reasons over the query, the ToolNode executes the chosen tool, and a conditional edge routes back to the model until a final answer is reached. Laying that Reasoning-and-Action loop out explicitly in src/react_agent/graph.py makes it easy to follow and to extend.

The model step is deliberately provider-agnostic — you select a model as a provider/model-name string, load_chat_model resolves it via LangChain's init_chat_model, and API keys live in .env (Anthropic, OpenAI, and Fireworks are already listed in .env.example). Because the whole agent depends on that single chat-model call, developers building on this template are exactly the users who benefit from having more model choices behind the same selector.

I'm an engineer on the OrcaRouter team, and I'd like to propose OrcaRouter as an optional provider for this template. It would not replace or change any existing provider; it would simply give users one more provider/model-name option, leaving the current defaults and setup untouched.

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. In the context of this template, the natural integration point is the existing model-loading path in src/react_agent/utils.py: an OpenAI-compatible connection (endpoint URL plus an API key, following the same .env pattern as the other provider keys) could be added so users select an OrcaRouter-routed model the same way they select models today. Nothing here is implemented or tested yet — this issue is to gauge interest and agree on an approach before any pull request.

For an agent that can call a model many times in one run, the capabilities that seem most relevant to template users are:

• Multiple chat and reasoning models behind one endpoint, so a user can switch or compare models without touching code.
• Automatic routing and provider failover, which keeps an agent run moving if one upstream model is down or rate-limited.
• Usage tracking and budgets, which help teams sharing a template keep cost visible.

OrcaRouter is already part of the open-source ecosystem — integrations exist with projects such as Dify, RAGFlow, and goose — and we maintain a built-with page. We also run an optional open-source partner program through which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration; joining that program is not a prerequisite for the integration, and I would be glad to follow any disclosure or governance requirements you have.

If this sounds useful for people building agents from this template, I'd welcome your thoughts on where the option should live, and I'm happy to submit an implementation PR once the direction is approved.

Start with src/react_agent/utils.py and trace load_chat_model, then review src/react_agent/graph.py and the provider keys shown in .env.example. Confirm the maintainers' preferred approach for an optional OrcaRouter-compatible connection before implementation. Done means the agreed provider can be selected through the existing model path without changing current defaults, with tests covering the integration.