ccproxy (starbased-co)

L'idée est intelligente : garder le harness Claude Code intact, mais rerouter certaines requêtes vers d'autres LLMs sur des règles (token count, tool used, model name, thinking mode). Pour notre stack, ça ouvrirait la porte à Gemini 2M tokens sur les gros codebases ou Perplexity sur les WebSearch. Architecture solide en façade — d'où le test.

• Snapshot baseline : md5 de ~/.claude/CLAUDE.md, settings.json, listing ~/.claude/plugins/.
• Cross-registry inspect : npm ccproxy v0.1.0 est un package distinct/orphelin — le vrai outil est sur PyPI sous claude-ccproxy v1.2.0.
• Lecture README + PyPI metadata : license réelle AGPL-3.0-or-later (gh affichait "Other"), Python ≥3.11 requis, uv recommandé.
• Vérification toolchain locale : uv non installé. Bootstrap nécessaire avant même de tenter ccproxy install.
• Install NON-effectuée : 3 gating factors cumulés ont fait avorter à l'étape 4 (cf panneau Verdict).

Même sans installer, l'analyse de surface a produit 6 patterns réutilisables pour les prochains test benches :

1. 01

   Proxy externe ≠ plugin Claude Code

   ccproxy ne s'enregistre pas comme marketplace plugin. Il vit dans `~/.ccproxy/` (sa propre dir) et intercepte au niveau réseau via `ANTHROPIC_BASE_URL=http://localhost:4000`. Modèle d'invasion radicalement différent de claude-mem ou Ruflo : pas de pollution `~/.claude/`, mais runtime continu (proxy server détaché). Trade-off : footprint propre côté config, mais process additionnel en mémoire.

2. 02

   npm `ccproxy` ≠ PyPI `claude-ccproxy`

   Le vrai outil est sur PyPI sous `claude-ccproxy`. Le package npm `ccproxy` v0.1.0 est un projet distinct/orphelin. Une recherche naïve `npm install ccproxy` ne donne PAS le bon outil. Pattern à reconnaître : namespace squat / cross-registry confusion. Toujours croiser PyPI ↔ npm ↔ GitHub avant d'installer.

3. 03

   `uv` est le nouveau standard Python

   Le README recommande `uv tool install` au lieu de `pip install`. `uv` est un installateur Python rust-based qui gère venv isolés (l'équivalent npm pour Python). Bootstrap : `curl https://astral.sh/uv/install.sh | sh`. Friction si pas déjà installé — exactement comme Bun pour claude-mem. Pattern : un outil dans un écosystème (Python) requis pour évaluer un outil ciblant un autre écosystème (Claude Code).

4. 04

   AGPL-3.0-or-later : à flagger explicitement

   PyPI metadata = AGPL-3.0-or-later. Github API renvoyait juste "Other" (non-classifié), ce qui masque la nature copyleft réseau. Pour usage perso CLI c'est OK. Pour redistribution, intégration dans un produit commercial, ou même usage SaaS : la licence impose ouverture du code. À identifier au step Inspect avant de continuer.

5. 05

   Value-gating par API keys = quick eval impossible

   ccproxy ne fait rien d'utile sans clés OpenAI/Gemini/Perplexity. Le "hello world" de la value proposition (router une requête vers Gemini) requiert un compte payant chez un autre provider. Le skill `/test-tool` exclut ce cas dans "When NOT to use". Pattern : un outil free-to-install peut être paid-to-evaluate. Détecter ça au step Inspect, pas en plein milieu d'un test.

6. 06

   v2.0 dev branch : signal de scope creep

   Le README annonce une v2.0 prerelease : "jails your process in a rootless WireGuard namespace, intercepts at the network layer with full TLS inspection, DAG-driven hook pipeline". C'est un changement architectural massif sur 6 mois — le genre de réécriture qui fragmente la communauté et bloque les adoptions. Heuristique : quand un outil OSS récent (créé 2025) annonce une v2 ground-up rewrite, attendre que la nouvelle ligne soit stabilisée AVANT d'investir dessus.

Conditions de re-évaluation pour une future adoption :

• ✓ Cas d'usage concret apparaît : router vers Gemini 2M sur gros codebases OU vers Perplexity sur WebSearch
• ✓ Budget API keys multi-providers débloqué
• ✓ Commande ccproxy uninstall documentée
• ✓ Flag --dry-run sur ccproxy install
• ✓ v2.0 stable releasée OU ligne v1.x continue de stabiliser sans la branche WireGuard