Problem
Flatkey CLI gives media teams and AI agents one FLATKEY_API_KEY, one credit balance, and a single router for image, video, audio, and text generation. That design is aimed squarely at the workflow your Product Comparison calls out: repeated, agent-driven testing, where creator suites get expensive and peak-time queues stall iteration — your README notes Dreamina/Jimeng video calls can wait up to 5 hours. Making generation scriptable with --json, --dry-run, and a live flatkey models registry is what lets a pipeline own the work instead of a person babysitting it.
Because model selection already flows through the Flatkey router and its model registry, adding an upstream option is a natural next step for the text/chat path. Your users who drive flatkey text generate from Codex, Claude Code, or Cursor would gain more model choice behind an OpenAI-compatible endpoint with the standard API-key auth Flatkey already expects — without replacing or altering any existing provider.
Proposal
I'm an engineer on the OrcaRouter team, and I'd like to propose OrcaRouter as an optional provider for Flatkey CLI.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it maps cleanly onto the provider/API abstraction Flatkey already has — the FLATKEY_API_KEY auth model, the documented --base-url override for alternate endpoints, and model discovery via flatkey models --json. Concretely, an integration would surface OrcaRouter-backed chat and reasoning models as an additional choice for text generation, discoverable through the existing registry flow. This is a proposal only: nothing is implemented or tested yet, and I'd defer to maintainers on where an extra route belongs in the current router architecture.
For Flatkey's cost-sensitive, agent-driven users, the most relevant OrcaRouter capabilities are:
- Multiple chat and reasoning models through one endpoint, so teams stop hard-coding a single vendor.
- Automatic model routing with provider failover, matching Flatkey's own one-router philosophy for the text path.
- Usage tracking and budgets, which suits teams that watch spend across repeated agent runs.
- Prompt caching to cut cost on the repetitive calls agent workflows make.
OrcaRouter is already integrated in open-source projects such as RAGFlow, Dify, goose, and promptfoo, with more listed at https://www.orcarouter.ai/built-with.
One transparent note: OrcaRouter runs an optional open-source partner program through which approved OSS projects can receive a 5% revenue share from usage attributed to their integration. Participation is entirely optional and not a prerequisite for the integration; if Flatkey is interested, we're glad to follow the project's disclosure and governance expectations.
Thanks for considering this — I'd welcome maintainer feedback on fit, and I'm happy to submit an implementation PR if the direction looks useful.
Problem
Flatkey CLI gives media teams and AI agents one
FLATKEY_API_KEY, one credit balance, and a single router for image, video, audio, and text generation. That design is aimed squarely at the workflow your Product Comparison calls out: repeated, agent-driven testing, where creator suites get expensive and peak-time queues stall iteration — your README notes Dreamina/Jimeng video calls can wait up to 5 hours. Making generation scriptable with--json,--dry-run, and a liveflatkey modelsregistry is what lets a pipeline own the work instead of a person babysitting it.Because model selection already flows through the Flatkey router and its model registry, adding an upstream option is a natural next step for the text/chat path. Your users who drive
flatkey text generatefrom Codex, Claude Code, or Cursor would gain more model choice behind an OpenAI-compatible endpoint with the standard API-key auth Flatkey already expects — without replacing or altering any existing provider.Proposal
I'm an engineer on the OrcaRouter team, and I'd like to propose OrcaRouter as an optional provider for Flatkey CLI.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it maps cleanly onto the provider/API abstraction Flatkey already has — the
FLATKEY_API_KEYauth model, the documented--base-urloverride for alternate endpoints, and model discovery viaflatkey models --json. Concretely, an integration would surface OrcaRouter-backed chat and reasoning models as an additional choice for text generation, discoverable through the existing registry flow. This is a proposal only: nothing is implemented or tested yet, and I'd defer to maintainers on where an extra route belongs in the current router architecture.For Flatkey's cost-sensitive, agent-driven users, the most relevant OrcaRouter capabilities are:
OrcaRouter is already integrated in open-source projects such as RAGFlow, Dify, goose, and promptfoo, with more listed at https://www.orcarouter.ai/built-with.
One transparent note: OrcaRouter runs an optional open-source partner program through which approved OSS projects can receive a 5% revenue share from usage attributed to their integration. Participation is entirely optional and not a prerequisite for the integration; if Flatkey is interested, we're glad to follow the project's disclosure and governance expectations.
Thanks for considering this — I'd welcome maintainer feedback on fit, and I'm happy to submit an implementation PR if the direction looks useful.