knowledge-base/wiki/architecture/model-routing.md

---
created: 2026-06-16
updated: 2026-06-16
sources: [other/2026-06-16_openclaw-releases-v2026.6.8.md]
tags: [architecture, model-routing, llm, openclaw]
---

# Model Routing

> Migriert aus ByteRover context-tree (April 2026)

## Two-Model-Pipeline

Für mehrstufige Aufgaben: **Grok 4.20 → Gemini 2.5 Flash**

| Phase | Modell | Stärke |
|-------|--------|--------|
| Ideation | Grok 4.20 | Kreative Exploration, Brainstorming, divergentes Denken |
| Synthesis | Gemini 2.5 Flash | Strukturierte Ausgabe, schnelle Synthese, konvergent |

Dieses Pattern wird sowohl im allgemeinen Routing als auch im Subconscious Agent (Hard Synthesis) verwendet, aber nie als Shared Primitive formalisiert.

## GPT-5.4 Konfiguration

- **Alias:** `GPT-5.4`
- **Route:** `openrouter/openai/gpt-5.4`
- **Context:** 200k Tokens
- **Output:** 32k Tokens
- **Reasoning/Thinking:** ❌ Deaktiviert (per Claire Vo-Empfehlung)

## Fallback-Chain (Hector Primary)

```
openrouter/auto
  → zai/glm-5-turbo
    → moonshot/moonshot-v1-auto
      → moonshot/kimi-k2.5
        → ollama/minimax-m2.7
```

**Hinweis (Stand 2026-06-16):** Wir sind gerade dabei, die Fallback-Chain
auf **`ollama/glm-5.1` als Primary + `ollama/minimax-m3` als Fallback**
umzustellen. Details unten in "Update 2026-06-16: OpenClaw v2026.6.8".

## Update 2026-06-16: OpenClaw v2026.6.8 GLM-5.2-Support + Provider-Prefix-Normalisierung

