Problem
HyperFrames' bet is that a video composition is plain HTML — the same index.html that plays in a browser is the file a coding agent can already write. Your deterministic seek-and-render loop (same input, same frames, headless Chrome + FFmpeg) is what makes that viable in CI and automated content pipelines, and tldraw ships automated PR-walkthrough videos on top of it.
Model choice is already an operational knob for those pipelines: the CLI's vision captioning resolves OpenRouter, Vertex, or Gemini from env keys, and media-use picks HeyGen, ElevenLabs, or Lyria by which keys are present. Teams captioning or rendering at volume care about which endpoint is reachable and what a batch costs. OrcaRouter on that same switch would give them one credential with failover and usage tracking.
Proposed solution
I'd like to propose OrcaRouter as an optional, additive provider for the model calls HyperFrames makes. It would not replace or change any existing provider. The natural integration point is the env-keyed provider switch HyperFrames already uses: add an OrcaRouter branch alongside openrouter in packages/cli/src/capture/contentExtractor.ts and mirror it in the media-use provider docs, selected by an OrcaRouter API key in the environment. Nothing here is implemented or tested yet — this issue is to gauge interest.
For HyperFrames users, the most relevant capabilities are:
- Many chat, reasoning, and vision models through one endpoint — matching how the captioning code already calls OpenRouter over an OpenAI-style chat/completions API.
- Automatic routing and provider failover, so unattended batch captioning or rendering keeps moving when an upstream provider degrades.
- Usage tracking and budgets, with per-key spend visibility that fits the pipeline's existing "budget-exhausted" cost discipline.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the integration point looks the same as the provider branches already in the codebase. It is already wired into open-source projects such as Dify, promptfoo, and goose, which is why it may be worth offering here.
One transparent disclosure: OrcaRouter runs 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 not a prerequisite for adding the provider, and I'm happy to follow HyperFrames' governance and disclosure expectations.
Alternatives considered
Keeping per-vendor keys works, but each team maintains its own upstream accounts and handles failover and cost visibility itself. An OrcaRouter entry would not replace that — only give users who want one OpenAI-compatible credential another path.
Additional context
I'm an engineer on the OrcaRouter team. Projects building with OrcaRouter are listed at https://www.orcarouter.ai/built-with. If this sounds useful and the maintainers would accept an additive implementation, I'd be glad to submit a PR scoped to the provider switch described above.
Problem
HyperFrames' bet is that a video composition is plain HTML — the same
index.htmlthat plays in a browser is the file a coding agent can already write. Your deterministic seek-and-render loop (same input, same frames, headless Chrome + FFmpeg) is what makes that viable in CI and automated content pipelines, and tldraw ships automated PR-walkthrough videos on top of it.Model choice is already an operational knob for those pipelines: the CLI's vision captioning resolves OpenRouter, Vertex, or Gemini from env keys, and media-use picks HeyGen, ElevenLabs, or Lyria by which keys are present. Teams captioning or rendering at volume care about which endpoint is reachable and what a batch costs. OrcaRouter on that same switch would give them one credential with failover and usage tracking.
Proposed solution
I'd like to propose OrcaRouter as an optional, additive provider for the model calls HyperFrames makes. It would not replace or change any existing provider. The natural integration point is the env-keyed provider switch HyperFrames already uses: add an OrcaRouter branch alongside
openrouterinpackages/cli/src/capture/contentExtractor.tsand mirror it in the media-use provider docs, selected by an OrcaRouter API key in the environment. Nothing here is implemented or tested yet — this issue is to gauge interest.For HyperFrames users, the most relevant capabilities are:
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the integration point looks the same as the provider branches already in the codebase. It is already wired into open-source projects such as Dify, promptfoo, and goose, which is why it may be worth offering here.
One transparent disclosure: OrcaRouter runs 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 not a prerequisite for adding the provider, and I'm happy to follow HyperFrames' governance and disclosure expectations.
Alternatives considered
Keeping per-vendor keys works, but each team maintains its own upstream accounts and handles failover and cost visibility itself. An OrcaRouter entry would not replace that — only give users who want one OpenAI-compatible credential another path.
Additional context
I'm an engineer on the OrcaRouter team. Projects building with OrcaRouter are listed at https://www.orcarouter.ai/built-with. If this sounds useful and the maintainers would accept an additive implementation, I'd be glad to submit a PR scoped to the provider switch described above.