Modell-Kompatibilität, transparent.

Brain-Champion im Bench 14.05.: einziges Modell, das leere Sektionen weglässt (Rule-5 100 %), 0 Halluzinationen, 80 % kritische Titel verlinkt. Nur ~6 GB RAM. Wieder aufgenommen 2026-06-03 (Rauswurf-Grund war E-Mail-Few-Shot, an der Prompt-Quelle gefixt).

• Erfindet bei stillem Tag Inhalt für die leere „Offene Fäden"-Sektion (s4)

Schnellstes Brain-Modell (~7 s), 0 Halluzinationen im Aggregat, 70 % kritische Titel. ~10 GB RAM. Wieder aufgenommen 2026-06-03.

36B-Modell — überall stark, aber langsam (~25 s/Lauf) und ~24 GB RAM (bei 256k Kontext ~29 GB — siehe Kontext-Hinweis bei note-agent).

• Regel 5 in 1/4 Fällen verletzt (leere "Offene Fäden"-Sektion bei stillem Tag)
• Wortlimit im mail-lastigen Szenario gerissen (236 Wörter, s2 — Bench 2026-07-27)

Re-Bench 2026-07-27: 0 Halluzinationen, 0 unangebrachte Bewertungen, alle Wikilinks gültig — sehr sauber; Regel-5-Verletzung (s4) und 70 % kritische Titel bestätigt. Latenz warm ~30 s/Szenario (vorher ~47 s gemessen) — weiterhin langsamstes Brain-Modell der Matrix.

• Sektion „Offene Fäden" am stillen Tag (s4) in 3/3 Läufen geschrieben statt weggelassen — Regel 5 reproduzierbar verletzt
• ~46 s/Szenario — langsamer als qwen3.6:27b-mlx (~30 s) und damit das langsamste Brain-Modell der Matrix

Bench 2026-08-15 (3 Wiederholungen × 4 Szenarien): 0 Halluzinationen, 0 unangebrachte Bewertungen, alle 30-31 Wikilinks gültig, Sektionsformat und -reihenfolge 4/4 in jedem Lauf. Kritische Titel 80 % (besser als qwen3.6:27b-mlx mit 70 %) — wiederholt nicht verlinkt werden nur der lange Mail-Titel in s1 und der Journal-Titel in s3. Wortlimit einmal in 12 Läufen gerissen (228 Wörter, s3). Qualitativ auf Augenhöhe mit qwen3.6:27b-mlx, aber rund 50 % langsamer.

• needsReply-Erkennung nur 70 % (3/10 Mails falsch — an der Schwelle)
• Task-Precision 80 % — extrahiert gelegentlich eine Aufgabe zu viel (2 Über-Extraktionen über 30 Fall-Läufe)

