Kleine Modelle sollten entscheiden, was große Modelle sehen

Es wird immer üblicher, ein leistungsstarkes KI-Modell als Orchestrator für kleinere Modelle einzusetzen. Das große Modell plant die Arbeit und delegiert Klassifizierungen, Extraktionen oder vorhersehbare Bearbeitungen an schnellere und günstigere Modelle.

Das ist sinnvoll. Aber es optimiert nur die Frage, wer welche Aufgabe ausführt.

Ich glaube, es gibt ein noch größeres Effizienzpotenzial: kleine Modelle nicht nur unter dem großen Modell einzusetzen, sondern um es herum.

Sie könnten den Kontext vorbereiten, bevor das Modell schlussfolgert, die Ausgaben seiner Tools filtern und nützliche Informationen bewahren, während die Session wächst.

Das große Modell würde weiterhin die schwierigen Entscheidungen treffen. Aber da es intelligent, langsam und teuer ist, sollte jeder Token, den es verarbeitet, seinen Platz verdienen.

Kontext vorbereiten statt ansammeln

Coding-Agenten bauen eine lange Arbeitshistorie auf: Nachrichten, Pläne, Befehlsausgaben, Dateien, Fehler und veraltete Versionen derselben Information. Jedes Element mag einmal nützlich gewesen sein. Nur wenige bleiben für jede spätere Entscheidung relevant.

Aktuelle Systeme sammeln dieses Material oft an, bis sie Tool-Ergebnisse löschen, Erinnerungen speichern oder die Konversation komprimieren. In der Dokumentation von Anthropic wird irrelevanter Kontext als Bedrohung für den Fokus des Modells behandelt, nicht nur für die Kapazität des Kontextfensters.

Ein kleines Modell könnte vor jedem wichtigen Schritt der Argumentation den Kontext auswählen. Die Ausgabe könnte so aussehen:

{
  "include_messages": [2, 7, 11],
  "include_files": [
    { "path": "src/auth.ts", "lines": "48-126" },
    { "path": "tests/auth.test.ts", "match": "refresh token" }
  ],
  "include_tool_results": ["call_184"],
  "durable_notes": ["Der Benutzer lehnte cookie-basierte Sessions ab."],
  "omit_reason": "Unrelevante Build-Logs und veraltete Dateien"
}

Das große Modell würde die ausgewählten Quellpassagen erhalten und nicht eine vage Zusammenfassung der gesamten Historie. Das ist Retrieval über den sich entwickelnden Workspace des Agenten.

Links ein unübersichtlicher Workspace mit Dateien, fehlgeschlagenen Tests, alten Plänen und Notizen. Ein Kontext-Selektor wählt vier davon aus, die rechts als Arbeitskontext an das Hauptmodell übergeben werden. — Der Workspace behält alles. Was das Modell erreicht, ist nur das, was für die nächste Entscheidung nötig ist.

Tool-Ausgaben filtern, bevor das Hauptmodell sie liest

Eine API oder ein MCP-Server liefert möglicherweise Dutzende von Feldern, obwohl der Agent nur drei benötigt. IDs, Zeitstempel, Paginierungs-Metadaten und wiederholte Beschreibungen bleiben dann im Transkript und werden in späteren Durchläufen eventuell erneut verarbeitet.

Ein kleines Modell könnte zwischen der Tool-Antwort und dem Hauptmodell sitzen. Es würde die Rohausgabe anhand des aktuellen Ziels filtern, eine typisierte Teilmenge zurückgeben und einen Verweis auf das unveränderte Ergebnis bewahren. Dies ist besonders wertvoll, wenn der Entwickler des Agenten das externe Tool nicht ändern kann.

Dieselbe Schicht könnte Dateien klassifizieren, relevante Abschnitte lokalisieren und generierte Inhalte ausschließen, bevor das große Modell sie liest.

Eine lange rohe Tool-Antwort durchläuft einen Payload-Filter, der eine kurze Liste nützlicher Felder an das Hauptmodell übergibt, während die rohe Antwort als abrufbarer Beleg archiviert wird. — Der Filter reduziert die Menge der Informationen, die das Modell erreichen, während die rohe Antwort abrufbar bleibt.

Informationen komprimieren, solange sie aktuell sind

