Vitalij Mik: deepseek

Goose statt Crush: weniger Tokens für die gleiche Arbeit

2026-10-31T00:00:00+00:00

Jetzt, wo ich auf DeepSeek umgestiegen bin und genauer sehen kann, wofür ich Tokens ausgebe, wollte ich mir mal die Agenten anschauen, die ich verwende. Bei Codex hatte ich Codex CLI und Crush zusammen benutzt. Mir ist immer wieder aufgefallen, dass ich mit Crush relativ früh an mein Stunden-Limit gekommen bin.

Tatsächlich haben sich auch andere mit der Frage des Tokenverbrauchs beschäftigt, und so bin ich auf den Artikel hier gekommen: https://arxiv.org/pdf/2607.22585

Hier wird goose CLI als Basis genommen und mit OpenHands und OpenCode verglichen. Der Beitrag ist von Juni 2026, es kann also sein, dass das zum Zeitpunkt, wo du es liest, nicht mehr stimmt.

Auf jeden Fall fand ich interessant, dass goose CLI 40-mal weniger Tokens verbraucht als OpenCode. Damit kann man für das gleiche Geld die gleiche Leistung erbringen.

Warum ich bei goose wieder vorbeigeschaut habe

Goose kannte ich schon früher. Ich habe es immer wieder lokal mit einem 9B-Modell getestet, leider funktionierte es damals nicht so gut. Das 9B-Modell konnte die Toolcalls in goose nicht besonders gut umsetzen, oft gab es Fehler und Endlosschleifen.

Anschließend habe ich dann Crush gefunden, und damit konnte ich mit einem 9B-Modell lokal arbeiten. Das Problem war aber, dass ich nicht nur ein 9B-Modell hatte, sondern auch nur ein ca. 42k-Token-Fenster. Meine Grafikkarte RTX 3060 Ti hat nur 8 GB VRAM, und ich bin da eingeschränkt.

Das heißt, Crush konnte zwar besser die Tools aufrufen und Dateien lesen, aber ich hatte dafür immer wieder Context-Zusammenfassungen, wo dann Inhalte aus dem Kontext geflogen sind. Es war also nur möglich, kleine Dinge umzusetzen.

Zum aktuellen Zeitpunkt kann man also nichts Wesentliches mit wenig VRAM lokal umsetzen.

Der erste Test: ein einfaches „Hi“

Wie dem auch sei, ich habe mir also goose installiert und als Erstes einfach nur „Hi“ getestet, um den initialen Tokenverbrauch zu messen.

Bei Crush habe ich ca. 12k Tokens benutzt.

Man muss hier aber bedenken, dass ich die Crush-Toolcalls schon eingeschränkt habe. Ich habe zum Beispiel alle LSP-Tools deaktiviert, da ich lokal kein LSP verwende.

Und hier haben wir goose:

4k Tokens bei einem einfachen „Hi“. Sind auf jeden Fall dreimal so wenig.

Die komplexere Aufgabe

Als Nächstes wollte ich eine komplexere Aufgabe umsetzen, damit ich den Vergleich zu gestern habe. Ich ließ goose das, was ich vorher über bash installiert hatte, als Paket zu Void hinzufügen. Dazu kam noch das Paket lightpanda. Das ist ein Headless-Browser für KI, damit man auch Inhalte von Webseiten laden kann, die JavaScript benötigen, ohne extra Chrome oder Firefox im Headless-Modus zu starten.

Das Ganze war ein Rust- und Zig-Build. Mir ist in der Statistik in DeepSeek aufgefallen, dass man mit goose wirklich weniger Tokens benutzt und mehr Output-Tokens generiert werden.

Output-Tokens sind eigentlich die wichtigen Tokens. Das ist ja das Wissen, das ausgegeben wird.

Ich bin mir noch unsicher, wie ich die Statistik selbst bewerten soll. Ich habe weniger Tokens gebraucht für eine komplexe Aufgabe, aber genauso viel bezahlt, weil eben mehr Output-Tokens kamen. Vielleicht kann man das noch mit dem caveman skill besser steuern.

Ich sammle aktuell nur Erfahrungen, konkret kann ich noch nichts sagen.

Was ich von einem Agenten erwarte

Eigentlich habe ich relativ einfache Anforderungen an den Agenten:

Er soll wenige Tokens verbrauchen
Er soll konfigurierbar und erweiterbar sein
Er soll meine Provider unterstützen
Er soll wenig RAM verbrauchen
Er soll gut aussehen und gut bedienbar sein

Goose vs. Crush

Goose verbraucht bei mir ca. 240 MB RAM, während Crush nur bei 88 MB liegt. RAM-Nutzung ist relevant, wenn Subagenten gestartet werden. Codex war bei 300 MB. Hier gewinnt Crush natürlich.

Konfigurierbar und erweiterbar sind beide. Aber ich glaube, in goose könnte ich sogar den System-Prompt anpassen. Bei Crush geht es nicht. Ich kann höchstens eigenen Text dazuschreiben. Ich würde hier noch sagen, es ist ein Unentschieden, da ich mich mit goose noch nicht so stark beschäftigt habe.

Goose unterstützt DeepSeek direkt als Provider, während man es bei Crush manuell konfigurieren musste. Es gibt zwar DeepSeek, aber das wird über irgendeinen Open Router angeboten und nicht das direkte. Hier ist goose dann besser.

Vom Aussehen her gewinnt Crush. Es sieht viel besser aus. Tool-Ausgaben werden versteckt, man sieht im Output am Ende nur das, was einen wirklich interessiert. Bei goose wird alles in der Konsole ausgegeben und man muss ständig scrollen, das ist nicht besonders schön.

Goose hat noch zwei weitere Vorteile. Es gibt goose Desktop, das im Grunde wie Claude oder Codex Desktop aussieht. Wenn man eher so ein Interface bevorzugt, hat man die Möglichkeit, es zu nutzen.

Außerdem hat goose ACP-Unterstützung. Ich kann goose im Editor Zed konfigurieren und benutzen. Dann wäre vermutlich die Tool-Ausgabe und Übersichtlichkeit besser als bei der CLI-Lösung.

Crush hat noch den Nachteil, dass es in jedem Projekt einen .crush-Ordner anlegt, mit einer SQLite-Datenbank und weiteren Dingen. Goose legt das irgendwo zentral ab. Wenn ich es mal löschen will, lösche ich einen Ordner und fertig.

Fazit

Also hat alles bisher Vor- und Nachteile. Ich denke, ich muss es mehr in meinen Projekten einsetzen, um ein besseres Urteil zu fällen.

Eigentlich bevorzuge ich Crush auf der CLI. Vermutlich wäre das Beste, Crush zu forken und den System-Prompt sowie die Tool-Beschreibung für Bash zu verändern. Dann würde ich direkt weniger Tokens verbrauchen. Aber ich denke, ich werde erstmal Goose über den Zed-Editor als ACP einsetzen und schauen, wie gut es funktioniert.

Weiterführende Links

Von Codex-Abo zu DeepSeek Pay-per-Use: mein Fazit nach dem ersten Tag

2026-10-30T00:00:00+00:00

Stell dir vor, du zahlst jeden Monat 23 €, um in deiner Freizeit mit KI zu programmieren, und nach ein paar Stunden bist du gezwungen, eine Pause einzulegen, weil dein 5-Stunden-Limit erreicht ist. Wenn du aber mal einen Tag nichts machst, wird dir dieses Limit nicht gutgeschrieben.

Wenn du also einen vollen Monat lang nicht programmierst, zahlst du trotzdem weiterhin 23 €. Das hat mich aktuell so derart frustriert, dass ich mich mal nach Alternativen umgeschaut habe.

Mein Use Case ist eigentlich ein einfacher. Nach der Arbeit so ab 17 Uhr arbeite ich ein paar Stunden an einem Projekt. Die KI entscheidet nicht für mich, sie muss nicht über Nacht laufen. Sie soll einfach nur das machen, was ich will. Also nichts Intensives. Ich bin kein Poweruser. Aber dennoch bin ich besonders am Wochenende immer wieder an mein Limit gekommen.

Ich habe mir meine Statistik angeschaut: In den letzten 7 Tagen habe ich ca. 72 Millionen Tokens benutzt. Leider sieht man in der Oberfläche von Codex nicht, ob das gecachte Tokens waren und wie sich die Summe auf Input, Cache und Output verteilt.

Es gab auch Tage, an denen ich nichts getan habe, und man hatte die ganze Zeit im Hinterkopf: „Wenn ich heute das Limit nicht aufbrauche, dann ist das Geld weg.”

