Claude Code sendet 33.000 Token, bevor es den Prompt liest, OpenCode 7.000 Token

• Bei Messungen an derselben Modell-, Maschinen- und Aufgaben-Konstellation direkt an der API-Grenze lag der feste Overhead der ersten Anfrage mit Sonnet 4.5 bei rund 32.800 Token für Claude Code und rund 6.900 Token für OpenCode – ein Unterschied um den Faktor 4,7; bei Fable 5 verringerte sich das auf etwa den Faktor 3,3
• Der Großteil der Differenz entsteht durch die Tool-Schemata. Claude Code verwendete für 27 Tool-Definitionen rund 24.000 Token, OpenCode für 10 Tools rund 4.800 Token; selbst bei komplett deaktivierten Tools lagen die System-Prompts noch bei etwa 6.500 bzw. 2.000 Token
• In einer realen Konfiguration fügte eine 72-KB-Befehlsdatei pro Anfrage rund 20.000 Token hinzu, und ein einzelner kleiner MCP-Server nochmals etwa 1.000–1.400 Token, sodass allein die erste Anfrage 75.000–90.817 Token erreichen konnte
• Bei derselben Dateizusammenfassungs-Aufgabe erzeugte Claude Code 5,9- bis 54-mal mehr Cache-Schreibvorgänge als OpenCode; wurde die Arbeit auf zwei Sub-Agenten verteilt, stieg der Verbrauch von 121.000 Token bei direkter Ausführung auf 513.000 Token, also um den Faktor 4,2
• Allein aus dem festen Overhead lässt sich aber nicht auf die Gesamtkosten schließen. Bei einer mehrstufigen Aufgabe nutzte Claude Code parallele Tool-Aufrufe und kam mit 3 Requests auf rund 121.000 Token, während OpenCode mit 9 seriellen Aufrufen auf rund 132.000 Token kam

---

Messmethode an der API-Grenze

• Zwischen Claude Code und OpenCode wurde ein Logging-Proxy platziert, der die exakten JSON-Requests des Harnesses sowie die von der API zurückgegebenen Nutzungsblöcke aufzeichnete
  • Der Request-Body enthielt System-Blöcke, Tool-Schemata und Nachrichten
  • Die Nutzungsdaten umfassten Eingabe-Token, Cache-Schreib-/Lesevorgänge und Ausgabe-Token
  • Die erfassten Request-Bodies dienten als tatsächlich gesendeter Inhalt, die API-Nutzungsblöcke als Grundlage für die reale Abrechnung
• Für den Grundvergleich wurden Claude Code 2.1.207 und OpenCode 1.17.18 verwendet; beide waren auf claude-sonnet-4-5 mit Stand Juli 2026 festgelegt
  • Fester Overhead, Cache-Verhalten und Teile der mehrstufigen Aufgaben wurden zusätzlich mit claude-fable-5 erneut ausgeführt
  • Die Standardwerte wurden in einem neuen Konfigurationsverzeichnis, ohne MCP-Server, Benutzereinstellungen oder Speicher und in einem leeren Workspace ohne Befehlsdatei isoliert
• Drei Aufgaben dienten zur Messung unterschiedlicher Kostenstrukturen
  • T1 isolierte den festen Overhead mit Reply with exactly: OK und wurde pro Harness dreimal ausgeführt
  • T2 ließ vorbereitete Dateien lesen und zusammenfassen
  • T3 führte einen Ablauf aus Schreiben, Ausführen, Testen und Korrigieren anhand von FizzBuzz und einem Prüfskript durch
• Um die System-Prompts ohne Tool-Schemata zu vergleichen, wurde bei Claude Code --tools "" und bei OpenCode "tools": {"*": false} verwendet
• Ein lokales LLM-Gateway fügte pro Request einen festen Envelope-Overhead von rund 6.200 Token hinzu; dieser wurde korrigiert und aus den Messwerten herausgerechnet
  • Komponentenwerte wurden aus den erfassten Request-Bodies berechnet, die das Gateway nicht verändern konnte
  • Für die Umrechnung von Zeichen in Token wurde je nach Harness ein Verhältnis von 1 Token pro 4,1–4,4 Zeichen verwendet, gemessen mit kaltem Cache

Tool-Schemata treiben den Basis-Overhead nach oben