Kompression ist meist reaktiv: Sobald der Kontext einen Schwellenwert erreicht, wird eine lange Historie zu einer kurzen Zusammenfassung. Bis dahin hat das Hauptmodell verbose Inhalte möglicherweise schon mehrfach gelesen. Eine späte Zusammenfassung muss zudem Details aus mehreren Phasen bewahren, deren zukünftige Relevanz schwer vorhersehbar ist.

Die Historie eines Agenten hat zwei Leser mit unterschiedlichen Bedürfnissen. Menschen benötigen die vollständigen Nachrichten und natürliche Sprache, um zu verstehen und zu prüfen, was passiert ist. KI-Modelle benötigen dieselben Fakten in so wenigen zuverlässigen Tokens wie möglich.

Ein kleines Modell könnte beide Versionen parallel führen, während Informationen eingehen: das vollständige, für Menschen lesbare Transkript und eine kompakte, maschinenlesbare Darstellung im aktiven Kontext. Jedes komprimierte Element würde zurück auf sein Original verlinken.

Die Maschinenversion benötigt keine geschliffene Prosa. Sie könnte sich am aktuellen “Caveman”-Trend bei Coding-Agenten orientieren: telegrafische Aussagen, die Artikel, Höflichkeitsfloskeln, Weichmacher und Füllwörter entfernen, aber technische Details beibehalten. Es geht nicht darum, dass Menschen so sprechen. Es geht darum, nicht mehr dafür zu bezahlen, dass große Modelle Sprache lesen, die für Menschen geschrieben wurde.

Ein 2.000 Token langes Testlog könnte so aussehen:

14 Tests bestanden. refreshes expired token fehlgeschlagen, da expiresAt undefined war in auth.test.ts:88. Vollständige Ausgabe: Artefakt test-run-184.

Das Ergebnis, der Fehler, der relevante Wert, die Position und der Weg zurück zum Beleg bleiben erhalten. Das Rauschen verschwindet.

Dies ist kontinuierliche Datenpflege statt einer Notfall-Kompression.

Zwei Zeitstrahlen. Im ersten stapeln sich rohe Nachrichten bis zu einem Warnsignal und kollabieren dann in einer kompakten Zusammenfassung. Im zweiten komprimiert ein Memory-Keeper jede Nachricht beim Eintreffen, was dauerhaft eine kompakte Aufzeichnung ergibt. — Bei einer späten Kompression zahlen Sie in jedem Durchgang für dieselben Tokens, bis der Schwellenwert erreicht ist. Komprimieren während des Prozesses bedeutet, nur einmal zu zahlen.

Die Wirtschaftlichkeit ist plausibel

Die zusätzliche Inferenz lohnt sich nur, wenn sie mehr einspart, als sie an Geld, Latenz und Fehlern kostet. Ein einfaches Modell zeigt, dass die finanzielle Schwelle niedrig sein kann.

Betrachten wir eine beispielhafte Coding-Session mit 20 Schritten. Das große Modell erhält insgesamt 1,45 Millionen Input-Tokens. Ein Kontext-Modell liest dieselbe Historie, gibt 10.000 Tokens an Auswahlbefehlen aus und reduziert den Input des großen Modells auf 560.000 Tokens. Beide Versionen produzieren 40.000 Output-Tokens des großen Modells.

Zwei Spalten. Links geht ein hoher Stapel Dokumente direkt in das Hauptmodell, was ein großes rotes Kosten-Tag erzeugt. Rechts dünnt ein kleiner Filter den Stapel zuerst für einen Bruchteil des Preises aus, und das Kosten-Tag des Hauptmodells ist viel kleiner. — Das kleine Modell amortisiert sich doppelt, wenn das Entfernte teurer zu lesen ist, als das Modell zu betreiben.

Unter Verwendung der Standard-API-Preise vom 4. Juli 2026 ergibt die Kombination von Gemini 3.1 Flash-Lite (0,25 $ Input und 1,50 $ Output pro Million Tokens) mit Claude Fable 5 (10 $ Input und 50 $ Output) Folgendes:

	Ohne Filterung	Mit Filterung
Input großes Modell	1,45M Tokens	0,56M Tokens
Kosten großes Modell	16,50 $	7,60 $
Kosten Kontext-Modell	keine	0,38 $
Gesamt	16,50 $	7,98 $

