How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

ccsync-isolated - Prompt - OpenSmartRoute

Name: ccsync-isolated
Author: colinc86

Prompt file imported from colinc86/ccsync (.claude/commands/ccsync-isolated.md). Copyright stays with the author.

/ccsync-isolated

Sets up an isolated sandbox for manual ccsync runs. After this command, you have a built ./ccsync, a tmp $HOME, and a local bare remote — drive the TUI, inspect state, and tear down without touching the user's real config.

The full procedure and rationale live in the ccsync-isolated-run skill. This command is the sandbox-setup half only.

What to do

Create the sandbox.

SANDBOX="$(mktemp -d -t ccsync-sandbox.XXXXXX)"
mkdir -p "$SANDBOX/home/.claude"
git init --bare "$SANDBOX/remote.git"

Build ccsync from the current worktree.

(cd "$(git rev-parse --show-toplevel)" && go build -o ./ccsync ./cmd/ccsync)

Report back to the user — in the chat — with:
- Sandbox path: $SANDBOX
- Bare remote: file://$SANDBOX/remote.git
- How to start the TUI:
```
HOME=$SANDBOX/home ./ccsync
```
- How to tear down when done:
```
rm -rf "$SANDBOX"
```
Do not start the TUI from within this command — the TUI is interactive and needs the user's actual terminal. Give them the invocation to run and wait for their feedback.

Optional: two-machine sandbox

If the user wants to verify a multi-machine flow (the common case for bug reports), offer the two-home variant:

SANDBOX="$(mktemp -d -t ccsync-sandbox.XXXXXX)"
git init --bare "$SANDBOX/remote.git"
mkdir -p "$SANDBOX/home1/.claude" "$SANDBOX/home2/.claude"
echo "Machine 1: HOME=$SANDBOX/home1 ./ccsync"
echo "Machine 2: HOME=$SANDBOX/home2 ./ccsync"
echo "Bare remote: file://$SANDBOX/remote.git"

Safety notes

mktemp -d produces a fresh dir each invocation — no collision risk with prior runs.
Nothing touches ~/.claude, ~/.ccsync, or any network. The file:// remote is local.
If the user's shell is still in the sandbox session (HOME exported) they should unset HOME or start a fresh shell before doing anything else. Mention this when reporting.

ccsync-isolated-run skill — full procedure, multi-machine patterns, inspection commands, pitfalls.
/ccsync-verify — for automated verification; use that first, then /ccsync-isolated only for what tests can't cover.

Install ccsync-isolated and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# /ccsync-isolated Sets up an isolated sandbox for manual ccsync runs. After this command, you have a built `./ccsync`, a tmp `$HOME`, and a local bare remote — drive the TUI, inspect state, and tear down without touching the user's real config. The full procedure and rationale live in the `ccsync-isolated-run` skill. This command is the sandbox-setup half only. ## What to do 1. Create the sandbox. ```bash SANDBOX="$(mktemp -d -t ccsync-sandbox.XXXXXX)" mkdir -p "$SANDBOX/home/.claude" git init --bare "$SANDBOX/remote.git" ``` 2. Build ccsync from the current worktree. ```bash (cd "$(git rev-parse --show-toplevel)" && go build -o ./ccsync ./cmd/ccsync) ``` 3. Report back to the user — in the chat — with: - Sandbox path: `$SANDBOX` - Bare remote: `file://$SANDBOX/remote.git` - How to start the TUI: ``` HOME=$SANDBOX/home ./ccsync ``` - How to tear down when done: ``` rm -rf "$SANDBOX" ``` 4. **Do not** start the TUI from within this command — the TUI is interactive and needs the user's actual terminal. Give them the invocation to run and wait for their feedback. ## Optional: two-machine sandbox If the user wants to verify a multi-machine flow (the common case for bug reports), offer the two-home variant: ```bash SANDBOX="$(mktemp -d -t ccsync-sandbox.XXXXXX)" git init --bare "$SANDBOX/remote.git" mkdir -p "$SANDBOX/home1/.claude" "$SANDBOX/home2/.claude" echo "Machine 1: HOME=$SANDBOX/home1 ./ccsync" echo "Machine 2: HOME=$SANDBOX/home2 ./ccsync" echo "Bare remote: file://$SANDBOX/remote.git" ``` ## Safety notes - `mktemp -d` produces a fresh dir each invocation — no collision risk with prior runs. - Nothing touches `~/.claude`, `~/.ccsync`, or any network. The `file://` remote is local. - If the user's shell is still in the sandbox session (`HOME` exported) they should `unset HOME` or start a fresh shell before doing anything else. Mention this when reporting. ## Related - `ccsync-isolated-run` skill — full procedure, multi-machine patterns, inspection commands, pitfalls. - `/ccsync-verify` — for automated verification; use that first, then `/ccsync-isolated` only for what tests can't cover.