• In der ersten Anfrage auf den 22 Zeichen langen T1-Prompt sendete Claude Code rund 32.800 Token, OpenCode rund 6.900 Token
  • Der Claude-Code-System-Prompt bestand aus 3 Blöcken und 27.344 Zeichen, der von OpenCode aus 1 Block und 9.324 Zeichen
  • Die 27 Tool-Schemata von Claude Code umfassten 99.778 Zeichen, die 10 Tools von OpenCode 20.856 Zeichen
  • Claude Code fügte vor dem eigentlichen Prompt einen 7.997 Zeichen langen <system-reminder>-Block mit Agententyp, verfügbaren Skills und Benutzerkontext ein
  • OpenCode sendete System-Block, 10 Coding-Tools und den Benutzer-Prompt ohne ein separates Scaffold für die erste Nachricht
• Bei beiden machte die Tool-Definition den größten Anteil aus
  • Von den rund 33.000 Token bei Claude Code entfielen etwa 24.000 auf Tool-Definitionen
  • Von den rund 6.900 Token bei OpenCode entfielen rund 4.800 auf Tool-Definitionen
  • Zu den Tools von Claude Code gehörten neben Coding-Funktionen auch CronCreate, Monitor, die Task-Familie, Verwaltung von Arbeitsbäumen, Push-Benachrichtigungen sowie Hintergrund-Agenten- und Orchestrierungsfunktionen
• Entfernt man alle Tools, bleibt bei Claude Code ein System-Prompt mit 26.891 Zeichen und etwa 6.500 Token, bei OpenCode mit 8.811 Zeichen und etwa 2.000 Token
  • Bei beiden Harnesses schrumpfte der Prompt leicht, wenn Tools deaktiviert wurden
  • Die verbleibende Differenz stammt aus Verhaltensanweisungen wie Tonalität, Sicherheitsrichtlinien, Regeln fürs Aufgabenmanagement und Umgebungsinformationen
• Mit Fable 5 verkürzte Claude Code den Prompt modellabhängig, wodurch sich der Abstand auf etwa den Faktor 3,3 verringerte
  • Die Systemanweisungen sanken von 27.787 Zeichen bei Sonnet auf 10.526 Zeichen bei Fable
  • Bei gleichbleibenden 27 Tools schrumpften auch die Schemata von 99.778 auf 82.283 Zeichen
  • Die OpenCode-Requests waren bei beiden Modellen bytegenau identisch

Gesamtverbrauch variiert je nach Aufgabenform

• Bei T2, dem Lesen und Zusammenfassen einer Datei, lieferten beide Harnesses korrekte Ergebnisse, aber mit unterschiedlicher Request-Struktur
  • Claude Code nutzte 6 HTTP-Requests und kumuliert rund 199.000 Eingabe-Token
  • OpenCode kam auf 4 Requests und rund 41.000 Token sowie zusätzlich 1 Haiku-Aufruf zur Generierung eines Sitzungstitels
  • Der Großteil der Nutzung bestand aus Cache-Lesevorgängen, die nur zu einem Zehntel des Eingabepreises berechnet wurden
• Trotz Cache-Rabatt steigen Cache-Schreibkosten der ersten Anfrage, Cache-Lesekosten pro Turn und die Belegung des Kontextfensters mit der Größe der Payload
  • Eine Basis von 33.000 Token belegt schon vor jedem eigentlichen Code etwa ein Sechstel eines 200.000-Token-Fensters
• Bei T3, der Aufgabe Schreiben-Ausführen-Testen-Korrigieren, glich die Art der Tool-Aufrufe den Unterschied im Basis-Overhead aus
  • Claude Code bündelte 2 Dateischreibvorgänge und 2 Skriptausführungen in einem parallelen Tool-Roundtrip und kam so auf 3 Modell-Requests und kumuliert rund 121.000 Eingabe-Token
  • OpenCode rief pro Turn nur ein Tool auf und kam damit auf 9 Requests plus 1 Titel-Request sowie kumuliert rund 132.000 Token
  • Die gesamte Eingabe ergibt sich grob aus Baseline pro Request mal Anzahl der Requests plus dem Wachstum der Unterhaltung
• Im Lauf der Unterhaltung erhöhte Claude Code die Zahl der <system-reminder>-Blöcke von 3 im ersten Turn auf 4 zum Zeitpunkt des ersten Tool-Roundtrips
• Bei OpenCode lag die zusätzliche Payload pro Turn bei rund 400–2.200 Zeichen und wuchs nur mit dem Gesprächsinhalt

