Tam Nhu Tran 53030891c6 feat(ui/design-system): codify rail-anchored layout invariants and palette
Adds a page-level design system spec for CCS dashboard Config pages,
without migrating any production page yet. Pure-spec PR: docs +
primitive treatments + DEV-only /_styleguide route. Production page
adoption is intentionally left for follow-up work, one page at a time.

Spec — `ui/docs/design-system.md`:

- §0 Layout invariants (NEVER VIOLATE): two-column shell, no second
  horizontal strip below the global topbar, sibling-pane top alignment,
  cliproxy as canonical reference, user-resizable form/json split, and
  content-fit unified rail (`w-fit min-w-[240px] max-w-[360px]`)
- §1 identity-strip patterns: HeroBar (home), rail-anchored (cliproxy),
  PageHeader (Monitor-only), Bespoke (health)
- §2 body archetypes: Config (rail + form + optional json) and Monitor
- §4 anti-patterns with rejected code samples (PageHeader-over-
  ConfigLayout, tab-bar offsetting json pane, redundant description
  band, blank vertical band)
- §5 color & accent rules using the existing Pampas/Crail palette only:
  1-accent-dot rule, sibling-pane differentiation, status pill spec,
  three-tier intensity ladder, sensitive-field treatment per §5g

Decisions log — `ui/docs/design-decisions.md`:

- v1.6: content-fit rail (replaces fixed 260px)
- v1.5: color & accent treatment for body panes
- v1.4: resizable form/json split
- v1.3: layout invariants and rail-anchored default for Config

Primitives — `ui/src/components/config-layout/`:

- ConfigLayout: rail rendered as content-fit `<aside>` within the
  unified envelope; form↔json split via react-resizable-panels (already
  in deps) with autoSaveId-driven per-page localStorage persistence
- FormPane: 1px Crail top strip on header + soft from-card gradient +
  inset bottom shadow for scroll-depth cue; body wash bg-muted/20 so
  FormSections read as elevated cards; footer bg-muted/40 anchors save
- FormSection: 2px Crail leading-edge stripe with three-tier intensity
  (default 30% / hover 70% / focus-within solid + ring + shadow) + 1.5px
  accent dot prefixing each title
- JsonPane: bg-muted/30 shell visually recesses the read-only pane vs
  the active form pane (bg-card); accent dot + status pill in header;
  inner <pre> sits inside an inset-shadow well; content stays plain
  (a dedicated JSON viewer with its own color coding will replace it
  later — pages MUST NOT add inline JSON tints in the meantime)
- ListPane: selected row uses three-tier intensity ladder (no stripe at
  rest, accent/30 stripe on hover, solid Crail stripe + bg-accent/10
  row tint + accent-tinted icon and count badge on selection)

Sensitive input primitive — `ui/src/components/ui/masked-input.tsx`:

Upgraded to match §5g: lock glyph prefixing label, "sensitive" accent
pill on the label row, accent focus ring (the only place the default
ring is overridden), accent-tinted reveal toggle on hover. Existing
consumers (settings-dialog, websearch, friendly-ui-section, env-editor-
section) inherit the treatment without code changes.

Shared Field — `ui/src/components/forms/field.tsx`:

Tiny self-documenting Field component referenced by /_styleguide demos.
Auto-detects sensitive labels (AUTH_TOKEN | API_KEY | SECRET | PASSWORD
| PRIVATE_KEY) and applies §5g treatment. Production pages can adopt
this as a follow-up; no production code currently consumes it.

Live styleguide — `ui/src/pages/_styleguide.tsx`:

DEV-only route (gated by import.meta.env.DEV in App.tsx) showcasing
every primitive in isolation plus composed Config + Monitor archetype
demos. Intro callout surfaces the §0 invariants. §1b/§2a/§2b demos are
canonical rail-anchored examples authors can copy. Demo content uses
realistic Anthropic-style env field sets so the visual density mirrors
the cliproxy reference.

What this PR does NOT do:

- No production page rewrites — `pages/{api,accounts,codex,copilot,
  cursor,droid,shared,updates,analytics,claude-extension,cliproxy-ai-
  providers}` are unchanged
- No test selector updates — the existing test suite passes (excepting
  the 2 pre-existing account-visual-groups failures already on dev)
- No HTML preview reports — the canonical visual reference is the live
  /_styleguide page
- No new dependencies — `react-resizable-panels` was already declared

Validation: typecheck + lint + format + build clean. Test suite green
(519/521 — 2 pre-existing dev failures unrelated to this PR).
2026-04-26 13:30:03 -04:00
2026-04-24 04:24:34 +00:00

CCS - Claude Code Switch

CCS Logo

The multi-provider profile and runtime manager for Claude Code and compatible CLIs

Run Claude, Codex, Droid-routed profiles, GLM, local models, and Anthropic-compatible APIs without config thrash.

License npm PoweredBy

Website | Documentation | Product Tour | CLI Reference

Why CCS

