Headless UI im Agenten-Zeitalter: Weniger Tokens sind ein Symptom, nicht das Auswahlkriterium

Beim Web-Rewrite von x.com hat X die interne Bibliothek XDS auf Base UI und Tailwind gebaut. Das habe ich in der Note zum Rewrite festgehalten. Base UI hat mich dabei interessiert, und es hat eine ältere Frage wieder aufgeworfen.

In Firmenprojekten habe ich oft selbst UI-Komponenten gebaut, meist auf Material UI von Google. Es gab selten etwas Passendes von der Stange, und jede Firma wollte wiedererkennbar aussehen. Damals haben Vorlieben, Wartbarkeit und frei wählbares Styling die Wahl bestimmt. Meine These heute: Künftig wird entscheidender, welche Lösung weniger Tokens für Coding-Agenten braucht. Ergänzend sehe ich die Agent-Tauglichkeit als Kern – je einfacher, desto besser – und vermute, dass bessere Tauglichkeit mit weniger Tokens einhergeht. Das ist eine Hypothese, keine Messung.

Weniger Tokens sind ein Symptom

Token-Effizienz ist morgen ein relevantes Kriterium, aber nicht isoliert entscheidender als Wartbarkeit, Barrierefreiheit und eigenes Styling. Tokens sind oft die Folge davon, wie gut ein Agent mit einer Bibliothek zurechtkommt:

• Trainingsdaten: Bekannte Bibliotheken wie shadcn, Radix oder Tailwind kennt ein Modell typischerweise besser. Bei neuen oder seltenen Libs liest es nach oder halluziniert.
• Code im eigenen Repo gegen eine npm-Blackbox: Bei Copy-Paste-Ansätzen wie shadcn oder Spartan sieht der Agent den Quelltext. Das kann helfen, kostet aber Kontext.
• Maschinenlesbare Docs: Eine llms.txt oder ein MCP-Server kann dem Agenten den Weg zeigen, ohne dass er die Codebasis durchsuchen muss.
• Explizite, lokal verständliche APIs, die sich aus dem Einsatzort erschließen.
• Tailwind im Markup ist tokenlastig, erspart aber den Sprung in CSS-Dateien. Ob das unterm Strich weniger Tokens bedeutet, habe ich nicht gemessen.

Wartbarkeit und Barrierefreiheit bleiben wichtig, weil Agenten Fehler dort schlecht merken.

Der naheliegende Gegenfall zu meiner Folgerung „je tauglicher, desto weniger Tokens“ sind gerade die Copy-Paste-Bibliotheken. Der Agent kann den Code lesen und kommt oft besser zurecht, braucht dafür aber mehr Kontext. Ob die Tokens pro erfolgreicher Komponente dann sinken oder steigen, ist offen.

Die Landschaft, kompakt

Ein unabhängiger Vergleich – dieselbe Komponente, mehrere UI-Bibliotheken, Tokens und Erfolg – liegt nicht vor. Die Übersicht ist deshalb eine Einordnung, kein Ranking. Sternzahlen und genaue Versionsnummern lasse ich weg, die ändern sich zu schnell.

Bei Angular Aria habe ich die zwölf Muster in der offiziellen Doku selbst gesehen. Die Live-Seite der v22-Ankündigung hat beim Abruf mit 403 geantwortet; den production-ready-Status übernehme ich aus dem Ankündigungstext vom 3.6.2026. Den von PrimeUI genannten MCP-Server habe ich nicht einzeln geprüft, deshalb steht er nicht in der Tabelle.

Was bisher gemessen wurde

Nolan Lawson hat in „The AI cost of JavaScript frameworks“ (28.10.2026) Tokens und Kosten über zwölf JS-Frameworks gemessen. Tailwind und Komponentenbibliotheken hat er ausdrücklich ausgenommen. Die Ausreißer erklärt er mit fehlenden Trainingsdaten und mit der Code-Menge, nicht mit einer UI-Lib. Außerdem nutzten seine Agenten vorhandene MCPs und Skills nur unregelmäßig; das Nuxt-MCP etwa kam in keinem Lauf vor. Die Einordnung seiner Zahlen steht in der Note zu den Angular-Kosten.

Näher an der Frage nach maschinenlesbaren Docs ist die Messung von EDL (8.9.2026). Eine Query-Oberfläche gegen eine undokumentierte Codebasis senkte bei Sonnet 5 die Tokens um 31 Prozent und die Schritte um 39 Prozent (Smarty-Design-System, zehn Aufgaben). Das ist ein Lauf pro Zelle, und die Varianz ist hoch: Dieselbe Aufgabe schwankte in einer Wiederholung zwischen 2,7 und 5,9 Millionen Tokens. EDL schreibt selbst, die Prozentwerte seien als Richtung zu lesen. Bei Haiku 4.5 lag der Nutzen eher in der Korrektheit als in den Kosten. Gemessen wurde hier nicht die Wahl einer UI-Bibliothek, sondern der Unterschied zwischen einer undokumentierten Basis und einer abfragbaren Schnittstelle.

Was fehlt, ist genau der Vergleich, den ich bräuchte: dieselbe Komponente, mehrere Bibliotheken, Tokens und Erfolg.

Was das für bmline.de heißt

bmline.de läuft auf Nuxt und nutzt bereits Nuxt UI: Das Paket @nuxt/ui steht in der package.json, das Modul @nuxt/ui in der nuxt.config.ts. Dazu kommen offizielles MCP und llms.txt. Das ist eine gute Ausgangslage, aber keine Aussage darüber, ob ein Agent damit weniger Tokens braucht oder zuverlässiger landet als mit Reka UI oder shadcn-vue.

Eine mögliche Vertiefung wäre ein kleines Lab: dieselbe interaktive Komponente, etwa ein Dialog oder eine Combobox, mit demselben Agent-Setup einmal auf Reka UI, einmal auf shadcn-vue und einmal auf Nuxt UI bauen lassen, mit denselben harten Checks, und dann die Tokens pro erfolgreicher Komponente vergleichen. Das wäre auch der Ort, die Copy-Paste-Gegenhypothese zu prüfen. Geplant ist das, durchgeführt nicht. Ergebnisse gibt es deshalb keine.

Quellen

• Yagiz Nizipli: Rebuilding the global town square from scratch, 4.11.2026 (Anlass: XDS auf Base UI und Tailwind)
• About Base UI
• shadcn/ui: July 2026 – Base UI as the Default
• Angular: Angular Aria – Overview und Announcing Angular v22, 3.6.2026
• Spartan: MCP Server
• PrimeNG: Migration to v22
• shadcn-vue MCP Server
• Nuxt UI: MCP Server und llms.txt
• Nolan Lawson: The AI cost of JavaScript frameworks, 28.10.2026
• Alessandro Longo / EDL: Benchmark: Do AI coding agents work better with a machine-readable design system?, 8.9.2026