Mit dem Release [v2026.6.8](https://github.com/openclaw/openclaw/releases/tag/v2026.6.8)
(16.06.2026) hat OpenClaw **drei für uns routing-relevante Änderungen** gebracht:

1. **GLM-5.2 ist offiziell im Provider-Catalog** — vorher nur über Z.ai Coding
   Plan verfügbar, jetzt nativ in OpenClaw routeable. Siehe
   [[../concepts/llm/glm-5.2-zai-coding-model.md]].
2. **Provider-Prefix-Normalisierung** für OpenRouter und Google Vertex Pfade:
   `openrouter/anthropic/claude-3.5-sonnet` wird intern zu bare IDs
   normalisiert wo Runtimes das brauchen.
3. **OAuth image-default routing durch Codex** für eligible OpenAI profiles —
   relevant für Generated-Media-Workflows (image_generate, music_generate).

**Konkrete Implikation für unsere aktuelle Konfiguration:**

| Setting | Status | Aktion |
|---|---|---|
| `ollama/minimax-m3` (Primary, lokal) | ✅ Unverändert | keine |
| `ollama/glm-5.1` (geplant als neuer Primary) | ⚠️ Migration offen | siehe unten |
| `openrouter/auto` (Fallback) | ✅ Unverändert | keine — Prefix-Norm ist transparent |
| GLM-5.2 als Sub-Route | 🆕 Option | nach v2026.6.8-Update evaluieren |

**Aktueller Routing-Plan nach v2026.6.8-Migration:**

```
Primary:   ollama/glm-5.1
Fallback:  ollama/minimax-m3
Optional (nach Evaluation):
  - openrouter/anthropic/claude-sonnet-4.5  (Haiku 4.5 catalog row in v2026.6.8)
  - zai/glm-5.2  (Long-Context, 1M)
  - moonshot/kimi-k2.7-code  (Coding, agentic)
```

Vollständige Plattform-Doku: [[../tools/openclaw.md]].

## Verwandt: Parallele Ensembles (Fusion)

Sequentielles Routing (Fallback) ist nicht das einzige Pattern. OpenRouter bietet **Fusion** — parallele Model-Panels mit Judge-Synthese. Siehe [[../concepts/llm/llm-model-fusion-ensembles.md]] für Details und DRACO-Benchmark-Ergebnisse.

**Aktuell offene Frage:** Soll OpenClaws Quality-kritische Pfade (z.B. Subconscious Hard Synthesis) um eine parallele Pre-Routing-Schicht erweitert werden? Trade-off: höhere Latenz + Kosten vs. bessere Qualität durch Modell-Heterogenität.

## Coding-Modelle: Kimi K2.7 & GLM-5.2

Im Juni 2026 haben sich zwei starke Open-Source-Coding-Modelle aus China etabliert:

- **Kimi K2.7** (Moonshot AI) — siehe [[../tools/kimi-k2.7-code.md]]. MoE 1T/32B, 256K Kontext, schnell im Real-Coding-Showdown.
- **GLM-5.2** (Zhipu AI / Z.ai) — 744B Dense, 1M Kontext, MIT-Lizenz, stark bei kreativer Generation und Animation.

Head-to-Head-Vergleich in Hermes Agent: siehe [[../concepts/llm/real-world-coding-showdown.md]].

**Implikation für Routing:** In Sub-Task-Spezialisierung (Coding vs. Creative vs. Long-Context) sind beide als Sub-Routing-Knoten sinnvoll — nicht als Ersatz der Primary-Fallback-Chain, sondern als **spezialisierte Side-Branches** für Coding-Tasks.

### GLM 5.2 (Z.ai) — 1M Kontext, MIT-Lizenz, 10x günstiger

Zusätzlich zu Kimi K2.7 ist **GLM 5.2** (Release 13.06.2026) ein zweiter chinesischer Frontier-Coding-Kandidat. Siehe [[../concepts/llm/glm-5.2-zai-coding-model.md]] für Details.

**Update 2026-06-16:** Mit OpenClaw v2026.6.8 ist GLM 5.2 **nativ in OpenClaw
als Provider-Adapter verfügbar** — vorher war der Zugang auf den Z.ai Coding
Plan beschränkt (siehe [[../concepts/llm/glm-5.2-zai-coding-model.md]]). Damit
wird die "Warten auf OpenRouter-Listing"-Option (siehe unten) gegenstandslos.

**Empfohlene Routing-Position:**

```
OpenClaw Primary Routing
  ├─ Creative / Long-Context (1M)  → GLM 5.2 (via OpenClaw provider-adapter)
  ├─ Speed / Innovation Coding     → Kimi K2.7 Code (added in v2026.6.7-beta.1)
  ├─ Standard Tasks                → openrouter/auto → ollama/minimax-m3
  └─ Frontier Quality              → Claude Opus 4.8 / Fable
```

**Drei Setup-Optionen** (Stand 16.06.2026 — Update nach OpenClaw v2026.6.8):
1. **OpenClaw Provider-Adapter** (NEU seit v2026.6.8) — nativ in OpenClaw als
   Provider routeable, keine externe Subscription nötig. **Empfohlener Pfad.**
2. **Z.ai Coding Plan** (parallel verfügbar, ab 18 USD/Monat) — via
   `npx @z_ai/coding-helper`. **Achtung:** Light-Plan hat in Stoßzeiten 2-3×
   Kontingent-Verbrauch und lange Wartezeiten.
3. **Self-Hosting** (nach Open Weights Release nächste Woche) — MIT-Lizenz,
   Self-Host via [HuggingFace](https://huggingface.co/zai-org/GLM-5).
4. ~~**Warten** auf OpenRouter-Listing~~ — **obsolet**, OpenClaw hat's
   nativ, und OpenRouter-Listing erfolgt unabhängig.

**Ensemble-Kandidat:** GLM 5.2 + Kimi K2.7 als heterogenes Coding-Panel in [[../concepts/llm/llm-model-fusion-ensembles.md]] (unterschiedliche Architektur: Dense vs MoE, unterschiedliche Stärken).

**Besonderheit:** [Z.ai Coding Plan](https://z.ai/subscribe) listet `Clawdbot/OpenClaw` namentlich als unterstütztes Environment — direkte Integration bereits vorbereitet.

## Post-Transformer-Architekturen als künftige Routing-Optionen

Während aktuelles Routing primär **innerhalb** des AR-Transformer-Stacks arbeitet (mit Modell-Heterogenität als Variations-Achse), verschiebt DeepMind die Variations-Achse **architektonisch**: hybride Attention+Recurrence (Griffin, Recurrent Gemma, Titans), Diffusions-LLMs, JEPA-Weltmodelle. Details: [[../concepts/llm/post-transformer-llm-architectures.md]].

**Aktuell noch nicht relevant für OpenClaw-Routing** (keine offenen Weights + stabile Provider-Listings), aber mittelfristig zu beobachten:
- **State-Space-Hybride** (Titans, Mamba) als effizientere lokale Embedding-Backends für SSR/Speicher-Layer
- **Diffusions-LLMs** für parallele Code-Completion in nicht-Präfix-Positionen (relevant für Hermes-Agent-Code-Edit-Tasks)
- **JEPA-Weltmodelle** für Subconscious-Agent-„Simulations-Prior" (statt nur Text-Pretraining-Prior)

**Status:** Beobachten, nicht adoptieren. Sobald OpenRouter oder ein anderer Provider-Adapter stabile Listings anbietet, evaluieren wie bei [[../concepts/llm/glm-5.2-zai-coding-model.md]].

## Hardware-Frontier als Routing-Constraint

Mainzers Energie-Argument (20W Gehirn vs. Megawatt-LLM-Cluster, siehe [[../concepts/hardware/neuromorphic-chips-und-quantencomputer.md]]) validiert [[../concepts/llm/ai-value-migration-orchestration.md]] (Aravind: „Token Value per Watt per User"). Implikation für OpenClaw-Routing:

- **Edge-Tasks** (Smart-Home, Mobile, Embedded): langfristig nur mit neuromorphen/photonischen Backends wirtschaftlich — nicht mit Cloud-LLMs
- **Mittelfristig beobachten:** Intel Loihi, IBM TrueNorth, Lightmatter, Luminous Computing — Status 2026?
- **Kurzfristig:** Optimierung bestehender AR-Transformer-Pfade (Caching, Quantisierung, Speculative Decoding) bleibt wichtig, ist aber Endpunkt-Frickelei — Hardware-Diversität ist der eigentliche Spielfeldwechsel.