Workflow Builder takes a hard position and makes it look easy: a drag-and-drop editor a team can embed in its React app in a minute, with workflows as plain JSON so execution stays the adopter's choice. The plugin-first architecture — ELK layout, PDF export or undo/redo added or dropped without breaking the host app — is what teams building B2B SaaS configuration tools and AI agent platforms need.
That separation is why the AI Studio stack is worth a look. The Hono backend and Temporal worker resolve their model through one provider constructor and one AI_MODEL variable, making the model a configuration choice, not something baked into node definitions. Letting teams on that stack point their AI nodes at OrcaRouter would widen the model menu without touching their editor.
Proposal
I'd like to propose OrcaRouter as an optional provider for Workflow Builder's reference stack. This is additive only — it would not replace, change, or deprioritize any existing provider, and the default AI_MODEL behavior and OpenRouter wiring would stay exactly as they are.
Capabilities that seem most relevant to the people who deploy this stack:
- Many chat and reasoning models behind one OpenAI-compatible endpoint, so a workflow author can pick a model per AI node without a second SDK or a second key format.
- Automatic model routing and provider failover, which matters for the long-running Temporal activities where a single upstream hiccup currently surfaces as a failed node in the UI log panel.
- Usage tracking and budgets, a natural fit given the worker already defaults to
mistralai/mistral-small-3.2-24b-instruct explicitly for cost reasons.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Based on the current code, the expected integration point is the provider constructor already used in apps/execution-worker/src/engines/temporal/worker.ts and apps/backend/src/routes/visualize.ts (@openrouter/ai-sdk-provider via the Vercel AI SDK), plus an ORCAROUTER_API_KEY / base-URL option alongside AI_MODEL. To be clear: nothing is implemented or tested yet — this is a proposal, and the shape of the seam is for the maintainers to decide.
OrcaRouter is already part of the open-source ecosystem, with integrations across projects such as Dify, RAGFlow, promptfoo and OpenCode.
I'm an engineer on the OrcaRouter team. For transparency: we run an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is optional and is not a prerequisite for the integration — I'm happy to follow whatever disclosure or governance rules this project prefers.
Details on existing integrations are at https://www.orcarouter.ai/built-with. Would the maintainers be open to an OrcaRouter provider option here? If so, I'd be glad to prepare an implementation PR after you've weighed in on the approach.
Workflow Builder takes a hard position and makes it look easy: a drag-and-drop editor a team can embed in its React app in a minute, with workflows as plain JSON so execution stays the adopter's choice. The plugin-first architecture — ELK layout, PDF export or undo/redo added or dropped without breaking the host app — is what teams building B2B SaaS configuration tools and AI agent platforms need.
That separation is why the AI Studio stack is worth a look. The Hono backend and Temporal worker resolve their model through one provider constructor and one
AI_MODELvariable, making the model a configuration choice, not something baked into node definitions. Letting teams on that stack point their AI nodes at OrcaRouter would widen the model menu without touching their editor.Proposal
I'd like to propose OrcaRouter as an optional provider for Workflow Builder's reference stack. This is additive only — it would not replace, change, or deprioritize any existing provider, and the default
AI_MODELbehavior and OpenRouter wiring would stay exactly as they are.Capabilities that seem most relevant to the people who deploy this stack:
mistralai/mistral-small-3.2-24b-instructexplicitly for cost reasons.OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Based on the current code, the expected integration point is the provider constructor already used in
apps/execution-worker/src/engines/temporal/worker.tsandapps/backend/src/routes/visualize.ts(@openrouter/ai-sdk-providervia the Vercel AI SDK), plus anORCAROUTER_API_KEY/ base-URL option alongsideAI_MODEL. To be clear: nothing is implemented or tested yet — this is a proposal, and the shape of the seam is for the maintainers to decide.OrcaRouter is already part of the open-source ecosystem, with integrations across projects such as Dify, RAGFlow, promptfoo and OpenCode.
I'm an engineer on the OrcaRouter team. For transparency: we run an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is optional and is not a prerequisite for the integration — I'm happy to follow whatever disclosure or governance rules this project prefers.
Details on existing integrations are at https://www.orcarouter.ai/built-with. Would the maintainers be open to an OrcaRouter provider option here? If so, I'd be glad to prepare an implementation PR after you've weighed in on the approach.