Is your feature request related to a problem? Please describe.
OpenFlowKit is a local-first diagramming studio that turns plain-English prompts, Mermaid, or pasted source code into architecture diagrams and flowcharts, generating them with AI across ten providers, including fully offline Ollama. The self-correcting Flowpilot loop — a model sees its own broken DSL and the parser error, then repairs it in one turn — makes AI diagramming feel production-ready, all without any server-side storage.
Because Flowpilot already treats AI as a bring-your-own-key choice behind one OpenAI-compatible surface, with OpenRouter and custom endpoints as first-class options, its users clearly value picking the provider that fits each task. Adding one more optional gateway would give those builders extra choice at the provider layer without touching the diagramming experience they rely on.
Describe the solution you'd like
I propose adding OrcaRouter as an optional provider in Flowpilot's provider list. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the expected integration point is the same one OpenRouter and the custom OpenAI-compatible endpoint option use today: a user selects OrcaRouter in the in-app settings, pastes a key that stays in the browser, and Flowpilot calls it through the existing request path. This is purely additive — no existing provider would be replaced or changed. I'm an engineer on the OrcaRouter team, and this describes the intended design rather than code that is already written or tested.
For OpenFlowKit users, three capabilities stand out:
- One endpoint, many models — chat, reasoning, and image models behind a single key, letting a user pick a stronger reasoning model for architecture questions and a cheaper one for quick flowchart drafts without juggling accounts.
- Automatic model routing and provider failover — if an upstream provider is overloaded, a request routes to an available model, which matters for the self-correction loop's repair follow-up.
- Usage tracking and budgets — per-integration visibility into token spend helps heavy Flowpilot users keep diagramming costs predictable.
OrcaRouter is already integrated by open-source projects such as RAGFlow, Dify, promptfoo, and NocoBase, so the integration patterns are established in this ecosystem.
Describe alternatives you've considered
OpenFlowKit already supports OpenRouter and arbitrary OpenAI-compatible endpoints, which cover much of the same ground; OrcaRouter would be an additional managed option rather than a necessary one, and whether it earns a place in the provider list is the maintainers' call.
Additional context
OrcaRouter runs an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for the integration, and we would gladly follow any disclosure or governance requirements OpenFlowKit has. More examples are listed at https://www.orcarouter.ai/built-with.
If this direction seems useful, I'd welcome maintainer feedback and, once approved, would be glad to submit an implementation PR for review.
Is your feature request related to a problem? Please describe.
OpenFlowKit is a local-first diagramming studio that turns plain-English prompts, Mermaid, or pasted source code into architecture diagrams and flowcharts, generating them with AI across ten providers, including fully offline Ollama. The self-correcting Flowpilot loop — a model sees its own broken DSL and the parser error, then repairs it in one turn — makes AI diagramming feel production-ready, all without any server-side storage.
Because Flowpilot already treats AI as a bring-your-own-key choice behind one OpenAI-compatible surface, with OpenRouter and custom endpoints as first-class options, its users clearly value picking the provider that fits each task. Adding one more optional gateway would give those builders extra choice at the provider layer without touching the diagramming experience they rely on.
Describe the solution you'd like
I propose adding OrcaRouter as an optional provider in Flowpilot's provider list. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the expected integration point is the same one OpenRouter and the custom OpenAI-compatible endpoint option use today: a user selects OrcaRouter in the in-app settings, pastes a key that stays in the browser, and Flowpilot calls it through the existing request path. This is purely additive — no existing provider would be replaced or changed. I'm an engineer on the OrcaRouter team, and this describes the intended design rather than code that is already written or tested.
For OpenFlowKit users, three capabilities stand out:
OrcaRouter is already integrated by open-source projects such as RAGFlow, Dify, promptfoo, and NocoBase, so the integration patterns are established in this ecosystem.
Describe alternatives you've considered
OpenFlowKit already supports OpenRouter and arbitrary OpenAI-compatible endpoints, which cover much of the same ground; OrcaRouter would be an additional managed option rather than a necessary one, and whether it earns a place in the provider list is the maintainers' call.
Additional context
OrcaRouter runs an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for the integration, and we would gladly follow any disclosure or governance requirements OpenFlowKit has. More examples are listed at https://www.orcarouter.ai/built-with.
If this direction seems useful, I'd welcome maintainer feedback and, once approved, would be glad to submit an implementation PR for review.