feat: add OrcaRouter as a named LLM provider

[bangla24bdrang-lab]

Summary

Add OrcaRouter as a first-class named provider in GoClaw's provider registry, mirroring the existing OpenRouter adapter.

For GoClaw users running multi-agent gateways with encrypted API keys and per-tenant provider rows, OrcaRouter previously had to be entered as an anonymous openai_compat custom base URL. This PR makes it a discoverable provider in the dashboard, CLI wizards, onboard seeding, and env-var config — the same surface OpenRouter already gets.

Type

• Feature
• Bug fix
• Hotfix (targeting main)
• Refactor
• Docs
• CI/CD

What & why

GoClaw describes itself as a "Multi-agent AI gateway built in Go. 20+ LLM providers" with a unified provider-adapter system, and it already lists OpenRouter as a named provider alongside Anthropic, OpenAI, Gemini, and others. OrcaRouter fits that same slot: it is an OpenAI-compatible AI gateway built for both models and agents. Like OpenRouter, it exposes a provider/model namespace across many models — but it also combines adaptive routing, automatic failover, zero-markup inference, observability, guardrails, and agent-tool governance behind the same endpoint. Adding orcarouter as a first-class provider means this project's users can use that stack directly, without treating OrcaRouter as an anonymous custom base URL.

It also runs gateway-level, zero-trust security for AI agents on the same endpoint — screening every prompt/response and governing every tool call on a default-deny basis, with no application code changes.

This PR wires OrcaRouter through the exact paths OpenRouter already uses:

• internal/store/provider_store.go — new orcarouter provider type + default API base/model
• internal/config/ — providers.orcarouter config block, GOCLAW_ORCAROUTER_API_KEY env override, secret masking, HasAnyProvider
• cmd/gateway_providers.go + internal/http/providers.go — runtime registration for env/config and DB-backed providers (verify + chat work without a restart)
• cmd/providers_cmd.go, cmd/setup_provider.go, cmd/onboard_managed.go, cmd/doctor.go — CLI/onboard/doctor surfaces
• internal/providers/openai_config.go — provider-prefixed model-ID resolution, same guard as OpenRouter
• ui/web + ui/desktop provider constants — dashboard picker entries
• README.md — provider list

Test Plan

• go build ./... and go build -tags sqliteonly ./... pass
• go vet ./... passes
• go test ./internal/store/ ./internal/config/ ./internal/providers/ ./cmd/ pass
• Live-tested the OrcaRouter endpoint (https://api.orcarouter.ai/v1) with a real API key: GET /v1/models, non-streaming and streaming /v1/chat/completions all return 200

Note: internal/http has pre-existing Ollama-related test failures in this container (DockerLocalhost rewrites localhost → host.docker.internal because /.dockerenv exists); they fail identically on the unmodified baseline and are unrelated to this change.

---

I'm an engineer on the OrcaRouter team.

Discord: discord.gg/YEubt8enRA · X: https://x.com/OrcaRouter

[clark-cant]

Maintainer review

Summary: This is a coherent, low-complexity provider-catalog addition that follows the established OpenRouter/OpenAI-compatible wiring across config, registry, DB-backed registration, CLI/onboarding, and both UIs.

Mandatory gates: duplicate/prior implementation clear (no earlier OrcaRouter PR or issue found); project standards found (AGENTS.md, CLAUDE.md, CONTRIBUTING.md, provider architecture docs); strategic value is plausible but the new named provider adds a permanent compatibility contract beyond the existing custom OpenAI-compatible endpoint.

Important — add focused regression coverage before merge. The PR changes 14 runtime/config/store/UI files yet adds no tests. Please add targeted tests that cover at least: (1) orcarouter accepted as a provider type and registered from config plus DB data, (2) default API base/model behavior, including an explicit custom API base, (3) provider-prefixed and unprefixed model resolution behavior, and (4) config credential masking/stripping or env override parity. This is needed to prevent silent onboarding/runtime regressions as provider registration paths evolve.

Merge status: GitHub currently reports UNSTABLE with no check rollup, so this is not merge-ready. No merge attempted.

Verdict: Request changes — coverage and a green/mergeable CI state are required; no separate duplicate or code-correctness blocker found in the current diff.

Posted by github-maintain cron-safe automation — 2026-08-29T04:10:14Z