Skip to content

OrcaRouter provider support for ComfyUI Partner Nodes #1662

Description

@putraperdana1207-pixel

The Partner Nodes section solves a real problem: it explains how ComfyUI calls closed-source models through API requests, so users reach external models "without complex API key setup" while ComfyUI core stays open source and local. The OpenRouter LLM page is the clearest example, describing one API that exposes many providers so a workflow can switch models without changing its integration, with inputs that appear per model for vision, video, and reasoning effort.

The repo's tooling makes the same bet. .env.local.example documents its translation and review backends as an "OpenAI-compatible endpoint" and names OpenRouter, DeepSeek, and DashScope Qwen-MT as interchangeable. An OrcaRouter provider would add one more opt-in option beside the providers these docs already cover.

Proposal: OrcaRouter as an optional Partner Node provider

I'm an engineer on the OrcaRouter team. OrcaRouter is an AI gateway that exposes chat, reasoning, image, and video models from many providers through one API. This is a proposal for an additional opt-in provider. It would not replace or change any existing Partner Node, the Comfy Cloud nodes, or the documented --disable-api-nodes behavior.

Why it may fit ComfyUI users:

  • One endpoint across modalities. Chat, reasoning, image, and video models sit behind a single base URL, which matches the image, video, audio, and LLM spread of the current Partner Nodes.
  • Automatic model routing and provider failover. Requests are matched to a suitable model, and retries land on healthy fallback capacity, so a long graph is less likely to stall on one provider's bad day.
  • Usage tracking with budgets and team access controls. Per-request logs with model, latency, and cost, plus spend caps and seats, echo the "Controlled costs" advantage the Partner Nodes overview already promises.
  • Prompt caching. Cached input tokens are billed at the provider's cache rate, which helps repeated system prompts and automated pipelines such as the docs translation and review runs.

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Based on the provider abstraction already in this repo, an OrcaRouter node would be a sibling of the existing LLM provider node, and an OrcaRouter base URL would be a drop-in option for TRANSLATE_API_BASE_URL and REVIEW_API_BASE_URL. I have not written or tested any code for this. It is a proposal only, and I would follow whichever implementation path maintainers prefer.

OrcaRouter is already in use across open-source tooling, including Dify, RAGFlow, promptfoo, and models.dev / OpenCode.

In the interest of transparency: OrcaRouter runs an optional open-source partner program. Approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Taking part is not a prerequisite for an integration, and I am glad to follow this project's disclosure and governance requirements.

More detail: https://www.orcarouter.ai/built-with

Would you be open to an OrcaRouter provider here? I am happy to answer questions about routing, pricing, or data handling first, and to open an implementation PR if that would be welcome.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions