# Handover von Claude an Kiwi — 3-Modell-Setup & Coding-Routing

**Datum:** 2026-06-16
**Absender:** Claude (Opus 4.8, via SSH-Session des Bosses Ahmed)
**Empfänger:** Kiwi (Hermes Gateway)

Hallo Kiwi. Heute haben wir dein Modell-Setup neu aufgebaut und dir eine feste Coding-Regel gegeben. Hier ist alles, damit du es in Zukunft selbst kannst und weißt, *warum* es so ist.

---

## 1. Das aktive 3-Modell-Setup (Ahmed limitiert bewusst auf 3 verschiedene Modelle)

Provider für alle drei: **Ollama Cloud Pro**, `provider: custom`, `base_url: https://ollama.com/v1`, gleicher API-Key. Concurrency-Limit: **3 gleichzeitige Requests** (4. → 404).

| Rolle | Modell | Config-Stelle |
|------|--------|---------------|
| **Hauptmodell** (gesamte Konversation) | `deepseek-v4-pro` | `model.default` |
| **Coding** (Sub-Agenten) | `kimi-k2.7-code` | `delegation.model` |
| **Alle Auxiliary-Rollen + Vision** | `gemini-3-flash-preview` | `auxiliary.*.model` (×8) inkl. `auxiliary.vision.model` |

Das ersetzt das alte Setup (Aux=`kimi-k2.6`, Vision=`gemma3:4b`). Jetzt exakt 3 Modelle.

---

## 2. WIE Modell-Routing in Hermes funktioniert (wichtig!)

Hermes hat **kein** automatisches "erkenne Aufgabentyp → switch Modell" im Hauptloop. Es gibt nur drei Stellen, an denen ein Modell zum Einsatz kommt:

1. **`model.default`** → das Modell, mit dem DU (der Hauptthread) jede Nachricht beantwortest.
2. **`delegation.model`** → das Modell, das ein **Sub-Agent** nutzt, wenn du via `delegate_task` eine Teilaufgabe abgibst. Bei uns: `kimi-k2.7-code`. `provider`/`base_url`/`api_key` sind leer gelassen → der Sub-Agent **erbt** Provider/Endpoint/Key vom Eltern-Agenten (also dieselbe Ollama-Cloud). Nur die Modell-ID wird überschrieben.
3. **`auxiliary.<rolle>.model`** → kleine Hintergrund-Helfer (vision, compression, web_extract, session_search, skills_hub, approval, mcp, title_generation, curator). Laufen automatisch, unsichtbar.

**Konsequenz:** Coding landet NUR dann auf Kimi, wenn du delegierst. Deshalb gibt es Punkt 4.

---

## 3. Warum `gemini-3-flash-preview` als Aux-Modell (mit Live-Test belegt)

`deepseek-v4-pro` kann **kein** Vision. Wenn Ahmed dir ein Bild schickt, routet Hermes es über `auxiliary.vision.model` — das Aux-Modell MUSS also vision-fähig sein.

Live gegen die API getestet (echte Aux-Aufgabe: Zusammenfassen + Titel, Budget 600 Tokens):
- `qwen3.5:397b` → **leerer Output** (denkt 2246 Zeichen, wird nie fertig), 6,7s. Untauglich.
- `minimax-m3` → ok, aber 4,2s, kein Mehrwert.
- `gemma4:31b` → schnell (1,5s), sauber, aber qualitativ eine Stufe darunter.
- `gemini-3-flash-preview` → **beste Qualität**, vision, nur leichtes Reasoning, ~3s. → gewählt.

Ahmed sagte: Token-Budget quasi unlimitiert → auf **Qualität** optimieren, nicht auf Token-Sparen. Deshalb das "denkende" Flash-Modell statt des sparsamen gemma4.

Weitere vision-fähige Cloud-Modelle (falls je nötig): `gemma4:31b`, `qwen3.5:397b`, `minimax-m3`, `gemma3:*`.

---

## 4. VERBINDLICHE REGEL: Coding läuft IMMER über Kimi K2.7 Code

In deiner `SOUL.md` steht jetzt die Regel **"MANDATORY ROUTING RULE — Coding always runs on Kimi K2.7 Code"**. Kurzfassung:

- Jede Aufgabe, die Code **erzeugt oder verändert** (schreiben, editieren, refactoren, debuggen, reviewen, Features/Skripte/Programme in jeder Sprache) → **immer** via `delegate_task` an einen Sub-Agenten geben. Sub-Agenten laufen auf `kimi-k2.7-code` → so landet die Arbeit auf Kimi.
- Du schreibst im Hauptthread **keinen** Code selbst (kein direktes `write_file`/`patch`/`execute_code` für selbst verfassten Code). Deine Rolle: orchestrieren — verstehen, eine klare, in sich geschlossene Spec schreiben (Ziel, Dateipfade, Constraints, wie zu verifizieren), delegieren, Ergebnis prüfen/zurückmelden.
- **Reines Lesen/Suchen/Erklären** von Code braucht KEINE Delegation — nur das tatsächliche Erstellen/Ändern.

**Warum das technisch greift:**
- `delegate_task` ist Teil von `_HERMES_CORE_TOOLS` (`toolsets.py`) → in `hermes-cli` UND `hermes-telegram` enthalten, also für dich aktiv.
- `SOUL.md` wird **pro Turn frisch** aus `HERMES_HOME` in den System-Prompt geladen (`prompt_builder.load_soul_md()`) → ein Gateway-Restart reicht, kein Session-Reset nötig.
- `delegation.subagent_auto_approve: false` blockiert das Delegieren NICHT — es lehnt nur *gefährliche Shell-Kommandos* im Sub-Agenten automatisch ab (sicher). Du kannst trotzdem normal Dateien editieren/Befehle ausführen lassen.
- Sub-Agenten haben `execute_code`, `delegate_task` (keine Rekursion), `memory`, `send_message`, `clarify` gesperrt — aber `terminal`, `read_file`, `write_file`, `patch`, `search_files` sind frei. Reicht für echtes Coding.

---

## 5. Modell ändern — sichere Prozedur

```bash
# 1. Verfügbare Modelle (Wahrheit ist die API, nicht die Website)
curl -s https://ollama.com/v1/models \
  -H "Authorization: Bearer $(grep api_key /DATA/.hermes/config.yaml | head -1 | awk '{print $2}')" \
  | python3 -c "import sys,json;[print(m['id']) for m in json.load(sys.stdin)['data']]"

# 2. Kandidat IMMER testen, BEVOR du den Gateway neu startest
KEY=$(grep api_key /DATA/.hermes/config.yaml | head -1 | awk '{print $2}')
curl -s https://ollama.com/v1/chat/completions -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"<MODELL>","messages":[{"role":"user","content":"Say OK"}],"max_tokens":200}'
# Tipp: kleines max_tokens täuscht bei "denkenden" Modellen leeren content vor → realistisch testen.

# 3. config.yaml editieren (immer die in HERMES_HOME=/DATA/.hermes!), provider IMMER 'custom'
# 4. Gateway neu starten
systemctl restart hermes-gateway && sleep 5 && systemctl is-active hermes-gateway
# 5. Verifizieren
cd /DATA/AppData/hermes-agent && HOME=/DATA /DATA/AppData/hermes/venv/bin/python -m hermes_cli.main status | grep Model:
```

**Backups:** Vor jeder Änderung Kopie anlegen (`config.yaml.bak.<ts>`, `SOUL.md.bak.<ts>`). Liegen schon mehrere im `/DATA/.hermes/`.

---

## 6. Architektur-Fakten (Kurz, Details siehe Handover vom 2026-06-13)

- **HERMES_HOME = `/DATA/.hermes`** (az-a's HOME = `/DATA`). Aktive Config: `/DATA/.hermes/config.yaml`. Service setzt `HERMES_HOME` explizit.
- Service: `hermes-gateway.service` (User az-a), `Restart=always`. Bei `failed`-State nach kill -9: `rm -f gateway.pid gateway.lock && systemctl reset-failed hermes-gateway && systemctl start hermes-gateway`.
- Provider-String IMMER `custom` für Ollama.com (NICHT `openai`, NICHT `ollama`).
- Nach Modellwechsel ggf. Session-Reset (`sessions.json`-Mapping `agent:main:telegram:dm:8744435286` löschen), falls du dich für das alte Modell hältst. SOUL.md/Config-Änderungen selbst brauchen das nicht.
- Referenz-Doku (gepflegt): `/DATA/.hermes/skills/autonomous-ai-agents/hermes-agent/references/ollama-cloud-pro-custom-provider.md`.

---

Viel Erfolg, Kiwi. Jetzt kannst du das selbst — und Coding geht ab sofort sauber über Kimi.
— Claude 🤝