Jev Ultrafast MCP : un navigateur autonome pour Claude Code
🇬🇧ENJev Ultrafast MCP remplace 20 appels navigateur par un seul browser_goal. 10x moins de tokens, 10x moins cher que Claude in Chrome. Setup complet avec benchmarks.
J’utilise Claude Code avec deux serveurs MCP pour le navigateur : Claude in Chrome et Jev Ultrafast MCP. Les deux permettent à Claude de piloter un navigateur, mais l’approche est radicalement différente. Claude in Chrome envoie chaque clic et chaque frappe comme un appel d’outil séparé, chacun injecte des tokens dans le contexte. Jev fait l’inverse : Claude envoie un objectif en langage naturel, Jev pilote le navigateur côté serveur, et Claude ne reçoit que le résultat.
Le gain mesuré sur une tâche réelle : 10x moins de tokens Claude et un coût divisé par 10 à 40.
Le problème avec le pilotage clic par clic
Quand Claude Code utilise Claude in Chrome ou un outil de computer use classique, chaque interaction avec le navigateur suit le même schéma :
- Claude lit la page (screenshot ou DOM) - injection de tokens
- Claude décide quoi cliquer - génération de tokens
- L’outil exécute le clic
- Claude relit la page pour vérifier - injection de tokens
- Répéter pour chaque action
Une recherche de vol sur Google Flights nécessite environ 15 à 20 allers-retours. Chaque aller-retour injecte le contenu de la page dans le contexte de Claude. Sur Opus, ça représente facilement 100 000 à 150 000 tokens pour une tâche qui prend 45 secondes.
Le contexte se remplit vite. Sur une session avec plusieurs tâches navigateur, on atteint la compaction bien avant d’avoir fini le travail.
Comment Jev change l’approche
Jev Ultrafast MCP inverse la boucle de décision. Au lieu que Claude décide chaque clic, Claude envoie un seul objectif via browser_goal :
browser_goal(
goal="Rechercher un vol Paris CDG vers Barcelone, aller simple, le 15 octobre",
url="https://www.google.com/travel/flights",
verify=["résultats de vols affichés", "prix visibles"]
)Le serveur MCP prend le relais. Jev utilise un modèle de décision spécialisé (TypeSafe System One) qui choisit chaque action — clic, saisie de texte, scroll — en environ 300 millisecondes. Un micro-LLM (inception/mercury-2.5) génère le texte quand il faut taper quelque chose. La page ne transite jamais par le contexte de Claude.
Claude reçoit un résultat structuré : la tâche est terminée, les critères de vérification sont passés, voici les données extraites. Un seul appel d’outil, quelques milliers de tokens.
Benchmarks
J’ai mesuré la différence sur une tâche concrète : recherche de vol sur Google Flights (Paris CDG vers Barcelone, aller simple).
| Métrique | Jev (turbo) | Jev (fallback manuel) | Claude in Chrome |
|---|---|---|---|
| Appels MCP | 1 | ~20 | ~15-20 |
| Tokens Claude | ~5 000 | ~45 000 | ~100-150 000 |
| Contexte consommé | 4% | 8% | ~15-25% |
| Temps | 42s | 1m40 | ~45s |
Quand browser_goal réussit en mode turbo (cas nominal), le gain est massif : 10x moins de tokens, coût divisé par 10 à 40. Quand il échoue (modale bloquante, captcha), Claude passe en pilotage manuel via browser_act et browser_observe. Le gain se réduit à 2-3x, mais ça reste largement en dessous de Claude in Chrome.
Les benchmarks du projet Jev sur 3 tâches de formulaire confirment l’écart de coût :
| Modèle | Coût total | Temps | Ratio |
|---|---|---|---|
| Jev | $0.006 | 17.8s | 1x |
| Claude Sonnet 5 | $0.25 | 43.3s | 44x |
| Claude Opus 5 | $0.80 | 45.4s | 140x |
Le modèle de décision de Jev coûte environ $0.01 par jour en utilisation courante. Le mode macro permet de rejouer des tâches déjà effectuées sans aucun appel modèle.
Installation et configuration
Prérequis
- Python 3.10 ou supérieur
- Une clé API pour le modèle de décision Jev : OpenRouter, TypeSafe AI, ou tout autre provider compatible
- Un navigateur Chromium : Chrome, Brave, Edge, Chromium, Arc, ou tout navigateur basé sur Chromium
Cloner et installer
git clone https://github.com/jiawei686/jev-ultrafast-mcp.git
cd jev-ultrafast-mcp
python3 -m venv .venv
.venv/bin/pip install -e .Ajouter le MCP à Claude Code
claude mcp add --scope user jev-ultrafast-mcp \
-- /chemin/absolu/.venv/bin/python -m jev_ultrafast_mcpLe serveur MCP lit ses variables d’environnement depuis os.environ, pas depuis un fichier .env. Il faut les déclarer dans le bloc env du serveur MCP dans ~/.claude.json :
{
"mcpServers": {
"jev-ultrafast-mcp": {
"type": "stdio",
"command": "/chemin/.venv/bin/python",
"args": ["-m", "jev_ultrafast_mcp"],
"env": {
"TYPESAFE_API_KEY": "<clé-api>",
"TYPESAFE_BASE_URL": "https://openrouter.ai/api/alpha/decisions",
"TYPESAFE_MODEL": "jev-latest",
"TEXT_MODEL_API_KEY": "<clé-api>",
"TEXT_MODEL_BASE_URL": "https://openrouter.ai/api/v1",
"TEXT_MODEL": "inception/mercury-2.5",
"JEVMCP_CHROME": "/Applications/Brave Browser.app/Contents/MacOS/Brave Browser",
"JEVMCP_MODE": "attach",
"JEVMCP_CDP_URL": "http://127.0.0.1:9224",
"JEVMCP_HEADLESS": "0",
"JEVMCP_ALLOW_JS": "1"
}
}
}
}Comprendre JEVMCP_CHROME et JEVMCP_CDP_URL
JEVMCP_CHROME pointe vers l’exécutable du navigateur Chromium que Jev va utiliser. Ce choix a deux conséquences directes :
- Le navigateur piloté : Jev utilise le protocole CDP (Chrome DevTools Protocol) pour envoyer ses actions. N’importe quel navigateur basé sur Chromium supporte CDP : Chrome, Brave, Edge, Arc, Chromium.
- Le profil utilisateur : en mode
attach, Jev se connecte au navigateur déjà ouvert avec le profil de l’utilisateur. Les cookies, les sessions connectées, les extensions sont disponibles. Jev peut interagir avec des sites où l’utilisateur est déjà authentifié sans avoir à gérer de credentials.
Exemples de chemins selon le navigateur sur macOS :
# Brave
JEVMCP_CHROME="/Applications/Brave Browser.app/Contents/MacOS/Brave Browser"
# Chrome
JEVMCP_CHROME="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
# Edge
JEVMCP_CHROME="/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge"
# Chromium
JEVMCP_CHROME="/Applications/Chromium.app/Contents/MacOS/Chromium"JEVMCP_CDP_URL indique à Jev où se connecter au port de debugging distant du navigateur. Le port par défaut de Chrome est 9222, mais si Chrome et Brave tournent sur la même machine, ils ne peuvent pas partager le même port. J’utilise 9224 pour Brave afin d’éviter le conflit :
# Brave sur le port 9224 (évite le conflit avec Chrome 9222)
open -a "Brave Browser" --args --remote-debugging-port=9224
# JEVMCP_CDP_URL doit correspondre au port choisi
JEVMCP_CDP_URL="http://127.0.0.1:9224"Si le port ne correspond pas, Jev ne trouve pas le navigateur et tombe en mode launch (qui échoue si le navigateur tourne déjà).
Lancer le navigateur avec le remote debugging
Pour que Jev se connecte à un navigateur existant (mode attach), le navigateur doit démarrer avec le port de debugging :
open -a "Brave Browser" --args --remote-debugging-port=9224Le profil existant est conservé : cookies, sessions, extensions restent disponibles.
Pour rendre ça permanent, ajouter dans ~/.zshrc :
alias brave='open -a "Brave Browser" --args --remote-debugging-port=9224'Les variables clés
| Variable | Valeur | Rôle |
|---|---|---|
JEVMCP_CHROME | Chemin binaire | Exécutable du navigateur Chromium à utiliser (Brave, Chrome, Edge…) |
JEVMCP_CDP_URL | http://127.0.0.1:9224 | Port de debugging distant, doit correspondre au --remote-debugging-port |
JEVMCP_MODE | attach | Se connecte au navigateur existant avec le profil utilisateur |
JEVMCP_HEADLESS | 0 | Navigateur visible (voir les actions en direct) |
JEVMCP_ALLOW_JS | 1 | Autorise Jev à exécuter du JS (fermer les modales cookies) |
TYPESAFE_BASE_URL | .../api/alpha/decisions | Endpoint décisions (pas /api/v1) |
Les pièges à éviter
Profil verrouillé. Si le navigateur tourne déjà, le mode launch échoue à cause du SingletonLock. Utiliser le mode attach avec --remote-debugging-port.
ALLOW_JS à 0. Sans JavaScript, Jev ne peut pas fermer les bannières de cookies. Le browser_goal échoue et Claude bascule en pilotage manuel, ce qui consomme beaucoup plus de tokens.
Les variables dans un .env. Le serveur MCP ne lit pas de fichier .env. Les variables doivent être dans le bloc env de ~/.claude.json, sinon le serveur démarre sans configuration.
Le mauvais endpoint pour le modèle de décision. Pour le modèle Jev, utiliser https://openrouter.ai/api/alpha/decisions (le endpoint décisions), pas /api/v1 (le endpoint chat standard). Avec TypeSafe AI directement, l’URL est différente — consulter leur documentation.
Port CDP qui ne correspond pas. Si JEVMCP_CDP_URL pointe vers un port différent de celui du --remote-debugging-port du navigateur, Jev ne le trouve pas et tente un launch qui échoue.
Les outils exposés
Jev expose 10 outils à Claude, mais en pratique deux suffisent pour la plupart des tâches :
| Outil | Usage |
|---|---|
browser_goal | Déléguer une tâche complète en un appel (mode turbo) |
browser_open | Ouvrir une URL et récupérer la table d’éléments |
browser_act | Exécuter un batch d’actions (fallback quand turbo échoue) |
browser_observe | Relire la page (delta seulement, pas le DOM complet) |
browser_assert | Vérifier un état par code, pas par opinion du LLM |
browser_macro | Rejouer un flow enregistré sans aucun coût modèle |
Le mode browser_macro est sous-estimé. Une fois qu’une tâche a réussi, Jev enregistre le flow. La prochaine exécution du même flow coûte zéro token, zéro appel API. Pour les tâches répétitives (vérifier un déploiement, checker un dashboard), c’est du gratuit.
Quand utiliser Jev, quand garder Claude in Chrome
Jev excelle pour les tâches web bien définies : remplir un formulaire, chercher un vol, scraper des données structurées, soumettre un rapport. Tout ce qui se résume à “va sur cette page et fais ça”.
Claude in Chrome reste nécessaire pour l’exploration ouverte (“regarde cette page et dis-moi ce que tu en penses”), le debug frontend (console, network requests), et l’analyse visuelle du contenu d’une page. Jev ne fait pas d’analyse visuelle — il refuse les captchas et ne sait pas interpréter un screenshot.
En pratique, j’utilise les deux. Jev pour les tâches automatisables, Claude in Chrome pour le debug et l’exploration. Le choix se fait naturellement : si je peux écrire un objectif en une phrase, c’est pour Jev. Si je dois regarder et comprendre, c’est pour Claude in Chrome.
Le serveur MCP est disponible sur GitHub. Il s’intègre avec Claude Code, Claude Desktop, Cursor, VS Code, Codex CLI et d’autres agents compatibles MCP. Pour optimiser aussi les tokens des autres serveurs MCP, voir MCP RTK. Et pour le setup complet de Claude Code incluant Jev : mon setup Claude Code en 2026.