{ "prompt": "# /ccsync-isolated\n\nSets up an isolated sandbox for manual ccsync runs. After this\ncommand, you have a built `./ccsync`, a tmp `$HOME`, and a local\nbare remote — drive the TUI, inspect state, and tear down without\ntouching the user's real config.\n\nThe full procedure and rationale live in the `ccsync-isolated-run`\nskill. This command is the sandbox-setup half only.\n\n## What to do\n\n1. Create the sandbox.\n\n ```bash\n SANDBOX=\"$(mktemp -d -t ccsync-sandbox.XXXXXX)\"\n mkdir -p \"$SANDBOX/home/.claude\"\n git init --bare \"$SANDBOX/remote.git\"\n ```\n\n2. Build ccsync from the current worktree.\n\n ```bash\n (cd \"$(git rev-parse --show-toplevel)\" && go build -o ./ccsync ./cmd/ccsync)\n ```\n\n3. Report back to the user — in the chat — with:\n\n - Sandbox path: `$SANDBOX`\n - Bare remote: `file://$SANDBOX/remote.git`\n - How to start the TUI:\n ```\n HOME=$SANDBOX/home ./ccsync\n ```\n - How to tear down when done:\n ```\n rm -rf \"$SANDBOX\"\n ```\n\n4. **Do not** start the TUI from within this command — the TUI is\n interactive and needs the user's actual terminal. Give them the\n invocation to run and wait for their feedback.\n\n## Optional: two-machine sandbox\n\nIf the user wants to verify a multi-machine flow (the common case\nfor bug reports), offer the two-home variant:\n\n```bash\nSANDBOX=\"$(mktemp -d -t ccsync-sandbox.XXXXXX)\"\ngit init --bare \"$SANDBOX/remote.git\"\nmkdir -p \"$SANDBOX/home1/.claude\" \"$SANDBOX/home2/.claude\"\necho \"Machine 1: HOME=$SANDBOX/home1 ./ccsync\"\necho \"Machine 2: HOME=$SANDBOX/home2 ./ccsync\"\necho \"Bare remote: file://$SANDBOX/remote.git\"\n```\n\n## Safety notes\n\n- `mktemp -d` produces a fresh dir each invocation — no collision\n risk with prior runs.\n- Nothing touches `~/.claude`, `~/.ccsync`, or any network. The\n `file://` remote is local.\n- If the user's shell is still in the sandbox session (`HOME`\n exported) they should `unset HOME` or start a fresh shell\n before doing anything else. Mention this when reporting.\n\n## Related\n\n- `ccsync-isolated-run` skill — full procedure, multi-machine\n patterns, inspection commands, pitfalls.\n- `/ccsync-verify` — for automated verification; use that first,\n then `/ccsync-isolated` only for what tests can't cover.", "variables": [], "notes": "Spin up a sandboxed $HOME and a local bare git repo, build ccsync, and report the sandbox paths so you can manually drive the TUI without touching the real ~/.claude or any remote. Invoke when a TUI change needs visual verification. Tools: Bash, Read.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/colinc86/ccsync", "path": ".claude/commands/ccsync-isolated.md", "ref": "7f1b56f193b7ca35b379db0e6e1d04a7fca49591", "url": "https://github.com/colinc86/ccsync/blob/7f1b56f193b7ca35b379db0e6e1d04a7fca49591/.claude/commands/ccsync-isolated.md", "key": "colinc86/ccsync/.claude/commands/ccsync-isolated.md" } } }

ccsync-isolated

About

/ccsync-isolated

What to do

Optional: two-machine sandbox

Safety notes

Related

Install ccsync-isolated and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews