Kleine lokale Modelle bekommen den Harness: Reika, Jeff-Code und d1 zielen auf On-Device-Agenten

Am 5. Oktober tauchten zwei GitHub-Projekte mit fast identischem Rahmen auf. Reika, ein Coding-Agent-CLI des Entwicklers alexwkleung, wurde zuerst um kleine lokale Modelle herum gebaut: 8.000.000.000 bis 35.000.000.000 Parameter, oft bei Q2 bis Q4, mit einem Kontextfenster von 16 bis 32.000. Jeff-Code, ein Fork von Mario Zechners Pi-Agent, stellt ein 800.000.000-Entscheidungsmodell neben Qwen 3.8-27.000.000.000. Es meldet Coding-Aufgaben 47% schneller bei gleicher Pass-Rate.

Das ist für jeden relevant, der Agenten auf eigener Hardware laufen lässt. Wenn die Agentenschleife und nicht das Modell entscheidet, ob ein lokaler Lauf zu Ende kommt oder sich verrennt, werden kleine Modelle für Arbeit nutzbar, die derzeit eine gehostete API braucht. Keines der Projekte beansprucht Frontier-Ergebnisse. Unklar bleibt, wie sich beide Harnesses außerhalb der eigenen Evaluierungen der Autoren schlagen.

Reikas README veröffentlicht die Messungen hinter seinen Designentscheidungen, und sie sind konkret. Ein Rewrite mitten im Kontext verarbeitete 8.453 Token Prompt neu, was das Projekt mit 7,9 Minuten Prefill veranschlagt. Ein Anhang in derselben Sitzung kostete 25 Token und 3,5 Sekunden. In einem A/B-Test verwarf ein Arm seine Befunde vor einem Kontext-Fold. Dieser Arm faltete fünfmal, las Dateien erneut, die er schon gelesen hatte, und antwortete nie. Der Arm, der zuerst nach seinen Befunden gefragt wurde, antwortete aus dem Digest. Die Formulierung des Prompts, so das Projekt, ist der schwächste Hebel. Bei einer vagen Aufgabe bei Q2 konvergiert oder verrennt sich ein Modell etwa 50/50, und der Harness kann diese Rate nicht bewegen, nur was die scheiternde Hälfte kostet. Reika berichtet außerdem, dass Modelle mit 9.000.000.000 bis 35.000.000.000 Parametern Multi-File-Aufgaben im Test am zuverlässigsten bewältigten. Modelle mit 8.000.000.000 bis 9.000.000.000 Parametern schafften einfache, gut abgegrenzte Aufgaben, und unter 7.000.000.000 kamen selten weit.

Jeff-Codes Zahlen kommen mit Intervallen, was für ein Projekt-README selten ist. Über 1.242 gepaarte Aufgaben lag die Pass-Rate mit Jeff bei 62,4% gegenüber 62,8% für Qwen 3.8-27.000.000.000 allein. Das ist eine gepaarte Differenz von minus 0,2 Punkten, mit einem 95%-Intervall von minus 2,6 bis plus 2,1. Die Zeit pro Aufgabe betrug im Mittel 0,68x, der Median 0,70x. Die Gesamtzeit über alle Aufgaben sank weniger, auf 0,86x, weil Jeff-Code bei etwa 5% der Aufgaben mehr als 30 Minuten länger läuft als Qwen allein. Thinking in jedem Turn abzuschalten war noch schneller, kostete aber 7,6 Punkte. Eine weniger vorsichtige Schwelle von 0,7 kostete 4,5 Punkte.

Entscheidungsmodelle als der andere Weg

