Hector a95e76d3ef ingest(youtube): jonas-keil-hermes-desktop

- raw: YouTube video 'Hermes DESKTOP ist der WAHNSINN!!' (Jonas Keil, 22:23, ~24K views)
- wiki: tools/hermes-desktop.md — full feature page (Electron/React/Python, OpenClaw migration, Hermes vs OpenClaw comparison)
- Updated: real-world-coding-showdown.md, ecosystem-tools-april-2026.md, index.md, log.md

2026-06-22 13:34:01 +02:00

9.4 KiB

Raw Blame History

created

updated

sources

Real-World Coding-Agent Showdowns — Methodik jenseits von Standard-Benchmarks

Quelle des Konzepts: YouTube-Video "Kimi K2.7 vs GLM-5.2: Real Coding Showdown in Hermes Agent" (Fahd Mirza, 14.06.2026, 14 Min, 2659 Aufrufe, 89 Likes). Geteilt von @PWeber (Kai) in OME-Gruppe "News & Infos (X/YT/Substack etc.)"-Topic.

Kernidee

Statt statischer Code-Benchmarks (HumanEval, MBPP, SWE-bench) → head-to-head-Vergleich zweier Modelle in derselben Agent-Umgebung, mit echtem Bug + Feature-Anforderung in einer nicht-trivialen App.

Das Video von Fahd Mirza demonstriert eine alternative Evaluationsmethode für Coding-Modelle: Beide Modelle erhalten denselben Prompt in derselben Hermes Agent-Instanz, lösen denselben realistischen Task (Bug-Fix + Feature-Build in einer Flask-App), und werden anhand konkreter Output-Qualität, Zeit und Tool-Call-Effizienz verglichen.

Die Methodik

Setup

Element	Details
Test-App	Flask-Webanwendung (World Cup 2026 Tracker), DB + CRUD, "hundreds of files"
Gepflanzter Bug	Round-of-32-Ranking der besten Drittplatzierten ignoriert Goal Difference — verstößt gegen FIFA-Regel
Feature-Anforderung	Round-of-32-Bracket: 16 Matchups, Group-Winner auf starker Seite, kein Team spielt gegen einen aus seiner eigenen Gruppe
Test-Framework	Hermes Agent von Nous Research (selber Agent für beide Modelle)
Hardware	Ubuntu-System, beide Modelle als Inference-Backends
Prompt	Identisch für beide Modelle, One-Shot mit echtem Use-Case
Bewertungsdimensionen	Korrektheit, Vollständigkeit, Zeit, Tool-Call-Anzahl, Innovation

Bewertung — Kriterien-Katalog (extrapoliert)

Bug-Fix Korrektheit — wird der FIFA-Regel-konforme Goal-Difference-Fix korrekt umgesetzt?
Feature-Vollständigkeit — funktioniert das Round-of-32-Bracket mit allen 16 Matchups?
Constraint-Satisfaction — Anti-Group-Rematch-Regel eingehalten?
Tool-Call-Effizienz — wie viele Tool-Calls für die Lösung?
Zeit-Effizienz — Inferenz-Zeit für die Gesamtaufgabe?
Innovation — Eigeninitiative über die Anforderung hinaus (z.B. zusätzliche UI-Features)
Kreativität (zweiter Test) — Fähigkeit zu Single-File-Creative-Coding mit Animation, Geographie, Live-Stats

Ergebnisse (Video)

Test 1: Real Coding (Bug-Fix + Feature)

Kriterium	Kimi K2.7	GLM-5.2
Bug-Fix korrekt	✅	✅
Bracket-Feature	✅	✅
Anti-Group-Rematch	✅	✅
Tool-Calls	mehr	97
Zeit	~5 Min	länger
Innovation	+ (z.B. Progression-Previews)	–

Fazit Test 1: Beide bestehen, Kimi vorn durch Geschwindigkeit + Innovation.

Test 2: Creative HTML (Siberian Wind Simulation)

Kriterium	Kimi K2.7	GLM-5.2
Geographie korrekt	✅	✅
Live-Stats (Wind, City)	✅	✅
Animation sichtbar	⚠️ sehr schwach	✅
Terrain-Detail	❌ "plain"	✅ sichtbar