Reale Konfigurationen fügen zusätzliche Token hinzu

• Wurde dem Produktiv-Repository ein 72-KB-AGENTS.md hinzugefügt, stiegen bei beiden Harnesses die Requests um mehr als 20.000 Token pro Anfrage
  • Bei OpenCode stieg der Messwert von 13.152 auf 33.336 Token
  • Bei Claude Code von 39.005 auf 59.243 Token
  • Claude Code 2.1.207 ignorierte AGENTS.md; erst nach Umbenennung in CLAUDE.md wurde die Datei in die erste Benutzernachricht eingefügt
  • OpenCode las beide Dateinamen und fügte sie in den System-Prompt ein
  • Ohne Prüfung des tatsächlich erkannten Dateinamens kann eine Befehlsdatei stillschweigend ignoriert werden
• Ein öffentlicher kleiner MCP-Server fügte pro Request und Server rund 1.000–1.400 Token hinzu
  • 5 Server addierten 4.900 Token zur Claude-Code-Payload und 6.967 Token zum OpenCode-Messwert
  • Die Tool-Anzahl stieg bei Claude Code von 27 auf 69, bei OpenCode von 10 auf 52
  • Produktivserver mit umfangreichen APIs können noch größere Schemata senden
  • Der Print-Modus von Claude Code ignorierte projektlokale .mcp.json stillschweigend ohne explizites --mcp-config; deshalb muss an der API-Grenze geprüft werden, ob die Verbindung tatsächlich besteht
• Story-basierte Workflow-Frameworks wie BMAD erweitern Slash-Befehle um große Templates mit Personas, Protokollen und Checklisten
  • Das im Experiment verwendete Template mit 8.405 Zeichen entsprach selbst nur rund 2.100 Token, wurde aber in den Gesprächsverlauf aufgenommen und danach in jeder Anfrage erneut gesendet
  • In einer Sitzung mit 9 Requests wird dasselbe Template 9-mal mitgeschickt, die Kosten wachsen also mit Template-Größe × Anzahl Requests
• In realen Konfigurationen war die erste Anfrage deutlich größer als der Basis-Overhead
  • OpenCode nutzte 11 MCP-Server für E-Mail und Kalender, Aufgabenverwaltung, Literaturverwaltung, Produktanalyse usw. und kam zusammen mit einer 72-KB-Befehlsdatei auf 179 Tools, 277 KB Schema und 90.817 Token kalte Cache-Schreibkosten
  • Claude Code kam mit 4 MCP-Servern, installierten Plugins und derselben Befehlsdatei auf 118 Tools, 311 KB Payload und rund 75.000 Token
  • Die OpenCode-Konfiguration lag damit ohne Gateway-Envelope beim rund 12-Fachen des Standardwerts von etwa 7.000 Token

Kosten von Sub-Agenten und erweitertem Denken

• Verteilte Claude Code die Aufgabe parallel auf zwei Sub-Agenten, stiegen die 121.000 Token der direkten Ausführung auf 513.000 Token, also auf das 4,2-Fache
  • Insgesamt entstanden 9 Modell-Requests über drei Request-Typen hinweg, darunter Hauptsitzung und Sub-Agent-Aufrufe
  • Die 5 Sub-Agent-Aufrufe bootstrappten sich jeweils mit einem 3.554 Zeichen langen System-Prompt und 24 der 27 Standard-Tools selbst
  • Jeder Sub-Agent trägt also eigene Initialkosten, und seine Ausführungsprotokolle werden anschließend vom übergeordneten Agenten erneut gelesen
• OpenCode-Sub-Agenten sendeten ein reduziertes Profil mit einem 1.379 Zeichen langen System-Prompt und nur 5 Tools
  • Da die Ausführung über das Gateway nicht sauber abgeschlossen wurde, wurde der gesamte Sub-Agent-Verbrauch von OpenCode nicht quantifiziert
  • Verglichen wurden nur die in der erfassten Payload sichtbaren Designunterschiede
• Ausgabe für erweitertes Denken wird mit dem fünffachen Ausgabepreis gegenüber Eingaben abgerechnet; zudem werden die Reasoning-Blöcke in den Gesprächsverlauf aufgenommen und in späteren Requests erneut gesendet
  • Wegen der Denk-Policies des Gateways ließ sich nicht sicher bestätigen, ob die Einstellungen beider Harnesses tatsächlich angewendet wurden; daher wurden keine Messwerte veröffentlicht
  • Übrig blieb nur die Kostenstruktur, bei der Reasoning-Blöcke Teil des Verlaufs werden

