Tell us about the problem you're trying to solve
ByteChef unifies AI agent orchestration and workflow automation in one platform, so an agent can be a step in a workflow and a workflow can become an agent tool, all under one audit log. Because an agent's quality depends on the models behind it, the per-environment AI Providers catalog and router-style LLM components such as OpenRouter show how deliberately ByteChef manages model credentials and model choice for teams that deploy across Development, Staging, and Production. That is why ByteChef users would benefit from one more well-integrated option.
OrcaRouter is proposed here as an optional, purely additive provider. It would not replace or alter any existing provider or connection, and it would follow the credential model ByteChef users already know: one API key per environment instead of one per model vendor.
Describe the solution you'd like
OrcaRouter is a model gateway that exposes an OpenAI-compatible API and uses standard API-key authentication, serving many chat, reasoning, image, and video models through one endpoint. For ByteChef agents and workflows, the most relevant capabilities are automatic model routing and provider failover (a step keeps running if an upstream provider is down), prompt caching for repeated agent and tool calls, and usage tracking with budgets for a single view of model spend.
The natural integration point mirrors what already exists: provider components under server/libs/modules/components/ai/llm/ (for example the OpenRouter module) reuse a shared RouterConnection.connectionDefinition(baseUrl) that wires a base URI plus BEARER_TOKEN API-key authorization. OrcaRouter's OpenAI-compatible surface should fit that pattern as a new component and/or AI Providers catalog entry. This is a proposal only: no code has been written or tested, and I would rely on ByteChef maintainers to confirm where a new provider belongs.
OrcaRouter already cooperates with open-source platforms such as RAGFlow, Dify, goose, and promptfoo, following an established pattern of gateway providers working with OSS tools.
Describe the alternative you've considered or used
Teams that want a multi-model gateway today configure OpenRouter manually or wait for the in-development EE AI Gateway. OrcaRouter would be an additional, optional choice that brings its own caching, budgets, and failover behavior into ByteChef's existing provider model.
Additional context
Transparency disclosure: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for this integration, and I am happy to follow ByteChef's governance and disclosure expectations either way. Other open-source integrations are listed at https://www.orcarouter.ai/built-with.
I'm an engineer on the OrcaRouter team. I would welcome maintainers' input on whether a provider component fits ByteChef's architecture, and with your go-ahead I would be glad to contribute the implementation as a PR following the component contribution guide.
Tell us about the problem you're trying to solve
ByteChef unifies AI agent orchestration and workflow automation in one platform, so an agent can be a step in a workflow and a workflow can become an agent tool, all under one audit log. Because an agent's quality depends on the models behind it, the per-environment AI Providers catalog and router-style LLM components such as OpenRouter show how deliberately ByteChef manages model credentials and model choice for teams that deploy across Development, Staging, and Production. That is why ByteChef users would benefit from one more well-integrated option.
OrcaRouter is proposed here as an optional, purely additive provider. It would not replace or alter any existing provider or connection, and it would follow the credential model ByteChef users already know: one API key per environment instead of one per model vendor.
Describe the solution you'd like
OrcaRouter is a model gateway that exposes an OpenAI-compatible API and uses standard API-key authentication, serving many chat, reasoning, image, and video models through one endpoint. For ByteChef agents and workflows, the most relevant capabilities are automatic model routing and provider failover (a step keeps running if an upstream provider is down), prompt caching for repeated agent and tool calls, and usage tracking with budgets for a single view of model spend.
The natural integration point mirrors what already exists: provider components under
server/libs/modules/components/ai/llm/(for example the OpenRouter module) reuse a sharedRouterConnection.connectionDefinition(baseUrl)that wires a base URI plusBEARER_TOKENAPI-key authorization. OrcaRouter's OpenAI-compatible surface should fit that pattern as a new component and/or AI Providers catalog entry. This is a proposal only: no code has been written or tested, and I would rely on ByteChef maintainers to confirm where a new provider belongs.OrcaRouter already cooperates with open-source platforms such as RAGFlow, Dify, goose, and promptfoo, following an established pattern of gateway providers working with OSS tools.
Describe the alternative you've considered or used
Teams that want a multi-model gateway today configure OpenRouter manually or wait for the in-development EE AI Gateway. OrcaRouter would be an additional, optional choice that brings its own caching, budgets, and failover behavior into ByteChef's existing provider model.
Additional context
Transparency disclosure: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for this integration, and I am happy to follow ByteChef's governance and disclosure expectations either way. Other open-source integrations are listed at https://www.orcarouter.ai/built-with.
I'm an engineer on the OrcaRouter team. I would welcome maintainers' input on whether a provider component fits ByteChef's architecture, and with your go-ahead I would be glad to contribute the implementation as a PR following the component contribution guide.