Fazit Test 2: GLM vorn bei kreativer Animation + Detail.

Gesamtfazit Mirza: "Both models are neck to neck. Test on your own use case." (Subjektivität anerkannt.)

Warum diese Methodik wertvoll ist

1. Statische Benchmarks haben Grenzen

Standard-Coding-Benchmarks messen eng definierte Code-Generierung (Funktion schreiben, Bug fixieren). Real-World-Coding-Agents brauchen mehr:

Multi-File-Reasoning über hunderte Dateien
Tool-Use (Shell, Browser, DB, Git)
Constraint-Satisfaction mit nicht-offensichtlichen Regeln
Eigeninitiative (User will "Bracket", aber gute Lösung antizipiert Edge-Cases)
Kombiniertes Bug-Fix + Feature-Build in einem Shot

Der Hermes-Showdown testet all das implizit — ohne explizit dafür designte Benchmarks.

2. Agent-Framework isolieren

Indem beide Modelle im selben Agent-Framework laufen (Hermes Agent), wird die Modell-Variable sauber isoliert. Der Vergleich misst: Was kann das Modell XY in einem realen Agent-Workflow? — nicht: Was kann Agent A vs Agent B?

→ Direkter Implikat für OpenClaw: Eine vergleichbare Showdown-Methodik mit concepts/agents/ai-agents-2026.md-Setups würde zeigen, welches Modell für welchen Sub-Task im OpenClaw-Setup am besten passt.

3. Open-Source-Realität 2026

Sowohl Kimi K2.7 (Moonshot AI) als auch GLM-5.2 (Zhipu AI) sind konkurrenzfähige Open-Source-Coding-Modelle mit unterschiedlichen Trade-offs:

Dimension	Kimi K2.7	GLM-5.2
Architektur	MoE (1T total, 32B active)	Dense (744B)
Kontext	256K	1M
Lizenz	Open	MIT
Stärke (Test 1)	Speed, Innovation	Konsistenz
Stärke (Test 2)	Stats, Geographie	Animation, Detail

→ Direkter Implikat für concepts/llm/llm-model-fusion-ensembles.md: In der OpenRouter-Fusion-Demo war Kimi K2.6 im Budget-Panel. Kimi K2.7 ist die nächste Generation und GLM-5.2 ein weiterer Kandidat. Beide könnten in heterogenen Coding-Panels Synergieeffekte erzeugen.

4. Sub-Task-Spezialisierung als Schlüssel

Statt "ein Modell für alles" zeigt der Showdown: Beide Modelle sind kompetent, aber in verschiedenen Dimensionen stark. Praktisch heißt das: in einer Ensemble-Architektur (Fusion) sollte man nicht nur diverse Modelle kombinieren, sondern auch Sub-Task-spezifisch zuweisen.

Pro-Leben-Perspektive

Gemäß concepts/directives/pro-leben-directive.md:

Gegen Mangelnarrativ ("Wir sind abhängig von US-Frontier-Modellen"):

2026 ist das Jahr, in dem chinesische Open-Source-Coding-Modelle Frontier-Nähe erreicht haben — Kimi K2.7, GLM-5.2, DeepSeek-Varianten
MIT-Lizenz für GLM-5.2 (Open Weights) ist ein handfester Schritt Richtung echter Offenheit
Konkurrenz belebt das Feld — beide Modelle sind besser als eines allein

Für Handlungsfähigkeit:

Wer Coding-Agents baut, kann heute zwischen mehreren starken Open-Source-Modellen wählen
Hermes Agent ist Open Source (concepts/agents/ai-agents-2026.md-Pattern)
Real-World-Tests sind machbar: App mit Bug + Feature bauen, beide Modelle dranlassen, vergleichen

Realismus:

Beide Modelle haben eigene Schwächen (Kimi bei Animation, GLM bei Innovation)
1M Kontext (GLM) ist nicht immer nützlich — oft sind 256K (Kimi) praxisnäher
"Neck to neck" = beide gut genug für Production, aber nicht perfekt
Standard-Benchmarks (Kimi Code Bench v2, Program Bench) bleiben als erste Approximation sinnvoll — Real-World-Tests ergänzen, ersetzen aber nicht

Externe Ressourcen

Video & Autor

9.4 KiB Raw Blame History Unescape Escape