Wirtschaftlichkeit und Stabilität des Prompt-Caches

• Beide Harnesses setzten Cache-Breakpoints korrekt. Die Payload wird bei einer TTL von 5 Minuten einmalig zum 1,25-fachen des normalen Eingabepreises geschrieben und anschließend zum Zehntelpreis gelesen
• Drei Kostenarten werden durch Caching nicht eliminiert
  • Nach mehr als 5 Minuten Pause muss der gesamte Stack erneut geschrieben werden; nach Unterbrechungen wie Meetings oder Mittagessen fallen die Schreibkosten daher erneut an
  • Auch Cache-Lesevorgänge werden pro Request erneut berechnet, weshalb serielle Tool-Loops und die Verteilung auf Sub-Agenten die Kosten erhöhen
  • Die Belegung des Kontextfensters wird durch Cache-Rabatte nicht beeinflusst; ein Bootstrap von 85.000 Token belegt mehr als 40 % eines 200.000-Token-Fensters, und sobald Kompression einsetzt, entstehen zusätzliche Zusammenfassungskosten
• OpenCode hielt in allen erfassten Requests und Ausführungen einen bytegenau identischen Präfix bei
  • In drei T1-Sitzungen waren Tool-, System- und Nachrichten-Bytes identisch, und die Cache-Schreibkosten bei Wiederholungen lagen bei 0
  • Auch die T3-Sitzung mit 9 Requests behielt einen stabilen Präfix bei
• Claude Code erzeugte dagegen je Sitzung unterschiedliche Request-Typen und Cache-Einträge für Aufwärm-Erkundung, Hauptdialog und Sub-Agent-Aufrufe
  • Selbst im selben Workspace unterschieden sich System-Bytes und Scaffold der ersten Nachricht von Lauf zu Lauf
  • Bei derselben Dateizusammenfassung schrieb es über 5 Requests hinweg 53.839 Cache-Token und schrieb den rund 43.000 Token großen Präfix während der Aufgabe einmal vollständig neu
  • OpenCode schrieb für dieselbe Aufgabe nur 1.003 Cache-Token
• Diese großen Zwischen-Rewrites des Caches bei Claude Code zeigten sich auch in Wiederholungsexperimenten
  • In den ersten zwei Läufen wurden 43.342 bzw. 36.899 Token erneut geschrieben, im dritten Lauf mit frisch vorgewärmtem Cache fast nichts mehr
  • Auch mit Fable 5 wurden ohne Cache-Lesungen 50.053 Token erneut geschrieben, was ähnlich wie bei Sonnet zu einer Lücke von rund dem Faktor 52 statt 54 führte
  • Je nach Cache-Temperatur lag die Cache-Schreibmenge von Claude Code beim 5,9- bis 54-Fachen von OpenCode
  • Der Preis für Cache-Schreibvorgänge beträgt im 5-Minuten-Tier das 1,25-Fache und im 1-Stunden-Tier das 2-Fache des Grundpreises
• Ein einzelner Cache-Miss könnte zwar durch Verdrängung im Gateway verursacht worden sein, trat aber in mehreren Läufen reproduzierbar auf; zudem zeigte schon der vorab erfasste Byte-Stream Instabilität im Präfix
  • Wenn Präfixe groß sind, in mehreren Varianten auftreten, wiederholt neu geschrieben werden und zusätzlich Sub-Agenten hinzukommen, kann der Nutzungszähler von Claude Code deutlich schneller steigen

Ergebnisqualität und Audit-Logs

• Beide Harnesses erledigten alle bewerteten Aufgaben korrekt
  • Die Dateizusammenfassungen waren in allen Fällen korrekt
  • Die mehrstufige Aufgabe bestand die jeweils vom Harness erzeugten Prüfscripte und endete erfolgreich
  • In diesem Rahmen ließ sich daher die Token-Differenz für dieselben Resultate vergleichen
• Ob die Hintergrund-Agenten, Skills und Orchestrierung von Claude Code bei schwierigeren realen Engineering-Aufgaben genügend Qualitätsgewinn für die Mehrkosten liefern, wurde nicht gemessen
  • Dafür wären ein geeignetes Testset, ausreichend viele Wiederholungen und eine gesonderte Bewertung der Erfolgsquote nötig
• Es wurde auch Verschwendung unabhängig von der Qualität sichtbar
  • Ein byteidentischer Cache-Präfix, der mitten in der Sitzung erneut geschrieben wird, entspricht faktisch dem erneuten Kauf desselben Inhalts zum Premium-Preis
  • Wenn ein Harness eine Befehlsdatei stillschweigend ignoriert, entsteht daraus überhaupt kein Nutzen
• Die erfassten 185 Request-/Response-Protokolle wurden mit der Open-Source-Bibliothek @systima/aiact-audit-log in eine SHA-256-Hash-Kette geschrieben
  • Die Kette wurde ohne Unterbrechung bis zum Ende verifiziert, das Integritätsergebnis lautete VALID
  • Mit derselben Struktur lassen sich Versand- und Antwortinhalte rekonstruieren und Dritten Integritätsnachweise bereitstellen
  • Dies entspricht derselben strukturierten Logging-Methode, die für EU AI Act Article 12 bereitgestellt wird

Grenzen der Messung und Reproduzierbarkeit

• Die Ergebnisse sind ein Schnappschuss vom Juli 2026 auf einer einzelnen Maschine, mit zwei Harness-Versionen und kleiner Stichprobe
  • T1 und T2 wurden jeweils dreimal ausgeführt, jede Konfigurationsvariante nur einmal
  • Standard- und Cache-Bedingungen nutzten Sonnet 4.5 und Fable 5, Konfigurations-Multiplikatoren nur ein Modell
  • Da sich Harness-Prompts häufig ändern, dürfte die Messmethode an der API-Grenze länger relevant bleiben als einzelne Zahlenwerte
• Im Messpfad befand sich ein lokales Gateway
  • Komponentenwerte nutzten die Request-Bodies, die das Gateway nicht verändern konnte
  • Messwerte wurden über den festen Envelope-Offset am Kalt-Cache-Basispunkt korrigiert; Warm-Run-Werte mit unklarer Ursache wurden ausgeschlossen
  • Es gab Fälle, in denen das Gateway stillschweigend auf neuere Snapshots als das festgelegte Modell wechselte; daher muss auch das tatsächlich antwortende Modell an der Grenze überprüft werden
  • Im Fable-Pfad traten Wiederaufnahmen alter Serversitzungen und hostseitige Tool-Ausführung auf, weshalb die mehrstufigen Fable-Ergebnisse von Claude Code ausgeschlossen wurden
• Die Kostenkonvergenz bei T3 basiert auf einer einzelnen Beobachtung für genau einen Aufgabentyp
  • Bei Aufgaben, die zwingend sequentiell ablaufen müssen, können Request-Anzahl und Gesamtverbrauch von Claude Code wieder steigen
  • Bedingungen wie Tool-Entfernung und Sub-Agenten bei OpenCode lieferten im Gateway fehlerhafte Streams, weshalb dort nur die Größe der erfassten Payload verwendet wurde
  • Die Zahlen realer Konfigurationen stammen aus dem Setup eines einzelnen Nutzers und können in anderen Umgebungen anders ausfallen
• Die Reproduktionsvorrichtung ist ein HTTP-Proxy mit rund 200 Zeilen Node-Code
  • Er leitet Requests an den Modell-Endpunkt weiter und protokolliert Request-Body sowie Response-Nutzungsblöcke auf Disk und in der Audit-Kette
  • Über ANTHROPIC_BASE_URL wird der Proxy gesetzt; gemessen wird zuerst die Standardkonfiguration in einem neuen Konfigurationsverzeichnis und leeren Workspace, danach werden Befehlsdatei, MCP-Server und Workflows einzeln hinzugefügt
  • Wer ein Gateway verwendet, sollte zuerst mit einer Minimalanfrage den eigenen Envelope messen und prüfen, welches Modell tatsächlich antwortet
  • Wer API-Grenzen-Logging aufsetzt, um den exakt an das Modell gesendeten Inhalt eines Produktiv-Agenten zu rekonstruieren, erhält damit zugleich eine belastbare Token-Buchhaltung

[GN⁺]

Meinungen auf Hacker News