Liquid AI wählte am selben Tag einen anderen Ansatz. Sein d1-Modell, am 5. Oktober angekündigt, beantwortet Fragen zu einer Situation mit einer Wahrscheinlichkeit pro möglicher Antwort. Es erzeugt überhaupt keine Token und liefert Ergebnisse in 200 bis 300 ms für eine Textentscheidung. Liquid sagt, d1 erreiche oder schlage GPT-6.1 Sol bei vier von sechs getesteten realen Anwendungen, vom Filtern von Support-Tickets bis zur Inspektion von Leiterplatten. Und das bei 19x bis 200x geringeren Kosten und bei jeder Aufgabe schneller. Das Unternehmen meldet außerdem 85 bis 97% Genauigkeit beim Sortieren guter und defekter Teile im öffentlichen Datensatz VisA, eine Aufgabe, für die es nie trainiert wurde.

Die relevanteste Demo für Agenten-Bauer ist die Kontextkompaktierung. Liquid sagt, d1 lese jede Tool-Ausgabe in der Sitzung eines Coding-Agenten und behalte, kürze oder verwerfe sie. Es entfernt 52% der Token und behält jede Ausgabe, die die Aufgabe braucht. Das ist dasselbe Problem, das Reika mit Kontext-Folds angeht, gelöst durch ein viel kleineres Modell, das eine engere Frage gestellt bekommt. Liquid beschreibt d1 als sein erstes Entscheidungsmodell und als das erste, das diese Fähigkeiten auf Bilder ausdehnt.

Die Harness-These taucht auch in einem Beitrag von Sean Goedecke auf, veröffentlicht am 5. Oktober. Goedecke argumentiert, dass Modelle wie Jev, die nur Entscheidungen ausgeben, sich in handgebaute Klassifikatoren destillieren lassen, sobald ein Prompt validiert ist. Eingaben und Ausgaben sammeln, dann etwas Kleineres und Schnelleres für diese eine Aufgabe trainieren. Er merkt an, dass das Training eines maßgeschneiderten Klassifikators außerhalb der Fähigkeiten der meisten Engineering-Teams liegt. Diese Lücke füllt zuerst ein allgemeines Entscheidungsmodell.

Nicht jedes kleine Modell ist ein Entscheidungsmodell. Interfaze 1.1 Lite, am 5. Oktober auf Hugging Face veröffentlicht, ist ein Mixture-of-Architectures-Modell. Es läuft auf einer einzigen 80 GB GPU ohne externe Dienste. Es meldet 83,8 auf olmOCR-Bench, 85,9 auf GPQA Diamond und 3,01 Word Error Rate auf VoxPopuli-Cleaned. Es transkribiert eine 95-minütige Aufnahme in etwa 90 Sekunden. Das ist On-Device-Fähigkeit für Dokument- und Spracharbeit, nicht für Code.

Die Open-Weight-Frontier bewegte sich am selben Tag in die andere Richtung. Reflection kündigte Beam an, ein sparse Mixture-of-Experts-Modell mit 501.000.000.000 Gesamtparametern und 23.000.000.000 aktiven. Es wurde auf 23.800.000.000.000 Token vortrainiert und mit über 100.000.000 Rollouts auf 10.500 NVIDIA GB300 GPUs über vier Wochen trainiert. Reflection sagt, Beam sei konkurrenzfähig mit größeren offenen Modellen wie GLM 5.2 und nähere sich Qwen 3.8-Max bei Coding- und agentischen Aufgaben. Kimi K3 bleibe bei der rohen Leistungsfähigkeit vorn. Die Gewichte, der technische Bericht und die Modellkarte sind für später in diesem Monat versprochen, und das Modell ist noch im Red-Teaming.

Vorerst ist die praktische Behauptung von der Seite der kleinen Modelle enger als das Marketing darum herum. Reika ist Pre-1.0 und sagt, dass sich Befehle und Verhalten zwischen Releases ändern können. Jeff-Codes Beschleunigung hält auf SWE-bench Verified bei 0,63x und Terminal-Bench Pro bei 0,64x. Auf Terminal-Bench 2.0 bei 0,96x oder SkillsBench bei 0,91x zeigt sich kein klarer Gewinn. Der Harness hilft am meisten, wo die Aufgabe Routine ist, und genau dort passt auch ein Entscheidungsmodell.