OrcaRouter provider support for Parallel Code

[putraperdana1207-pixel]

Why Parallel Code is a great home for more model choice

Parallel Code runs AI coding CLIs — Claude Code, Codex, Gemini, Copilot, Antigravity — side by side, each task in its own git worktree and branch. That automatic isolation removes the merge conflicts that normally cap how many parallel agents one developer can safely run; the reviewable diffs you merge or toss are the payoff.

Ask Code already makes the model behind a question configurable — Claude Code by default or MiniMax M2.7, called as a direct chat/completions endpoint with a Bearer API key set in Settings. A gateway serving many models through one endpoint would let those users pick the right model per question instead of re-pointing provider config each time.

Proposal: OrcaRouter as an optional Ask Code provider

I'm an engineer on the OrcaRouter team. This is a proposal for maintainer feedback, not finished code — nothing is implemented or tested yet.

The seam is electron/ipc/ask-code.ts, where AskCodeProvider is currently 'claude' | 'minimax', and the MiniMax backend (ask-code-minimax.ts) is a fetch to https://api.minimax.io/v1/chat/completions with an Authorization: Bearer header, the API key held in the main process. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so an option could follow the same shape as the MiniMax backend. I'd want your call on where the provider enum, Settings entry, and key storage should live before writing code. Adding it would be purely optional and would not replace or change the Claude Code, MiniMax, or per-agent CLI setups you already ship.

Capabilities most relevant to Parallel Code's users:

• Multiple chat and reasoning models through one endpoint — one OrcaRouter key and base URL lets Ask Code reach models beyond today's two backends.
• Automatic routing and provider failover — if an upstream model is rate-limited or degraded, a routed request falls back to another capable model instead of failing the Q&A.
• Usage tracking — per-project request and spend visibility for teams that share the app.

OrcaRouter already has open-source integrations including Dify, goose, promptfoo, and OpenCode — the last an agent Parallel Code can itself dispatch. For a project that highlights being free, open source, and without an extra platform fee, an optional gateway only adds a choice.

One transparent note: OrcaRouter's optional open-source partner program gives approved OSS projects a 5% revenue share from OrcaRouter usage attributed to their integration. That is not a condition of integration, and I'd gladly follow whatever disclosure or governance rules Parallel Code prefers.

Existing integrations are listed at https://www.orcarouter.ai/built-with. If this direction seems useful, I'd welcome your thoughts — and, with your go-ahead, I'd be glad to submit an implementation PR.

[johannesjo]

Thanks for the detailed writeup, and for actually reading the code. Your description of the seam is accurate, and I appreciate you disclosing the revenue-share program upfront rather than after the fact.

I don't want to add a third named vendor, though, and I don't think you need one.

Why not a per-vendor enum. 'claude' | 'minimax' isn't one constant. It's hardcoded in electron/ipc/ask-code.ts, src/store/types.ts (twice), src/store/ui.ts, src/store/persistence.ts, src/components/SettingsDialog.tsx, plus a dedicated IPC channel and preload allowlist entry for the key, and vendor-specific prose in README.md and PRIVACY.md. Every new vendor is that same diff plus an indefinite maintenance and privacy-doc obligation, for a backend that differs from the existing one only in a URL string and a model name. That doesn't scale, and two is where I stop.

What I'd take instead: a generic "OpenAI-compatible endpoint" provider. Base URL, model name, and API key: three fields in Settings, reusing the MiniMax streaming path nearly unchanged. That covers OrcaRouter, OpenRouter, Together, an in-house gateway, or a local llama.cpp/Ollama server, with no vendor names in the code.

Worth noting: all three capabilities you list (multi-model access, routing and failover, usage tracking) are server-side features of your gateway. They work the moment a user can point Ask Code at your base URL. None of them needs OrcaRouter-specific client code, which to me is the strongest argument that the generic option serves your users just as well.

On the revenue share: thanks for stating it plainly. It's also why I'd rather this be a text field the user fills in than a name I ship in a dropdown. A paid referral relationship shouldn't decide which vendors get first-class placement in a free, open-source app.

So: a PR for a generic OpenAI-compatible provider is welcome and I'd review it. Two constraints if you take it on:

• The API key stays in the main process, in memory only. Never persisted, never returned to the renderer, same rule ask-code-minimax.ts follows today. Users re-enter it per launch; that's deliberate.
• The base URL needs validation (require https:, reject other schemes), and PRIVACY.md needs a line noting that with a custom endpoint configured, prompts and code selections go to whatever host the user pointed at.

Docs would describe this as "any OpenAI-compatible endpoint". I'm not planning to list gateway vendors by name.

[putraperdana1207-pixel]

Agreed on the generic OpenAI-compatible provider — OrcaRouter needs nothing vendor-specific beyond a base URL, model, and key, so the three-field Settings entry covers it.

One implementation note on the base-URL validation constraint. An unconditional https: requirement would reject the local-server case you listed, because those default to plain HTTP on loopback:

• Ollama serves its OpenAI-compatible endpoint at http://localhost:11434/v1 over HTTP by default (https://docs.ollama.com/api/openai-compatibility).
• llama.cpp llama-server binds http://127.0.0.1:8080/v1 over plain HTTP by default; TLS is only available when built with OpenSSL and given --ssl-key-file/--ssl-cert-file (https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md).

Suggestion: require https: for non-loopback hosts, but allow http: when the host is loopback (localhost, 127.0.0.1, [::1]). That keeps remote keys/traffic on TLS while leaving the local Ollama/llama.cpp path usable.