Ich habe mir also mal die Benchmarks der anderen Modelle angeschaut. Vorher hatte ich GPT6 Luna benutzt, das war für meine Zwecke völlig ausreichend. In der Liste habe ich dann DeepSeek V4.1 Flash gesehen, und es war besser als Luna bewertet.

Auf der Seite von DeepSeek hat mich besonders die Preisliste überzeugt. Du zahlst nur, was du verbrauchst, und außerhalb der Arbeitszeiten in China ist es günstiger. Da ich abends programmiere, liege ich automatisch außerhalb dieser Zeit.

Ein weiterer Punkt war, dass ich nicht direkt ein Abo abschließen muss. Einfach eine Art Prepaid-Konto: Ich lade eine Summe auf, und wenn sie aufgebraucht ist, kann ich die KI nicht mehr nutzen. Fette Rechnungen können so gar nicht erst entstehen. Ich habe erst mal 2 € aufgeladen und konnte es damit ausprobieren.

Der erste echte Test: Pakete unter Void Linux

Heute wollte ich mein Void-Linux-System etwas aktualisieren, und die Pakete waren dafür ein guter Test-Use-Case.

Bei Void Linux klont man das Paket-Repository lokal über Git. Pro Paket gibt es eine Template-Datei, in der die Version, die Art des Builds und die Build-Abhängigkeiten stehen. Außerdem steht dort zu jedem Paket der GitHub-Pfad.

Ich ließ mir also Code generieren. Der Code enthält eine feste Liste an Paketen, die ich aktualisieren will. Für diese Pakete wird die Template-Datei herausgesucht und die aktuelle Version ausgelesen. Danach wird auf GitHub beim Paket geschaut, ob es eine neuere Version gibt. Wenn ja, wird die neue Version ins Template geschrieben, anschließend der Build-Prozess angestoßen und danach die Build-Abhängigkeiten wieder gelöscht.

Heute habe ich OBS auf die Version 33.0 aktualisiert. Die neue Version braucht FFmpeg 8, das Void gar nicht hat. Also hat die KI mir ein neues Template angelegt, damit ich OBS über das Skript neu bauen kann. Natürlich wurde der Build-Prozess vorher lokal getestet, und für das Template hat sie die richtigen Dev-Abhängigkeiten ermittelt und eingetragen.

Den Code kannst du hier finden: https://gist.github.com/BlackScorp/4b2cbdd0305a012501fc732f6e2a7347

Du siehst also, es war etwas mehr als „färbe den Button grün”.

Was das am Ende gekostet hat

Ich glaube generell, dass man sich auf die Benchmarks mittlerweile nicht mehr verlassen kann. Alles, was in der Größenordnung von Qwen 3.8 27B oder darüber aufgelistet ist, reicht für die normalen Tasks völlig aus.

Ich vergleiche die Benchmarks gern mit der Formel 1. In der Regel reicht dir auch ein Fiat, um von A nach B zu kommen. Die Formel-1-Autos sind für den normalen Verbraucher nicht relevant.

Mit dem heutigen Task habe ich etwas über 22 Millionen Tokens verbraucht, und das hat mich 14 Cent gekostet. Bei Codex wären es bei 23 € auf 30 Tage gerechnet 0,77 € pro Tag. Das heißt, ich konnte vermutlich am Ende des Tages mehr machen für weniger Geld.

Und wenn ich mal nichts tue, kostet es mich auch nichts. Natürlich ist das nur ein einziger Tag, ich muss da noch mehr Erfahrung sammeln. Bisher ist es aber doch positiv.

Ein negativer Punkt

Ich habe den Agenten „Crush” verwendet und habe das Gefühl, dass damit irgendwie mehr Tokens verbrannt werden. Mit dem Agenten bin ich bei Codex schneller an das Limit gekommen als mit der CLI von Codex selbst. Das werde ich morgen mal mit dem Client von DeepSeek selbst ausprobieren.

Und ich kann keine Bilder über DeepSeek generieren, nur anschauen und verstehen kann es sie. Ich denke aber, dass ich für diesen Fall einfach Google Gemini verwenden werde. Da habe ich 100 freie Bilder am Tag, die ich generieren kann, das sollte reichen.

Fazit

Wenn du einen ähnlichen Use Case wie ich hast, dann probiere DeepSeek mal aus. Ein Prepaid-Guthaben macht den Einstieg leicht, und man sieht direkt, was ein einzelner Task wirklich kostet.