CCS gives you one stable command surface while letting you switch between:

  • multiple runtimes such as Claude Code, Factory Droid, and Codex CLI
  • multiple Claude subscriptions and isolated account contexts
  • OAuth providers like Codex, Copilot, Kiro, Claude, Qwen, Kimi, and more
  • API and local-model profiles like GLM, Kimi, OpenRouter, Ollama, llama.cpp, Novita, and Alibaba Coding Plan

The goal is simple: stop rewriting config files, stop breaking active sessions, and move between providers in seconds.

Quick Start

npm install -g @kaitranntt/ccs
ccs config

Then launch whatever runtime fits the task:

ccs
ccs codex
ccs --target droid glm
ccs glm
ccs ollama

OpenAI-Compatible Routing

CCS can now bridge Claude Code into OpenAI-compatible providers through a local Anthropic-compatible proxy instead of requiring a native Anthropic upstream.

ccs api create --preset hf
ccs hf

Need to manage the proxy manually?

ccs proxy start hf
eval "$(ccs proxy activate)"

The proxy also supports request-time profile:model selectors, scenario-based model routing through proxy.routing, and explicit activation helpers such as ccs proxy activate --fish.

Guide: OpenAI-Compatible Provider Routing

claude-code-router is an excellent standalone tool for routing Claude Code requests to OpenAI-compatible providers. CCS's local proxy and SSE transformation work was directly informed by CCR's transformer architecture.

Use CCR when you want a standalone router without CCS profile management. Use CCS when you want the routing flow integrated with CCS profiles, runtime bridges, and the existing ccs command surface.

Need the full setup path instead of the short version?

Need Start here
Install and verify CCS /getting-started/installation
First successful session /getting-started/first-session
Visual walkthrough /getting-started/product-tour
Provider selection /providers/concepts/overview
Full command reference /reference/cli-commands
Troubleshooting /reference/troubleshooting

See CCS In Action

Usage Analytics

Analytics Dashboard

Track usage, costs, and session patterns across profiles. Deep dive: Dashboard Analytics.

Live Auth And Health Monitoring

Live Auth Monitor

See auth state, account health, and provider readiness without dropping into raw config. Deep dive: Live Auth Monitor.

OAuth Provider Control Center

CLIProxy API

Manage OAuth-backed providers, quota visibility, and proxy-wide routing from one place. CCS now surfaces round-robin vs fill-first natively in both CLI and dashboard flows instead of hiding that choice inside raw upstream controls. The original CLIProxyAPI backend remains the default; the community-maintained CLIProxyAPIPlus fork is opt-in for plus-only providers. Deep dive: CLIProxy API.

Managed Tooling And Fallbacks

WebSearch Fallback

CCS can provision first-class local tools like WebSearch and image analysis for third-party launches instead of leaving you to wire them by hand. Browser automation now has a first-class setup path as well. Deep dive: WebSearch | Browser Automation.

Docs Matrix

The README stays short on purpose. The docs site owns the detailed guides and reference material.

If you want to... Read this
Understand what CCS is and how the pieces fit together Introduction
Install CCS cleanly on a new machine Installation
Go from install to a successful first run Your First CCS Session
See the dashboard and workflow surfaces before setup Product Tour
Compare OAuth providers, Claude accounts, and API profiles Provider Overview
Learn the dashboard structure and feature pages Dashboard Overview
Configure profiles, paths, and environment variables Configuration
Understand browser attach vs Codex browser tooling Browser Automation
Keep OpenCode aligned with your live CCS setup OpenCode Sync Plugin
Browse every command and flag CLI Commands
Recover from install, auth, or provider failures Troubleshooting
Understand storage, config, and architecture details Reference

Example Workflow

# Design with default Claude
ccs "design the auth flow"

# Implement with a different provider
ccs codex "implement the user service"

# Use a cheaper API profile for routine work
ccs glm "clean up tests and docs"

# Run a local model when you need privacy or offline access
ccs ollama "summarize these logs"

Community Projects

Project Author Description
opencode-ccs-sync @JasonLandbridge Auto-sync CCS providers into OpenCode

Contribute And Report Safely

  • Contributing guide: CONTRIBUTING.md
  • Daily local gate: bun run format && bun run lint:fix && bun run validate (validate is the fast path only)
  • Before review or merge confidence: bun run validate:ci-parity
  • If PR checks stay queued for more than 10 minutes, assume the self-hosted runner is offline and notify a maintainer instead of retrying blindly
  • Starter work: good first issue, help wanted
  • Questions: open a question issue
  • Security reports: SECURITY.md and the private advisory form

Star History

Star History Chart

S
Description
Switch between Claude accounts, Gemini, Copilot, OpenRouter (300+ models) via CLIProxyAPI OAuth proxy. Visual dashboard, remote proxy support, WebSearch fallback. Zero-config to production-ready.
Readme MIT
37 MiB
0 Stars 1 Watchers 0 Forks
Languages
TypeScript 82.1%
HTML 7.4%
JavaScript 6.9%
Swift 1.9%
Shell 1%
Other 0.6%