Summary
CC Switch is a cross-platform desktop "switchboard" for AI coding CLIs (Claude Code, Codex, Gemini CLI, OpenCode, and others). It provides one-click provider switching across 50+ provider presets, a local OpenAI-compatible routing proxy with automatic failover, request logging, and usage visibility. This request asks OpenWorker to integrate with CC Switch so users can route OpenWorker's model calls through it — gaining centralized provider management, failover, and usage tracking without hand-editing OpenWorker's provider config for every vendor.
Motivation
Provider sprawl. OpenWorker already supports many providers (OpenAI, Anthropic, Gemini, Bedrock, Vertex, plus OpenAI-compatible vendors and resellers), each with its own key and endpoint. Users juggling several want a single control plane for switching and failover rather than reconfiguring OpenWorker each time.
Failover & resilience. CC Switch's local proxy can fail over between upstream providers automatically — useful for an agent that runs long, unattended jobs where a single provider hiccup shouldn't kill a run.
Usage visibility. Centralized request logs and usage metering across providers is something OpenWorker doesn't currently surface.
Ecosystem fit. CC Switch already targets exactly this class of tool (coding/agent CLIs). OpenWorker is a natural addition to its supported-tool list, and vice versa.
How it could work today (no code change)
OpenWorker's openai provider descriptor already accepts a custom endpoint (base_url, "For Azure OpenAI, vLLM, or any OpenAI-compliant server"). Since CC Switch exposes a local OpenAI-compatible proxy, a user can in principle point OpenWorker's OpenAI provider base_url at CC Switch's local proxy URL and route traffic through it. This works but is fragile and undiscoverable:
It only exercises the OpenAI-compatible path; native Anthropic/Gemini providers bypass it.
There's no first-class UI affordance, preset, or documentation tying the two together.
Failover/provider selection happens inside CC Switch, invisible to OpenWorker's model picker and capability matrix.
Proposal
Treat CC Switch as a first-class routing option, at one of two levels:
Lightweight (recommended first step): Document and template the "route through CC Switch" setup — a preset/guide for pointing the OpenAI provider's base_url at CC Switch's local proxy, including how OpenWorker's model strings map to CC Switch's provider presets. Possibly a dedicated "CC Switch / local proxy" choice in the provider picker that prefills the local endpoint.
Deeper integration: Recognize CC Switch as a provider type so OpenWorker can (a) discover the active upstream provider and reflect it in the UI, (b) keep the capability matrix (vision/tools flags) correct as CC Switch swaps upstreams underneath, and (c) surface CC Switch's usage/log data where relevant.
Considerations / open questions
Capability detection across failover. OpenWorker's capability matrix (coworker/providers/matrix.py / capabilities.py) keys vision/tools/PDF flags to specific model ids. If CC Switch fails over between upstreams of differing capabilities mid-run, OpenWorker needs a sane way to resolve capabilities for the routed model — otherwise image/PDF handling could silently degrade (the same class of issue as the Qwen vision-flag report).
Native vs. compatible paths. Routing everything through CC Switch's OpenAI-compatible proxy means native Anthropic/Gemini features (e.g. extended thinking, PDF blocks) depend on how faithfully the proxy translates. Worth documenting which features survive the proxy.
Local-first alignment. CC Switch is local-first, matching OpenWorker's model — keys and routing stay on the machine. No new cloud dependency.
Scope. The maintainer may prefer to keep provider routing out of scope and simply document the custom-endpoint workaround; either outcome is useful.
Environment / context
OpenWorker, latest main (registry.py, matrix.py, capabilities.py read from github.com/andrewyng/openworker on 2026-08-02).
CC Switch: github.com/farion1231/cc-switch (supports Claude Code, Claude Desktop, Codex, Gemini CLI, Grok Build, OpenCode, OpenClaw, Hermes; 50+ provider presets; local OpenAI-compatible proxy with failover, request logs, usage visibility).
Summary
CC Switch is a cross-platform desktop "switchboard" for AI coding CLIs (Claude Code, Codex, Gemini CLI, OpenCode, and others). It provides one-click provider switching across 50+ provider presets, a local OpenAI-compatible routing proxy with automatic failover, request logging, and usage visibility. This request asks OpenWorker to integrate with CC Switch so users can route OpenWorker's model calls through it — gaining centralized provider management, failover, and usage tracking without hand-editing OpenWorker's provider config for every vendor.
Motivation
Provider sprawl. OpenWorker already supports many providers (OpenAI, Anthropic, Gemini, Bedrock, Vertex, plus OpenAI-compatible vendors and resellers), each with its own key and endpoint. Users juggling several want a single control plane for switching and failover rather than reconfiguring OpenWorker each time.
Failover & resilience. CC Switch's local proxy can fail over between upstream providers automatically — useful for an agent that runs long, unattended jobs where a single provider hiccup shouldn't kill a run.
Usage visibility. Centralized request logs and usage metering across providers is something OpenWorker doesn't currently surface.
Ecosystem fit. CC Switch already targets exactly this class of tool (coding/agent CLIs). OpenWorker is a natural addition to its supported-tool list, and vice versa.
How it could work today (no code change)
OpenWorker's openai provider descriptor already accepts a custom endpoint (base_url, "For Azure OpenAI, vLLM, or any OpenAI-compliant server"). Since CC Switch exposes a local OpenAI-compatible proxy, a user can in principle point OpenWorker's OpenAI provider base_url at CC Switch's local proxy URL and route traffic through it. This works but is fragile and undiscoverable:
It only exercises the OpenAI-compatible path; native Anthropic/Gemini providers bypass it.
There's no first-class UI affordance, preset, or documentation tying the two together.
Failover/provider selection happens inside CC Switch, invisible to OpenWorker's model picker and capability matrix.
Proposal
Treat CC Switch as a first-class routing option, at one of two levels:
Lightweight (recommended first step): Document and template the "route through CC Switch" setup — a preset/guide for pointing the OpenAI provider's base_url at CC Switch's local proxy, including how OpenWorker's model strings map to CC Switch's provider presets. Possibly a dedicated "CC Switch / local proxy" choice in the provider picker that prefills the local endpoint.
Deeper integration: Recognize CC Switch as a provider type so OpenWorker can (a) discover the active upstream provider and reflect it in the UI, (b) keep the capability matrix (vision/tools flags) correct as CC Switch swaps upstreams underneath, and (c) surface CC Switch's usage/log data where relevant.
Considerations / open questions
Capability detection across failover. OpenWorker's capability matrix (coworker/providers/matrix.py / capabilities.py) keys vision/tools/PDF flags to specific model ids. If CC Switch fails over between upstreams of differing capabilities mid-run, OpenWorker needs a sane way to resolve capabilities for the routed model — otherwise image/PDF handling could silently degrade (the same class of issue as the Qwen vision-flag report).
Native vs. compatible paths. Routing everything through CC Switch's OpenAI-compatible proxy means native Anthropic/Gemini features (e.g. extended thinking, PDF blocks) depend on how faithfully the proxy translates. Worth documenting which features survive the proxy.
Local-first alignment. CC Switch is local-first, matching OpenWorker's model — keys and routing stay on the machine. No new cloud dependency.
Scope. The maintainer may prefer to keep provider routing out of scope and simply document the custom-endpoint workaround; either outcome is useful.
Environment / context
OpenWorker, latest main (registry.py, matrix.py, capabilities.py read from github.com/andrewyng/openworker on 2026-08-02).
CC Switch: github.com/farion1231/cc-switch (supports Claude Code, Claude Desktop, Codex, Gemini CLI, Grok Build, OpenCode, OpenClaw, Hermes; 50+ provider presets; local OpenAI-compatible proxy with failover, request logs, usage visibility).