Gesamtkosten einer 20-Schritte-Session

Ohne Filterung$16.50

Mit Filterung$7.98

Die letzte Tabellenzeile, maßstäblich gezeichnet. Die Ersparnis beträgt 8,52 $ oder 51,7 %.

Die Filterung rentiert sich bereits nach dem Entfernen von 37.750 Fable-Input-Tokens, was nur 2,6 % des rohen Inputs entspricht.

Der Filter kann scheitern

Durch das Entfernen von Kontext kann auch der Hinweis verloren gehen, der die Aufgabe löst. Ein kleines Modell könnte eine ungewöhnliche Log-Zeile verwerfen, eine Nutzerbedingung verzerren oder eine Kennung löschen, die für den nächsten Tool-Aufruf benötigt wird.

Die Architektur benötigt daher einige strikte Regeln:

rohe Inputs müssen abrufbar bleiben;
Filterentscheidungen müssen strukturiert und prüfbar sein;
Nutzeranweisungen oder Sicherheitsbeschränkungen dürfen niemals komprimiert werden;
unsichere Informationen müssen eingeschlossen werden;
das Hauptmodell muss die originalen Belege anfordern können;
der Aufgabenerfolg muss gemessen werden, nicht nur die Token-Ersparnis.

Kleine Modelle sollten den Zugang zu Belegen verwalten und nicht selbst zu einer unsichtbaren Instanz der Wahrheit werden.

Das Experiment zählt mehr als die Schätzung

Die Idee sollte gegen drei Alternativen getestet werden: roher akkumulierter Kontext, schwellenwertbasierte Kompression und kontinuierliche semantische Filterung.

Jedes System sollte dieselben Coding-Aufgaben bearbeiten. Die Auswertung sollte die Gesamtkosten der Tokens, die Latenz, die Cache-Auslastung und den Aufgabenerfolg messen. Zudem sollte jeder Fall dokumentiert werden, in dem die Filterung Belege entfernt, die das Hauptmodell später benötigt.

1Ein AufgabensetDie gleiche Coding-Arbeit für jeden
2Drei SystemeRoh, Schwellenwert-Kompression, kontinuierliche Filterung
3Vier MesswerteKosten, Latenz, Cache-Hits, Erfolg
4Ein UrteilGünstiger zählt nur, wenn es immer noch funktioniert

Token-Ersparnisse allein würden den aggressivsten Filter zum Gewinner erklären, weshalb die Qualität der Fertigstellung das entscheidende Maß ist und keine Randnotiz.

Die Architektur gewinnt nur, wenn sie die Kosten senkt, ohne die Qualität der Ergebnisse zu beeinträchtigen. Bis ein solcher Test existiert, sind die wirtschaftlichen Überlegungen ein Grund zum Experimentieren, aber kein Beweis für die Funktionsfähigkeit des Systems.

Eine neue Rolle für kleine Modelle

Model Routing fragt: Welches Modell sollte diese Aufgabe ausführen?

Diese Architektur fragt: Was verdient die Aufmerksamkeit des besten Modells?

Model RoutingWer führt die Arbeit aus

Liest die Aufgabe, wählt ein Modell
Das günstige Modell erledigt die einfachen Jobs
Kontext ist das, was sich angesammelt hat

Kleine Modelle um das große herumWorauf die Arbeit basiert

Das beste Modell trifft die schwierigen Entscheidungen
Kleine Modelle wählen aus, was es liest
Kontext wird vor jedem Schritt ausgewählt

Die beiden sind keine Alternativen. Routing entscheidet, wer antwortet, dies entscheidet, worauf die Antwort basiert.

Kleine Modelle könnten zu Kontext-Bibliothekaren, Payload-Editoren und Memory-Wartern werden. Sie würden den Workspace vorbereiten, bevor das Hauptmodell schlussfolgert, und anschließend die nützlichen Ergebnisse bewahren, nachdem es gehandelt hat.

Die Idee ist besonders relevant für Coding-Agenten, da diese so viel Zwischenmaterial erzeugen. Sie gilt auch für Forschung, Support und andere langfristige Workflows, die Konversationen, Tools und externe Daten kombinieren.

Das fähigste Modell sollte nicht jede Zeile lesen, nur weil das System sie senden kann.

Jeder Token sollte einen Grund haben, dort zu sein.