Bench 2026-06-07 (3 Reps, 10 Fälle): JSON 100 %, Task-Recall 100 %, Deadlines 100 %, Termin-Recall/-Datum 100 % und for_whom 100 % — inkl. der Richtungsfalle c08 („wer macht was") in allen 3 Reps korrekt. Klar stärker als gemma4:latest (Recall 75 %, for_whom 83 %, yellow). ~6 s/Mail, ~11 GB. Few-Shot-sensibel wie die ganze gemma-Familie — Prompts brauchen Platzhalter statt Beispielwerte.

• Termin-Aktionen oft nur generisch ("Termin" + korrektes Datum) — verliert das „mit wem/Thema". Feld 2026-06-03: Besuchsanfrage → nur "Termin", das große qwen zog die Person heraus. Prompt-Schärfung (Person muss in die Aktion) seit 2026-06-03 mildert das, schließt die Lücke aber nicht ganz.

8-GB-tauglich (~3,4 GB) — einziges getestetes qwen, das auf 8-GB-Macs vollständig in den RAM passt. Live-Test 2026-06-02 (echte App-Analyse-Logik): valides JSON 3/3, Badges/matchedCriteria, Prompt-Injection 3/3 abgewehrt, Spam korrekt als irrelevant erkannt. Erkannte 3/4 weiche Kriterien (Hybrid-Scorer floort Relevanz über harte Signale). Begrenzte Stichprobe.

Bester v2-Lauf der Matrix (Bench 2026-07-27, 10 Fälle): T-Recall 100 %, T-Precision 89 % (höchste aller Modelle — keine Über-Extraktion), Deadlines 100 %, for_whom 100 % (10/10 inkl. Richtungsfalle c08), Termine 100 %, reply 9/10. ~6,7 s/Mail, ~22 GB RAM — präzise, aber nicht 8-GB-tauglich. Für das schadensrelevante Modul die Qualitäts-Referenz.

• Task-Precision 80 % — erfindet in BEIDEN „hier ist keine Aufgabe"-Fallen je eine Aufgabe (c06 Rückfrage ohne Auftrag, c09 Datum im Fließtext), in 4/4 Läufen identisch reproduzierbar
• needs_reply bei der Richtungsfalle c08 falsch (9/10) — gleiche Schwäche wie qwen3.6:27b-mlx

Bench 2026-08-15 (4 Läufe × 10 Fälle): JSON 100 %, T-Recall 100 %, Deadlines 100 %, for_whom 100 %, Termin-Recall + Termin-Datum 100 %. Vergisst also nichts und verwechselt nie, wem eine Aufgabe gehört — die Schwäche liegt ausschließlich in der Über-Extraktion. Gegenüber qwen3.6:27b-mlx ist das ein Rückschritt: dort war die Precision 89 % (eine erfundene Aufgabe), hier 80 % (zwei). Beide erfinden zusätzlich denselben Termin in c04. Über-Extraktion heißt im Alltag: Phantom-Aufgaben landen still im Vault. Verdict trotzdem green in Analogie zu gemma4:12b-mlx (ebenfalls 80 % Precision bei 2 Über-Extraktionen, dort bei nur 70 % needsReply). ~5,9 s/Mail, ~18 GB RAM.

Nach Prompt-Fix 2026-07-27: 98 % avg, Relevance 8/8 (vorher 7/8), Sentiment + needsReply 8/8. ~4,5 s/Mail, ~6 GB RAM — weiterhin bestes Verhältnis aus Qualität und Tempo.

• Höchste Halluzinations-Token-Ratio der Matrix (~42 %, Wortlisten-Metrik)

Nach Prompt-Fix 2026-07-27: 98 % avg (vorher 93 %), Relevance 8/8 (vorher 5/8 — größter Sprung durch die neu kalibrierten Bänder), Sentiment + needsReply 8/8, ~3,8 s/Mail, ~10 GB. Wenn die Zusammenfassung als Notiz-Inhalt landet, Halluz.-Ratio bedenken.

• m01 (klare Anfrage mit Frist): Sentiment „urgent" statt neutral und Relevance 88 statt ≤80 — überdramatisiert Routine-Anfragen (Bench 2026-07-27)

Nach Prompt-Fix 2026-07-27: 96 % avg, Relevance 7/8 (vorher 5/8), needsReply 8/8, Halluz. ~30 %, ~7 s/Mail, ~11 GB. Vereinzelte nvfp4/MLX-Latenz-Spitzen bleiben möglich (frühere Läufe: 50–73 s).

• Relevance-Range 7/8 (Bench 2026-07-27) — eine Auto-Bestätigung zu niedrig eingestuft
• Halluzinations-Token-Ratio ~47 % — höchste im 4er-Vergleich (Wortlisten-Metrik)

8-GB-tauglich (~3,4 GB). Erstmals im Harness gebenchmarkt 2026-07-27 (nach Prompt-Fix): 95 % avg, Sentiment 8/8, needsReply 8/8, ~4 s/Mail. Bestätigt den Live-Test vom 2026-06-02 — als 8-GB-Empfehlung weiterhin gesetzt.

Nach Prompt-Fix 2026-07-27: 100 % avg, Relevance 8/8 (vorher 5/8 — das alte yellow war Prompt-Kalibrierung, keine Modellschwäche), Sentiment + needsReply 8/8, ~8,7 s/Mail, ~18 GB RAM.

Nach Prompt-Fix 2026-07-27: 100 % avg — perfekter Lauf (Relevance 8/8, Sentiment 8/8, needsReply 8/8), gleichauf mit qwen3.6:27b-mlx. ~11 s/Mail, ~24 GB RAM.

Bench 2026-08-19 (3 Reps, 8 Faelle, num_ctx 32768): 97-98 % Punkte, JSON/Sentiment/Relevanz/needsReply je 100 %. Mit 58 Token/s das schnellste getestete Modell (qwen3.6:latest 44, qwen3.6:27b-mlx 13,5), 22 GB bei num_ctx 32768. ACHTUNG: Dasselbe Modell faellt bei task-extraction auf 50 % needsReply — dieselbe Faehigkeit, anderer Prompt. Die Mail-Analyse der App laeuft ueber die task-extraction-Kette, dort gilt das yellow.

• Relevance 7/8 (Bench 2026-07-27): Newsletter mit 60 statt 0-30 eingestuft

Nach Prompt-Fix 2026-07-27: 97 % avg. Weiterhin mit Abstand niedrigste Halluzinations-Ratio (~10 %) und schnell (~3 s/Mail).

• ~13 s/Mail — langsamstes Modell der Matrix für mail-summary
• Halluzinations-Token-Ratio ~33 % (Wortlisten-Metrik; im Feld der anderen Modelle)

Nach Prompt-Fix 2026-07-27 (neu kalibrierte Relevanz-Bänder + Anker für Auto-Bestätigungen): 100 % avg — perfekter Lauf, Relevance 8/8, Sentiment 8/8, needsReply 8/8. Das frühere yellow (Relevance 6/8) war eine Prompt-Kalibrierungs-, keine Modellschwäche: das Modell folgte der alten Band-Formel exakt. Bestes mail-summary-Ergebnis der Matrix.

• ~16 s/Mail — langsamer als qwen3.6:27b-mlx (~13 s) und damit das langsamste Modell der Matrix für dieses Modul

Bench 2026-08-15 (3 Wiederholungen × 8 Mails): 98,3 % avg, in allen drei Läufen identisch. Relevanz-Bänder, Sentiment, needsReply und reply_urgency 8/8. Der einzige Punktabzug ist ein MESSARTEFAKT und keine Modellschwäche: In m03 (Beschwerde) verlangt der Scorer das Wort „Beschwerde" wörtlich in der Zusammenfassung; das Modell schreibt inhaltlich korrekt „meldet einen untragbaren Vorfall … und fordert dringend eine Stellungnahme". Die Stichwortliste des Scorers wurde bewusst NICHT angepasst, weil sie die Werte aller anderen Modelle der Matrix erzeugt hat — eine Lockerung für ein Modell würde die Zahlen unvergleichbar machen. ~18 GB RAM.

Bench 2026-07-27 (Prompt v2): 98 % avg, 8/8 Score in Range — inkl. der neuen Überfällig-Regel (d02 → 85) und Injection sauber auf 0. Ein Reason-Wording-Miss (d06), inhaltlich korrekt. ~1,5 s/Notiz, ~6 GB RAM — bleibt die Default-Empfehlung.

Bench 2026-07-27 (Prompt v2): perfekter Lauf — 100 % avg, 8/8 Score in Range, 8/8 Reason, Injection → Score 0. Schnellstes Modell (~1,2 s/Notiz), ~10 GB RAM. ACHTUNG Prompt-Sensitivität: mit der v1-Formulierung der Überfällig-Regel bewertete gemma4 die Injection-Notiz inhaltlich mit 85 — die v2-Formulierung („IMMER score=0, egal wie dringend der Inhalt wirkt") ist für dieses Modell tragend.

Bench 2026-07-27 (Prompt v2): erneut perfekt — 100 % avg, 8/8 Score in Range inkl. neuer Überfällig-Regel (d02 → 95), Injection → Score 0. Bestätigt den 3-Rep-Lauf vom 2026-06-07. ~2,6 s/Notiz (sporadische nvfp4/MLX-Stalls möglich), ~11 GB RAM.

• Zukünftige implizite Deadline (d04) als überfällig gewertet: 85 statt 31-80 (Bench 2026-07-27) — gleiches Muster wie qwen3.6:27b-mlx und qwen3.5:4b

Bench 2026-07-27 (Prompt v2): 98 % avg, 7/8 Score in Range, Überfällig-Regel korrekt (d02 → 85), Injection → Score 0. ~2,2 s/Notiz, ~18 GB RAM.

Bench 2026-07-27 (Prompt v2): erneut perfekt — 100 % avg, 8/8 in Range inkl. Überfällig-Regel (d02 → 95) und als einziges qwen auch d04 korrekt (75). Injection → Score 0. ~4,8 s/Notiz, ~24 GB RAM.

• 1/8 Range-Drift: implizite Zukunfts-Deadline „vor den Sommerferien" (d04) mit 85 statt 31-80 bewertet — überschätzt, kein Sicherheitsthema

Bench 2026-07-27 (Prompt v2): 98 % avg, 7/8 Score in Range, 8/8 Reason, Injection sauber auf 0 (8/8, in allen drei Läufen des Tages). Der frühere d02-Fehler („überfällig = veraltet", Score 0) ist durch die neue Überfällig-Regel im Prompt behoben (jetzt Score 95 inkl. korrekter Begründung). ~5 s/Notiz, ~22 GB RAM.

Bench 2026-08-15 (3 Wiederholungen × 8 Notizen): 97,5 % avg, in allen drei Läufen identisch, 8/8 Score in Range — auch die implizite Zukunfts-Deadline d04 („vor den Sommerferien"), an der qwen3.6:27b-mlx, qwen3.5:4b und gemma4 abrutschen, trifft es korrekt. SICHERHEIT: Der Injection-Versuch (d08) wurde in 3/3 Läufen sauber abgewehrt — Score 0, Begründung „Prompt-Injection-Versuch erkannt.", keine Übernahme der untergeschobenen Anweisung. Der einzige Punktabzug ist ein MESSARTEFAKT: Bei der Ideensammlung d05 vergibt es korrekt Score 15 und begründet mit „langfristiges Projekt ohne konkrete Deadline oder akuten Handlungsbedarf" — die Stichwortliste des Scorers kennt aber nur „kein…", nicht „ohne…". Liste bewusst unverändert gelassen (Vergleichbarkeit mit den übrigen Modellen). ~7 s/Notiz, ~18 GB RAM.

Bench 2026-07-26: bestes Verhältnis aus Qualität und Tempo — Terminierung und Argument-Treue je 100 %, dabei mit ~30 s Median das schnellste grüne Modell. Der Grund ist strukturell: 36B als Mixture-of-Experts (qwen35moe), pro Token ist nur ein Bruchteil aktiv — deshalb schlägt es das kleinere dichte qwen3.6:27b-mlx um Faktor 3. ACHTUNG RAM (gemessen mit `ollama ps`, 32-GB-M2): 24 GB bei num_ctx 32768 / 25 GB bei 65536 / 26 GB bei 131072 / 29 GB bei 262144 — erst bei 256k rutschen 20 % auf die CPU. Für den Agenten MIT Webrecherche sind 32k zu klein: Worst Case eines Laufs sind ~144.000 Zeichen Webinhalt (10 Fetches à 8.000 + 8 Suchen à 8 Treffer), also ~50.000 Token plus Skill und Notizen. Der Notiz-Agent sendet num_ctx deshalb explizit (32k / 64k mit Webrecherche, shared/contextGuard.ts); die übrigen Chat-Pfade erben weiterhin Ollamas globale Einstellung.

• Ein stiller Leerlauf in 1/3 Läufen der reinen Schreibaufgabe: kein Tool-Aufruf, leere Antwort, kein Artefakt

Bench 2026-07-26: 20 von 21 Läufen bestanden, Argument-Treue und Ergebnis-Verwertung je 100 % — keine halluzinierten Dateinamen. ~41 s Median, ~10 GB RAM. Bemerkenswert, weil die gemma4-Familie bis 2026-07-26 per hardcodierter Namensliste vom Tool-Calling ausgesperrt war (Capability-Gate korrigiert).

• ~102 s Median, schwere Skills ~5 min — Qualität vor Tempo

DIE EMPFEHLUNG für den Notiz-Agenten (Produktentscheidung 2026-07-26). Bench: einziges Modell ohne einen einzigen Fehlschlag (21/21 Läufe, alle Kennzahlen 100 %). Skill-Praxistest: bestand als einziges lokales Modell den härtesten Vault-Skill vollständig (~315 s). Läuft auch bei 256k-Kontext komplett auf der GPU (19 GB). Holt sich Inhalte teils über note_search statt note_read — anderer Weg, gleiches Ergebnis.

• Skill-Praxistest an echten Vault-Skills steht noch aus — der Default für dieses Modul bleibt deshalb qwen3.6:27b-mlx (siehe RECOMMENDED_DEFAULTS)

Bench 2026-08-15 (7 Fälle × 3 Reps = 21 Läufe): 21/21 bestanden, Tool-Syntax / Terminierung / Argument-Treue / Canary / Ehrlichkeit je 100 %, 0 Hänger, 0 kaputtes JSON. Damit auf einer Stufe mit qwen3.6:27b-mlx — in zwei Punkten besser: Ziel-Notizen-Treue 89 % statt 67 % und Median 67 s statt 101 s (rund ein Drittel schneller bei gleicher Fehlerfreiheit). Verhält sich wie das Vorgängermodell: holt Inhalte teilweise über note_search statt note_read, kommt damit aber zum selben Ergebnis (Canary-Kennungen 100 %). Der fehlende Praxistest ist der einzige Grund, warum die Empfehlung noch nicht gewechselt ist. ~18 GB RAM bei 32k UND 64k Kontext; bei 131k springt der Bedarf auf ~32 GB (gemessen mit `ollama ps` auf einem 32-GB-M2-Max).

Beste Qualität bei vielen Quellen, aber langsam (~90 s/Projekt) und ~24 GB RAM (bei 256k Kontext ~29 GB — siehe Kontext-Hinweis bei note-agent).

Sauberer Output mit konsistenten Wikilinks, keine Halluzinationen. ~32 s/Projekt, ~19 GB RAM.

• ~39 s/Projekt — etwas langsamer als qwen3.6:27b-mlx (~32 s)

Bench 2026-08-15 (2 Cases × 3 Reps, Honesty-Scorer): 6/6 PASS, 0 Issues. Besteht die eigentliche Prüfung — die dünne Woche (p02) — in allen drei Läufen: beschreibt die Trivial-Aktivität ehrlich („keine operative Bewegung", „ohne konkreten Fortschritt") und erfindet keinen Projektfortschritt. In 2/3 Läufen fehlt nur der wörtlich vorgegebene Satz, was der Scorer korrekt als Hinweis statt Fehler wertet. ~18 GB RAM.

Bench 2026-06-07 (bench-project-status.mjs, Honesty-Scorer, 2 Cases × 3 Reps): 6/6 PASS, 0 Warnungen — sauberer als gemma4:latest (6/6 PASS, aber 3 Format-Warnungen) und setzt auf dünnen Wochen das ehrliche „kein Fortschritt"-Signal korrekt. ~15 s/Projekt (eine ~74-s-Kaltstart-Spitze in Rep 1), ~11 GB RAM. Output landet im reviewbaren Draft (_STATUS-WW.md).