Caveman und Ponytail für die GreenPT-API

Wenn du dieses Jahr mit KI-Coding-Agents arbeitest, ist dir wahrscheinlich etwas Seltsames aufgefallen: Je fortschrittlicher diese Modelle werden, desto mehr reden sie. Jede Frage löst drei Absätze Erklärung aus. Jeder Code-Fix kommt mit Vorrede, Erläuterung und Zusammenfassung. Das Modell will hilfreich sein. Es ist hilfreich, indem es geschwätzig ist. Und du zahlst für jedes Wort.

Zwei Open-Source-Projekte haben still verändert, wie Entwickler darüber denken. Heute bringen wir beide direkt in die GreenPT-API.

Das Problem: Agents, die zu viel erklären, zu viel bauen und zu viel kosten

Wer KI-Coding-Tools in großem Maßstab betreibt, weiß, dass die Rechnung nicht aufgeht. Modelle der GPT-5-Klasse erzeugen Output für etwa 10 bis 15 US-Dollar pro Million Tokens. Ein einzelner Senior-Entwickler, der den ganzen Tag einen Coding-Agent laufen lässt, verbraucht in einer Woche Millionen Tokens, größtenteils Erzählung, Boilerplate und defensiv erzeugten Code.

Es gibt einen zweiten Kostenfaktor, der weniger Beachtung findet: Energie. Jedes Output-Token ist ein Forward-Pass durch ein großes Modell. Weniger Output-Tokens bedeuten weniger Rechenleistung, weniger Strom, weniger CO2. Für KI-Anbieter ist Geschwätzigkeit im Grunde eine versteckte Umweltabgabe, unbemerkt an Kunden weitergereicht, die wenig dagegen tun können, außer auf kleinere (und schlechtere) Modelle umzusteigen.

Zwei Entwickler aus der Open-Source-Community entschieden, dass sich das auf Ebene der Sprache lösen lässt, nicht auf Ebene des Modells.

Caveman: dieselbe Antwort, viel weniger Worte

Julius Brussee begann mit einer einfachen Beobachtung: Das meiste, was ein KI-Coding-Agent erzeugt, ist Prosa, kein Code. Wenn man die Prosa komprimieren kann, ohne den Code anzufassen, holt man einen großen Teil der Gesamtersparnis heraus.

Seine Antwort war Caveman, ein Regelsatz, der den Agent anweist, zu schreiben wie, nun ja, ein Höhlenmensch. Statt “Du solltest das Objekt wahrscheinlich in useMemo einwickeln, da bei jedem Render eine neue Referenz entsteht und das Reacts referenzielle Gleichheitsprüfung aushebelt,” bekommst du “Neue Objekt-Ref pro Render. In useMemo einwickeln.”

Dieselbe Antwort. Etwa ein Neuntel der Lesezeit. Und entscheidend: Codeblöcke, Fehlermeldungen, Tool Calls und Diffs bleiben Byte für Byte erhalten. Caveman komprimiert die Verpackung, nicht den Inhalt.

Die gemessene durchschnittliche Ersparnis beträgt 65% weniger Output-Tokens bei chat-artigen Prompts (Bandbreite 22 bis 87%). Ein Paper vom März 2026, das Brussee zitiert, fand heraus, dass Kürze in KI-Antworten die Genauigkeit bei einigen Benchmarks sogar um rund 26 Punkte verbesserte. Weniger Rauschen macht das Signal sichtbarer.

Caveman kommt als Skill für Claude Code, Codex, Cursor, Windsurf, Cline, Copilot und rund 40 weitere Agents. Es ist MIT-lizenziert, hat keine Telemetrie und steht inzwischen bei über 95k Sternen auf GitHub. Brussee ist zudem erfrischend ehrlich über die Kompromisse: Caveman komprimiert nur Output-Tokens, nicht Input- oder Reasoning-Tokens, und fügt pro Runde rund 1 bis 1,5k Tokens Overhead hinzu. Bei überwiegend Code schrumpfen die Einsparungen. Bei überwiegend Prosa sind sie enorm.

Ponytail: der Code, den du nicht schreibst

Dietrich Gebert wählte einen anderen Ansatz. Wo Caveman darauf zielt, wie der Agent redet, zielt Ponytail darauf, was der Agent baut. Die Kernidee: Senior-Entwickler sind faul. Nicht im schlechten Sinne. In dem Sinne, dass sie wissen: Der beste Code ist der Code, den man nicht schreibt.

Ponytail erzwingt eine Entscheidungsleiter, bevor der Agent überhaupt etwas schreibt:

1. Muss das existieren? (YAGNI zuerst)
2. Existiert es schon in dieser Codebase? (Wiederverwenden)
3. Deckt die Standardbibliothek es ab? (Stdlib nutzen)
4. Deckt eine native Plattformfunktion es ab? (Nutzen)
5. Löst eine installierte Dependency es? (Nutzen)
6. Geht es in einer Zeile? (Eine Zeile daraus machen)

Nur wenn die Antwort auf alle sechs Nein lautet, schreibt der Agent neuen Code. Und selbst dann: minimal lauffähig.

