# local-llm

Deux façons de faire travailler un LLM local (Qwen3.6-35B-A3B-AWQ servi par vLLM sur
une Jetson AGX Orin) à la place de Claude, pour les sous-tâches mécaniques ou
volumineuses.

| Fichier | Rôle |
|---|---|
| `server.py` | Serveur MCP exposant l'outil `ask_local_llm` — Claude écrit le prompt lui-même |
| `delegate.py` | CLI qui **lit les fichiers elle-même** — rien du contenu ne transite par le contexte de Claude |

La distinction compte : passer par l'outil MCP oblige Claude à recopier le contenu dans
l'argument `prompt`, ce qui coûte plus cher en tokens de sortie que de ne rien déléguer.
`delegate.py` évite ça — Claude ne voit que le résultat.

## Installation

```bash
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
```

## delegate.py

```bash
.venv/bin/python delegate.py --file '<fichier_ou_glob>' --task "<instruction>" [--out <sortie>]
```

`--file` est répétable et accepte les globs. Options : `--system`, `--max-tokens`
(2048), `--temperature` (0.3), `--think` (raisonnement interne, plus lent), `--out`.

## server.py (MCP)

Déclaration dans `.mcp.json` :

```json
{
  "mcpServers": {
    "local-llm": {
      "command": "/chemin/vers/.venv/bin/python",
      "args": ["/chemin/vers/server.py"],
      "env": {
        "VLLM_URL": "http://localhost:8000/v1/chat/completions",
        "VLLM_MODEL": "cyankiwi/Qwen3.6-35B-A3B-AWQ-4bit"
      }
    }
  }
}
```

## Configuration

Tout passe par l'environnement, rien n'est codé en dur :

- `VLLM_URL` — défaut `http://localhost:8000/v1/chat/completions`
- `VLLM_MODEL` — défaut `cyankiwi/Qwen3.6-35B-A3B-AWQ-4bit`

Timeout des requêtes : 900 s (génération longue sur Jetson).

## Bon à savoir

Le modèle local est plus petit et moins fiable : ses sorties sont des brouillons à
relire, pas des vérités. À éviter pour les décisions d'architecture et le code
sensible (sécurité, auth, paiement).

Testé avec Python 3.10, `httpx` 0.28.1, `mcp` 1.9.4.