OrcaRouter provider support for peerd

peerd is the first agent harness I've seen that pulls the harness into the browser instead of the browser into the harness. The agent loop runs in the extension, drives the tabs and signed-in sessions someone already has open, and delegates page work to per-environment actors rather than to a hosted service. Keys stay in the vault, attach at the egress boundary, and never reach an actor worker's heap — so "no backend, no telemetry, no account" is a structural property, not a promise.

Because the keys stay the user's, the model is the one thing peerd asks someone to bring — and how many providers a single BYOK key reaches sets the ceiling on how useful that first run feels. Today that reach is one vendor account per adapter.

The problem / use case

extension/peerd-provider/failover.js already hands a turn to a second configured provider when the first hits a hard account limit or an overload that outlived the adapter's retries. That only helps if a second provider is already configured: a second vendor account, a second vault key, a second balance. Someone running an overnight goal-mode loop has no cheap way to widen that net.

What you'd like

I'm an engineer on the OrcaRouter team, so discount accordingly — the ask is narrow: OrcaRouter as an optional provider alongside the existing ones, replacing or changing none of them.

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it should fit the shape peerd already has: an adapter in extension/peerd-provider/registry.js reusing the /chat/completions conversion in format/to-openai.js and format/from-openai.js that the OpenAI and Z.ai GLM adapters already share, a vault secret name, and a key-format.js prefix so a bad paste fails at save time. No manifest change should be needed — <all_urls> and the https: connect-src already cover the host. Nothing is implemented or tested on our side; this is a proposal.

Three things that seem relevant here:

• One key, many vendors' models — one endpoint across chat, reasoning, and image models widens the Settings picker without an adapter per vendor; the registry's own backlog calls adding a provider "a registry entry, not chassis wiring."
• Upstream failover — the companion to failover.js: a gateway can absorb a dead upstream inside one key instead of requiring a second account.
• Prompt caching — peerd sends a ~20 KB system prompt every turn, so cache hits are a real cost lever across a long loop.

OrcaRouter has been landing in open-source projects — goose, Dify, and promptfoo among them.

One disclosure I would rather not bury: OrcaRouter runs an optional partner program where an approved open-source project can receive a 5% revenue share on usage attributed to its integration. It is not a condition of integrating and not why I'm asking, and I'm glad to follow this project's disclosure and governance rules. Details: https://www.orcarouter.ai/built-with

Alternatives considered

A second vendor account as a configured fallback is what peerd supports today; it works, but it means more signups and more vault keys, and it does not help someone who wants exactly one. If provider settings already accept a custom base URL, OrcaRouter could stay a manual override — an adapter just makes it first-class, with a proper key check.

If a maintainer is interested, I'd be glad to open an implementation PR once the approach is agreed. Thanks for building something that keeps the keys where they belong.

Read extension/peerd-provider/registry.js and compare the existing OpenAI and Z.ai GLM adapters, including format/to-openai.js and format/from-openai.js. Check extension/peerd-provider/key-format.js and the vault provider settings to determine the secret name and validation path, then inspect failover.js for provider compatibility. Done means OrcaRouter can be selected, its key is validated when saved, requests use the shared conversion, and tests cover the integration.