• Was wirklich viele Tokens verbrennt, sind Sub-Agents. Ich habe Claude Code eine große Aufgabe gegeben, und es startete sofort 7 Sub-Agents; noch bevor einer davon fertig war, war das Budget aufgebraucht. Als ich es 5 Stunden später erneut versuchte, passierte dasselbe.
  Wenn der Haupt-Agent dieselbe Aufgabe sequenziell ausführen sollte, gab es überhaupt kein Problem. Ich weiß nicht, ob das wegen der Kommunikations- und Koordinationskosten so ineffizient ist oder ob Anthropic damit den Umsatz steigern will, weil Nutzer von Sub-Agents meist Enterprise-Konten haben und pro Token zahlen.

  • Umgekehrt kann in der Erkundungs- und Planungsphase komplexer Projekte Fables neugieriges Verhalten genau das sein, was man braucht. Wenn sich der koordinierende Agent nicht nur darauf beschränken soll, den Prompt in mehrere Erkundungsperspektiven aufzuteilen, sondern jeder Sub-Agent die Codebasis aus dieser Perspektive untersucht und neue Hinweise rekursiv erweitert, ist es sinnvoll, Fable in allen Schritten zu verwenden.
    Wenn man dagegen eine gut geplante Aufgabe parallel auf mehrere Ziele anwenden will, sollte man ausdrücklich festlegen, dass die Sub-Agents auf ein weniger neugieriges Modell heruntergestuft werden. Auch die Konsistenz der Ergebnisse kann dadurch besser werden.
  • Jeder Sub-Agent muss Teile der Codebasis erneut lesen, um den für die Aufgabe nötigen Kontext zu bekommen. Dauert die Aufgabe länger, verschwindet auch der Kontext des koordinierenden Agents aus dem Cache, sodass man nach Abschluss der Sub-Agents wieder die vollen Kosten zahlt.
    Bei sequenzieller Ausführung liest man die Dateien grob nur je einmal, und alle Anfragen nutzen denselben Prefix-Cache.
  • Wenn Kunden auf teurere Tarife ausweichen, um ein Problem zu umgehen, entsteht für das Unternehmen ein negativer Anreiz, dieses Problem zu beheben. Selbst wenn es ein paar Engineers mit einer Lösung gibt, können sie auf Gleichgültigkeit der Mehrheit, Sabotage durch einige und manchmal aktive Feindseligkeit irgendwo in der Managementebene stoßen.
    In so einem Umfeld kann es die beste Strategie sein, neue Funktionen zuerst in den teuersten Tarif zu packen, die Kosten wieder hereinzuholen und sie danach in günstigere Tarife herunterzureichen – oder die Leiter wegzuziehen, damit Wettbewerber schwerer nachziehen können.
  • Jeder Sub-Agent bekommt denselben System-Prompt mit rund 30.000 Tokens geschickt. Mit Fable/Opus verbrauchen 7 davon leicht 30 % des 5-Stunden-Nutzungslimits, noch bevor sie überhaupt mit der Arbeit beginnen.
  • Nachdem ich diesen Kniff gelernt habe, verbiete ich Fable-Sub-Agents ausdrücklich. Gestern wollte ich nach einem großen Refactoring komplexen Code überprüfen lassen und bat zuerst um einen Review-Plan; im ersten Schritt wurden 8 Fable-Agents plus 1 zur Ergebnisvalidierung vorgeschlagen, was ich genehmigte.
    In der Validierungsphase wollte es dann aber 41 Fable-Validierungs-Agents starten. Irgendwie findet es immer einen Umweg.

• Ich denke, Claude Code verbraucht so viele Tokens, weil Anthropic mehr Geld verdienen und Nutzer in Abos drängen will. Die Richtlinie, dass man Abo-Berechtigungen nicht in anderen Coding-Agents verwenden darf, stützt das ebenfalls. Ich nutze pi.

  • Seit ich Anthropic als Token-Verkäufer betrachte, ergeben viele Entscheidungen Sinn. Solange Nutzer nicht protestieren oder Schutzmechanismen verlangen, schafft das Unternehmen weiter Gründe, über die eigenen Wege mehr Tokens zu verbrauchen.
  • Ich habe gesehen, dass der Abo-Umsatz laut Unterlagen im Zusammenhang mit dem Börsengang mit etwa 5 % sehr klein sein soll. Allerdings sind diese 5 % persönliche Claude-Abos; die meisten Claude-Code-Abos dürften vermutlich im Unternehmenssegment enthalten sein.
    API und Enterprise machen 75–85 % des Gesamtumsatzes aus, Unternehmensabos etwa 10–15 %, persönliche Abos etwa 5 %.
  • Eigentlich spricht die Logik eher dagegen. Abonnenten zahlen eine feste Monatsgebühr, daher hat Anthropic einen Anreiz, Claude Code weniger Tokens verbrauchen zu lassen.
  • Andererseits erhöht dieses Verhalten auch den Token-Verbrauch normaler Abonnenten, der in der Flatrate enthalten ist. Das wirkt weniger böswillig als eher inkompetent.

