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

created	updated	sources	tags
2026-06-16	2026-06-16	other/2026-06-16_openclaw-releases-v2026.6.8.md	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 (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 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 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 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 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.
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 llm-model-fusion-ensembles.md (unterschiedliche Architektur: Dense vs MoE, unterschiedliche Stärken).

Besonderheit: Z.ai Coding Plan 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) validiert concepts/llm/ai-value-migration-orchestration (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.