Ein kleiner Agent wird nicht dadurch nützlich, dass man ihm noch mehr Chatbot-Glitzer draufklebt. Er wird nützlich, wenn er die richtigen Werkzeuge sauber benutzen kann. Servus, ich bin Lissy, und heute ist Dienstag, also Werkzeugtag. Wir schauen auf ein Paper namens Data Turnstile, auf eine lokale PDF-Erweiterung für Claude, auf einen MCP-Server für Desktop-Automation und auf AirLLM. Das klingt nach vier Einzeldingen. Eigentlich ist es eine ziemlich klare Betriebslektion: Der Engpass sitzt nicht immer im Modell. Manchmal sitzt er in den Daten, im Kontextfenster, am Bildschirm oder schlicht im Speicher.
Fangen wir mit Data Turnstile an. Das Paper kommt von Goutham Ramakrishnan und Megha Sharma und beschreibt ein offenes Framework für Trainingsdaten beim Function Calling. Also für die Fähigkeit eines Modells, nicht nur Text zu schreiben, sondern eine API korrekt aufzurufen, Parameter richtig zu setzen, Zwischenschritte zu prüfen und aus Fehlern im Ablauf wieder herauszukommen. Der Punkt ist simpel: Kleine Sprachmodelle sind billig, schnell und näher an den Daten. Aber sie haben ein Problem. Wenn die Trainingsdaten für Werkzeugnutzung verrauscht sind, können sie das nicht einfach mit Größe überspielen. Ein riesiges Modell kann manchmal aus schlechtem Beispielmaterial noch irgendwie Sinn ziehen. Ein kleines Modell stolpert schneller. Data Turnstile setzt deshalb nicht beim Modell an, sondern bei den Daten. Das System nimmt API-Spezifikationen, baut daraus synthetische Mehrschritt-Interaktionen, validiert Zwischenergebnisse und gibt Fehlerfeedback zurück in die Generierung. Genau da wird es für Unternehmen spannend. Viele Firmen brauchen keinen allwissenden Agenten. Sie brauchen ein kleines Modell, das die eigene Versand-API, das Ticketsystem oder die Vertragsdatenbank zuverlässig bedient. Dafür ist sauberes Werkzeugtraining oft wertvoller als ein noch größeres Basismodell.
Die Ergebnisse sind deshalb interessant, weil sie die übliche Größer-ist-besser-Erzählung ein Stück verschieben. Auf dem BFCL Single-Turn Benchmark kommt ein Qwen3 Modell mit 0,6 Milliarden Parametern nach Turnstile-Training auf 75,9 Prozent Gesamtgenauigkeit. Die Basisversion mit eingeschaltetem Denken lag bei 67,4 Prozent. Damit rückt dieses winzige Modell nah an Qwen3 mit 1,7 Milliarden Parametern und 78,4 Prozent heran, und auch nicht absurd weit weg von Qwen3 mit 4 Milliarden Parametern und 79,9 Prozent. Noch deutlicher wird es im Mehrschritt-Benchmark tau2 auf der Telecom-Domain. Qwen3 mit 1,7 Milliarden Parametern steigt von 6,6 Prozent auf 31,1 Prozent. Das ist laut Paper eine Verbesserung um den Faktor 4,7 und liegt sogar über Qwen2.5 mit 32 Milliarden Parametern, das dort 27,4 Prozent schafft. Qwen3 mit 0,6 Milliarden Parametern steigt von 3,5 auf 24,6 Prozent. Ein Benchmark ist kein Kundensupport am Montagmorgen. Aber die Richtung zählt: Wenn die Daten für Werkzeugnutzung besser werden, kann ein kleines Modell plötzlich Aufgaben übernehmen, die vorher nach viel größerem Modell aussahen. Für Gründer ist das die Make-or-Buy-Frage in klein: teuersten allgemeinen Agenten kaufen, oder ein schmales System auf echte Werkzeuge trainieren. Wenn die Aufgabe klar genug ist, kann der zweite Weg billiger und kontrollierbarer sein.
Der zweite Baustein ist viel praktischer: Token Saver. Das ist eine lokale Claude Desktop Erweiterung als mcpb-Datei. Sie durchsucht große PDFs lokal, holt nur die passenden Stellen in den Modellkontext und gibt Seitenzitate zurück. Laut README sollen dadurch 92 bis 98 Prozent weniger Tokens nötig sein. Das ist keine Magie. Es ist die richtige Arbeitsteilung. Wenn du ein zweihundertseitiges PDF in einen Chat kippst, zahlst du bei Folgefragen immer wieder für sehr viel irrelevantes Material. Token Saver macht vorher lokale hybride Suche und gibt dem Modell nur den relevanten Ausschnitt. Genau das ist dieselbe Lektion wie bei Data Turnstile, nur auf einer anderen Ebene. Nicht das Modell soll heldenhaft alles im Kontextfenster sortieren. Die Umgebung soll den richtigen Kontext liefern. Für kleine Kanzleien, Berater, Vereine oder Solo-Selbstständige ist das sofort verständlich. Mietvertrag, Förderbescheid, Handbuch. Die Frage ist selten, ob ein Modell theoretisch 200 Seiten lesen kann. Die Frage ist, ob du schnell die drei Absätze bekommst, die wirklich zählen, mit Seitenangabe und ohne Upload. Mir gefällt daran, dass es den Hype runterholt. Gute KI im Betrieb ist oft kein großer autonomer Agent. Es ist eine kleine lokale Suchschicht, die den teuren Teil präzise füttert.
Dann ist da nuphus-mcp. Das Projekt ist frisch auf GitHub und beschreibt sich als Desktop-Automation-MCP-Server. Konkret: Ein MCP-Client wie Claude Desktop, Cursor, VS Code oder Copilot kann über JSON-RPC per stdio auf Desktop- und Browser-Werkzeuge zugreifen. Die README nennt 36 MCP-Tools, davon 15 für den Desktop und 21 für den Browser. Dazu kommen lokale OCR, Chrome-Steuerung über CDP und optional ein eigenes Vision-Modell über OpenAI-kompatible Schnittstellen. Wichtig ist der Rahmen. Computer-Use-Agenten hatten wir zuletzt öfter. nuphus ist interessant, wenn man es nüchtern betrachtet: Es macht aus Bildschirm, Maus, Tastatur, Fenstern und Chrome konkrete Werkzeuge mit Grenzen. Ein Prozess über stdio, lokale OCR und vorgesehene Bestätigungen für riskante Aktionen. Für Teams ist das die richtige Frage: Wenn ein Agent bestehende Desktop-Software bedienen soll, wie bekommt er eine kontrollierte Hand an die Maus. Nicht jeder alte Prozess bekommt morgen eine saubere API. Aber fast jeder Prozess hat irgendeine Oberfläche. Der Unterschied zwischen Spielerei und Betrieb ist dann, ob diese Oberfläche als Werkzeug sauber verpackt ist. Mei, am Ende ist auch ein Bildschirm nur eine sehr sture API mit Pixeln.
Der vierte Baustein ist AirLLM. Das Projekt behauptet im README, 70B-Modelle auf einer einzelnen GPU mit 4 Gigabyte Speicher laufen zu lassen, ohne Quantisierung, Distillation oder Pruning. Für Kimi K3 mit 2,8 Billionen Parametern nennt das README sogar unter 4 Gigabyte VRAM, weil bei Sparse-Mixture-of-Experts-Modellen nur die tatsächlich gerouteten Experten gestreamt werden. Das klingt verrückt, aber sauber eingeordnet heißt es: Speicher schaffen heißt nicht automatisch schnell, billig und produktionsreif. Wenn Gewichte ständig von Speicher zu Rechenkarte wandern, verschiebt man einen Engpass. Man löscht ihn nicht aus der Welt. Trotzdem ist AirLLM ein gutes Signal: lokale Kontrolle kommt nicht nur über kleinere Modelle, sondern auch über Systemtricks wie Streaming und Prefetching. Für Unternehmen heißt das nicht, dass morgen alles bequem auf jeder Kiste läuft. Es heißt: Der Inferenzweg hängt an deiner Aufgabe. Schnell, privat, langsam, Batch über Nacht. Genau da entsteht die Kostenrechnung. Data Turnstile sagt: Trainiere kleine Modelle auf Werkzeuge. Token Saver sagt: Gib dem Modell weniger, aber besseres Material. nuphus sagt: Verpacke den Desktop als kontrollierte Werkzeugschicht. AirLLM sagt: Auch Speicher ist gestaltbar. Zusammen ist das für mich der reife Blick auf KI-Automatisierung. Nicht ein Modell für alles. Sondern pro Engpass der passende Hebel.
Worauf ich heute komme: Gute KI-Automation beginnt nicht beim größten Modell, sondern bei der ehrlichsten Engpassdiagnose. Fehlen deinem Agenten bessere Werkzeugdaten. Dann ist Data Turnstile die Richtung. Schickst du zu viel Kontext in den Chat. Dann brauchst du lokale Suche wie bei Token Saver. Muss ein Agent alte Desktop-Software bedienen. Dann wird eine MCP-Werkzeugschicht wie nuphus spannend. Und wenn Speicher knapp ist, lohnt sich ein Blick auf Streaming-Ansätze wie AirLLM, aber ohne Wundererzählung. Wenn du diese Woche nur eine Sache testest, dann nimm einen wiederkehrenden Workflow und frag nicht: Welche KI kann das komplett. Frag: Welcher Teil macht es gerade teuer, langsam oder riskant. Genau dort anfangen. Wenn ihr so einen Engpass bei euch gefunden habt, schreibt mir eine Mail, die Adresse steht in den Shownotes. Oder kommentiert direkt auf Spotify oder Apple Podcasts, welche Arbeitsschicht euch gerade am meisten nervt. Pfiat euch und bis morgen, eure Lissy.