• Wie in PUSH_AX’ passender Analogie ist das so, als verlange Bauunternehmer A 33.000 Dollar und B 7.000 Dollar; wir sollten also prüfen, ob wir das richtige Ziel messen.
  Entsprechend werde ich dem Beitrag tiefere Aufgaben, qualitative Ergebnisvergleiche und möglichst schnell reproduzierbare Eingabe-/Ausgabe-Daten hinzufügen.

  • Ich frage mich, ob ein erheblicher Teil der 33.000 Tokens Kontextdaten wie die jüngste Unterhaltung sind.

• Es ist nicht nur ein Problem großer System-Prompts. Auch die Ausführungsumgebungen von Coding-Agents verwenden Tools selbst bei trivialen Anfragen aggressiver. In Tests führten Prompts wie „Hey“ oder „commit“ teils zu mehr als 30 Tool-Aufrufen.
  https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
  Eine Token-Inflation, bei der einfache Aufgaben immer mehr Tokens verbrauchen, ist tatsächlich zu beobachten.

  • Es nervt, wenn Opus einen einzelnen Tippfehler in einem Kommentar korrigiert und dann alles ausführt, was ausführbar ist, inklusive Tests und Linting. Manchmal stash’t es sogar zuerst die aktuellen Änderungen, um proaktiv zu prüfen, ob alle Tests ursprünglich bestanden haben.
    Es ist auch meine Schuld, weil ich in die Regeln geschrieben habe, dass alle Änderungen durch Tests verifiziert werden sollen; aber wenn man das I in AI so betont, erwartet man doch genug Urteilsvermögen, um keine Tomaten in den Obstsalat zu tun.
  • Bei mehrdeutigen Prompts wie „Hey“ oder „commit“ steigen die Tool-Aufrufe, weil versucht wird, aus früheren Gesprächen und anderem Kontext abzuleiten, was gemeint ist. Klarere Prompts sind besser.
  • Einen Commit kann man doch auch selbst machen, ohne ihn einem LLM zu überlassen, oder?

• Nach 6 Monaten mit Claude bin ich kürzlich zu Codex gewechselt. Codex ist offener, der Arbeitsprozess des Modells ist leichter nachzuvollziehen, und die User Experience der Approval-Flows ist besser. Insgesamt ist es transparenter, und die Wechselkosten lagen praktisch bei null.
  Mir gefällt nicht, dass Claude seit etwa Februar undurchsichtiger geworden ist, einschließlich des System-Prompts; 33.000 Tokens wirken übertrieben viel.

  • Ich nutze inzwischen beides, und tatsächlich sind sie praktisch austauschbar. Mir gefällt auch, dass Codex Open Source ist und OpenAI ausdrücklich erlaubt, Abo-Berechtigungen in anderen Agents zu verwenden.
    OpenAI ist in letzter Zeit deutlich verbraucherfreundlicher geworden.
  • Mich würde interessieren, welche Einstellungen du ausprobiert hast, nachdem es undurchsichtiger geworden ist. Inzwischen gibt es deutlich mehr Einstellungsoptionen.

• Der pi-Agent hat einen kleineren System-Prompt; den vollständigen Inhalt kann man hier einsehen
  https://github.com/earendil-works/pi/blob/main/packages%2Fco...

  • Das könnte mit diesem Minimalismus zusammenhängen, aber Pi fehlen die meisten Tools, die ein LLM braucht, um effizient und effektiv zu arbeiten. Ich verstehe die Philosophie, auf einer leeren Grundlage das Gewünschte hinzuzufügen, aber nach meinem Maßstab ist es zu leer
  • Ich frage mich, ob das Setzen des Datums und von cmd bei jedem Aufruf des System-Prompts den Cache invalidiert
    Wenn er nur invalidiert wird, wenn sich das Datum oder das Root-Verzeichnis ändert, ist das in der Praxis allerdings selten genug
  • Wenn man einen minimalen Agenten braucht, den man stark anpassen will, ist es besser, ihn selbst zu bauen, statt über das „minimale“ pi-coder-Paket mehr als 130 transitive Abhängigkeiten hereinzuziehen. Das ist nicht schwer, man lernt viel dabei, und für den Einstieg kann man auch ein anderes LLM um Hilfe bitten