Das Ergebnis sind im Schnitt rund 54% weniger erzeugter Code, bis zu 94% bei aggressivem Overengineering. Ponytail bewahrt 100% der Sicherheits- und Validierungslogik, oft das Erste, was übereifrige Agents zu “vereinfachen” versuchen. Gebert brachte es im Juni 2026 heraus, und es wuchs auf über 95k Sterne, eines der am schnellsten wachsenden Coding-Tools des Jahres.

Wie Caveman funktioniert es mit 13+ Agents über Plugins, Hooks und Rule Files, und es ist MIT-lizenziert.

Warum wir beide in die API-Schicht gebracht haben

Die Sache mit Skills, Plugins und Rule Files: Jemand muss sie installieren. Konfigurieren. Im Team aktuell halten. Dafür sorgen, dass neue Mitarbeitende wissen, dass es sie gibt. Das ist Reibung, und Reibung tötet die Verbreitung.

Wir haben uns eine einfache Frage gestellt: Was, wenn die Kompression direkt am API-Endpoint passiert, sodass es nichts zu installieren gibt?

Genau das haben wir heute veröffentlicht. GreenPT bietet jetzt drei neue Endpoints auf Basis von GLM-5.2:

• glm-5.2-caveman wendet Brussees Regelsatz nativ an (-22% bis -87% Output-Tokens)
• glm-5.2-ponytail wendet Geberts Regelsatz nativ an (-22% bis -94% Output-Tokens)
• glm-5.2-honey kombiniert beide, dieselbe Balance wie unser Honey-Skill, für gemischte Prosa-und-Code-Workloads (-6% bis -77%)

Jeder kommt in den Intensitäten -lite, default und -ultra. Keine zusätzlichen Parameter, keine Header, keine SDK-Gymnastik. Du tauschst das Modell-ID in deinem bestehenden OpenAI-kompatiblen Request, und es passiert einfach:

{
  "model": "glm-5.2-ponytail",
  "messages": [{ "role": "user", "content": "Füge dieser Fetch-Call einen Retry mit Backoff hinzu." }]
}

Weil das Endpoint OpenAI-kompatibel ist, passt es direkt in OpenCode, Cursor, Claude Code und jedes Coding-Tool, das die OpenAI-API spricht. Die Kompression ist eingebaut.

Warum das mehr bedeutet als die Token-Rechnung

Für uns bei GreenPT ist das die ganze Mission, verdichtet in ein Release: dieselbe Antwort, weniger Energie.

Das Preismodell ändert sich nicht. Du zahlst weiterhin pro Token, zum selben CO2 pro Token wie beim regulären GLM-5.2. Aber weil es weniger Output-Tokens gibt, sinkt deine Gesamtrechnung. Deine Antwortzeit sinkt. Dein Energieverbrauch sinkt. Und wir geben die gesamte Ersparnis weiter, weil die Ersparnis real ist, kein Rabatt, den wir anbieten, um Volumen zu verschieben.

Wir veröffentlichen CO2-Kennzahlen pro API-Call standardmäßig bei GreenPT. Mit diesen Endpoints wird diese Zahl spürbar niedriger, und sie ist ab dem ersten Tag in deinem Dashboard messbar.

Partnerschaft mit den Entwicklern

Wir sind der erste gelistete Sponsor von Ponytail, und beide Regelsätze laufen nativ auf unseren Endpoints, mit voller Nennung ihrer Urheber. Julius Brussee und Dietrich Gebert haben diese Tools offen gebaut, unter MIT-Lizenz gestellt und für alle verfügbar gemacht. Das verdient Anerkennung, nicht nur Nutzung.

Wenn du ihre Tools direkt mit deinem eigenen Agent-Setup nutzen willst, ermutigen wir dich ebenfalls dazu. Was wir getan haben, ist, dieselben Prinzipien für alle verfügbar zu machen, die unsere API bereits nutzen, ohne Installationsschritte. Dieselbe Idee, anders geliefert.

Das größere Bild

Es gibt eine Denkrichtung in der KI-Branche, die annimmt, dass Effizienz von größeren Modellen, besserer Hardware oder cleveren Inferenztricks kommt. Und manchmal stimmt das. Aber einige der größten Gewinne, die gerade verfügbar sind, stecken nicht im Modell, sie stecken im Output. Jedes überflüssige Wort, das ein Agent erzeugt, kostet Geld und Energie, die nicht hätten ausgegeben werden müssen.

Caveman und Ponytail haben das auf Ebene der Entwickler-Tools bewiesen. Wir bringen es auf Ebene der Infrastruktur.

Wenn du die API von GreenPT nutzt, kann das Ändern eines einzigen Strings in deinem Request deine Output-Tokens um bis zu 70% senken. Das ist kein Rabatt. Das ist einfach, was passiert, wenn das Modell aufhört, zu viel zu erklären.

Ausprobieren

• Dokumentation Kompressionsmodelle
• Caveman auf GitHub
• Ponytail auf GitHub