• Am Ende kommt es nicht auf die rohe Prompt-Größe an. Wenn doch, müssten Pi und seine Varianten die niedrigsten Kosten haben. Entscheidend ist die Effizienz des Prompts, und Prompt-Minimalismus und Effizienz werden oft verwechselt. Trotzdem wirkt Claude Code für das, was es tut, aufgebläht
  Noch wichtiger ist die Qualität der Tools. Schlechte oder fehlerhafte Tools erhöhen die Zahl der Roundtrips deutlich und machen alle Vorteile zunichte, die man anfangs einsparen wollte
  Vor ein paar Monaten habe ich 7 Agenten über 8 Aufgaben hinweg vollständig gebenchmarkt; unter https://github.com/dirac-run/dirac gibt es Daten und Traces. Da ich mit einem davon direkt verbunden bin, kann ich keine Neutralität beanspruchen, aber das Material ist reproduzierbar. Die meisten Aufgaben hatten mit Refactoring zu tun, daher gewann Dirac, das bei Hash-Anchoring und Analyse abstrakter Syntaxbäume seine Stärken ausspielt, mit großem Abstand

  • Es gibt viele Wettbewerber und der Wettbewerb ist sehr intensiv; wenn es Verbesserungspotenzial gibt, wird es jemand realisieren, und danach ist es sehr wahrscheinlich, dass es sich schnell auf andere Produkte ausbreitet

• Bei der Arbeit muss ich Claude Code verwenden, aber mit --system-prompt "" lässt sich das einfach lösen. Es wäre schön, wenn auch andere Laufzeitumgebungen erlaubt wären

  • Wenn man ihn mit --system-prompt "" leert, fehlt dem Modell dann nicht sogar der grundlegende System-Prompt, um die verfügbaren Tools zu verstehen?
  • Ich nutze das schon seit Langem so und weiß nicht, warum es nicht alle verwenden
  • Diese Option kannte ich nicht. Ich würde gern Analysen zur tatsächlichen Effizienz vor und nach der Anwendung oder Performance-Charts aus realen Einsatzumgebungen sehen
  • Ich frage mich, ob Claude mit dieser Option gestartet wird oder ob sie bei jedem Senden eines Prompts mitübergeben wird

• Als ich zum ersten Mal mit lokalen Modellen experimentierte und sie mit Claude Code verband, funktionierte das sehr gut, war aber langsam
  Mit Claudes Hilfe richtete ich mitmproxy ein und zeichnete den gesamten initialen System-Prompt von Claude Code auf; bei erneuter Prüfung waren es 162 KB JSON. Das war der Anlass, mit Pi, OpenCode und Hermes zu experimentieren

  • Wenn man heute in einer neuen Claude-Code-Session /context ausführt, werden von Opus 4.8s Kontext mit 1 Million Tokens nur 23.000 Tokens genutzt. Angezeigt werden 3.900 für den System-Prompt, 13.900 für System-Tools, 235 für benutzerdefinierte Agenten, 28 für Memory-Dateien, 4.900 für Funktionen, 8 für Nachrichten und 3.000 Tokens für den Kompressionspuffer
    4.000 Tokens System-Prompt entsprechen etwa 15–20 KB. Ich würde gern darum bitten, den aufgezeichneten Inhalt als Gist hochzuladen, aber er könnte sensible Daten enthalten, und es ist gut möglich, dass die sichtbaren 162 KB nicht nur der System-Prompt sind

• Was ich gebaut habe, überträgt weniger: https://maki.sh

  • Wenn der Kontext zu lang wird, entfernt maki angeblich Bilder und Reasoning-Blöcke und komprimiert den Verlauf automatisch, indem es frühere Gespräche zusammenfasst
    Aber invalidiert eine Zusammenfassung früherer Gespräche nicht faktisch den Kontext-Cache, sodass zwar weniger Tokens verwendet werden, dafür aber teurere Tokens verbraucht werden?