Warum Claude „dümmer“ wird, je mehr man ihn nutzt: Der versteckte Preis von „Geld sparen“ ist eine 100-fache API-Rechnung
Warum Claude „dümmer“ wird, je mehr man ihn nutzt: Der versteckte Preis von „Geld sparen“ ist eine 100-fache API-Rechnung
Vor ein paar Tagen veröffentlichte Stella Laurenzo, KI-Direktorin bei AMD, ein technisch brisantes Problem im offiziellen Claude Code Repository: „Claude Code ist für komplexe Ingenieursaufgaben mit den Feb-Updates unbrauchbar.“ Dies war keine rein gefühlsmäßige Beschwerde. Es war eine quantitative Analyse, die auf 6.852 Sitzungen, 17.871 Denkblöcken und 234.760 Tool-Aufrufen basierte, die in realen Arbeitsabläufen gesammelt wurden. Den Originalbericht können Sie hier lesen: GitHub-Issue #42796.
Wenn Sie im Krypto-Bereich arbeiten, sollten Sie das beachten – denn „komplexe Ingenieurskunst“ ist in Web3 praktisch die Standardeinstellung: Smart Contracts sind unveränderlich, Angriffsflächen sind komponierbar und eine einzige halluzinierte Änderung kann zu einem Exploit werden. Was wie ein Haken bei einem KI-Produkt aussieht, ist in der Praxis ein Software-Lieferkettenrisiko – und eine Kostenfalle.
1) Die unbequemen Daten: Qualität sinkt, Kosten steigen (sehr stark)
Der Bericht verbindet eine sichtbare Qualitätsverschlechterung mit serverseitigen Konfigurationsänderungen im Zusammenhang mit erweitertem Denken und Gedanken-Schwärzung (insbesondere dem Rollout mit der Bezeichnung redact-thinking-2026-02-12). Die Kernbehauptung ist nicht nur, dass „die Ausgaben schlechter wurden“, sondern dass sich das Verhalten des Modells messbar von „erst recherchieren“ zu „erst bearbeiten“ verschoben hat – genau die falsche Richtung für risikoreiche Ingenieursarbeiten.
Hier ist ein vereinfachter Überblick, basierend auf den Metriken im Issue-Thread:
Quelle: Die ursprüngliche Telemetrie und der Kostenanhang in dem GitHub-Issue.
Die für Krypto relevanteste Lektion ist kontraintuitiv: Das Rationieren von Denkprozessen reduziert nicht immer die Ausgaben. Bei langwierigen Aufgaben kann ein schwächerer Agent mehr Wiederholungen, Korrekturen und Tool-Aufrufe auslösen – und Ihre Rechnung um über das 100-fache erhöhen, während er immer noch eine schlechtere Zuverlässigkeit liefert.
2) Warum dies Blockchain-Teams härter trifft als typische Software-Teams
Smart Contracts tolerieren kein „nahezu richtig“
In Web2 kann eine Regression behoben und neu eingesetzt werden. In Web3 kann eine schlechte Annahme unsterblich sein.
Die Dokumentation von Ethereum selbst ist unmissverständlich: eingesetzter Code ist schwer zu ändern, und Verluste sind oft unwiederbringlich – siehe Ethereum Smart Contract Security Documentation und die allgemeineren Sicherheitsrichtlinien.
Nun verbinden Sie das mit der Claude Code-Telemetrie: weniger Datei-Lesevorgänge, mehr eifrige Bearbeitungen, mehr vorzeitige Stopps. Das ist genau das Muster, das Folgendes erzeugt:
- Unvollständige Prüfungen (Autorisierung, Replay-Schutz, Domain-Trennung)
- Fehlerhafte Invarianten zwischen Modulen
- Fehlende Behandlung von Grenzfall-Szenarien bei Token-Dezimalstellen, Gebühr-pro-Transaktion, Rundung
- Unsichere externe Aufrufe oder schlecht platzierte Zustandsänderungen
In DeFi und bei On-Chain-Infrastrukturen ist „nahezu korrekt“ oft dasselbe wie ausnutzbar.
Komplexitätstrends 2025–2026 verstärken den Einschlag
Zwei Branchentrends machen die Geschichte der „KI-Agenten-Regression“ in Krypto gefährlicher, als sie scheint:
-
Account Abstraction und Smart Accounts werden zum Mainstream, was die Menge an sicherheitskritischer Logik erhöht, die in Contracts und nicht in EOAs lebt. Wenn Ihr Produkt AA berührt, beginnen Sie mit ERC-4337 und den praktischen Ökosystem-Dokumenten unter ERC-4337 Documentation.
-
KI-gestützte Betrügereien und Social Engineering skalieren. Chainalysis stellt fest, dass Betrügereien im Zusammenhang mit KI-Anbietern durchschnittlich materiell mehr pro Operation erzielen; siehe ihren Bericht über Betrügereien im Crypto Crime Report 2026. Wenn Endbenutzer KI zunehmend fragen „Ist das sicher zu signieren?“, wird die Zuverlässigkeit des Modells zu einem Verbraucherschutzproblem, nicht nur zu einer technischen Präferenz.
3) Die eigentliche Erkenntnis: LLMs sind jetzt eine Produktionsabhängigkeit – behandeln Sie sie auch so
Krypto-Teams haben bereits gelernt (auf die harte Tour), kritische Abhängigkeiten zu versionieren: Compiler-Versionen, RPC-Anbieter, Custody-Module, Signing-Bibliotheken. LLM-Agenten gehören nun in dieselbe Kategorie.
Ein praktisches Web3-Playbook:
A) Bauen Sie „LLM-Regressionstests“ wie Protokoll-Test-Suiten
- Erfassen Sie repräsentative Aufgaben: Contract-Upgrade-Flows, Cross-Chain-Messaging, Indexer-Backfills, Gebühren-Mathematik-Refaktorisierungen.
- Führen Sie die gleichen Prompts wöchentlich aus; vergleichen Sie die Ergebnisse.
- Blockieren Sie Merges bei deterministischen Prüfungen: Unit-Tests, Invarianten, Simulation und statische Analyse.
Wenn Sie Solidity bereitstellen, verweist die Richtlinien-Seite von Ethereum explizit auf Tools wie Slither / Echidna-basierte Analyse-Workflows – starten Sie bei Smart contract security guidelines.
B) Entfernen Sie „automatische Annahme von Bearbeitungen“ aus kritischen Repositories
Der Issue-Bericht erwähnt Workflows, bei denen Änderungen automatisch akzeptiert wurden. Das ist ein Produktivitätsgewinn – bis ein Agent leise von sorgfältig zu rücksichtslos wechselt.
Behandeln Sie KI bei Smart Contracts wie einen Junior-Mitarbeiter:
- Fordern Sie menschliche Code-Überprüfung an
- Fordern Sie das Bestehen von Tests und lokaler Simulation an
- Fordern Sie eine ausdrückliche Bestätigung für Berechtigungsänderungen, neue externe Aufrufe oder Änderungen am Speicherlayout an
C) Setzen Sie eine harte Obergrenze für Schluckauf (Kostenkontrolle ist Sicherheitskontrolle)
Wenn die Qualität sinkt, kompensiert der Agent dies, indem er mehr tut: mehr Tool-Aufrufe, mehr Wiederholungen, mehr Token-Verbrennung. Sie benötigen Notbremsen:
- Maximale Wiederholungen pro Aufgabe
- Maximale Tool-Aufrufe pro Sitzung
- Maximale Kontextwachstum
- Benachrichtigungen bei „Kosten pro zusammengeführtem PR“ oder „Kosten pro gelöstem Ticket“
So verhindern Sie, dass „Rechenleistung sparen“ zu einer 100-fach überraschenden Rechnung wird.
D) Verwenden Sie ein LLM-Bedrohungsmodell, nicht nur eine Prompt-Vorlage
Wenn Sie Agenten entwickeln, die Produktionsschlüssel, RPC-Endpunkte oder Signing-Flows berühren, orientieren Sie sich an Sicherheitsframeworks wie den OWASP Top 10 für Large Language Model Applications und behandeln Sie Prompt-Injection / Tool-Missbrauch als erstklassige Risiken.
4) Für alltägliche Benutzer: KI kann Ihnen helfen, Krypto zu verstehen, aber sie sollte nicht Ihre Schlüssel kontrollieren
Da KI-Assistenten zur Standardschnittstelle für Wallets, Handel und Kundensupport werden, ist die wahrscheinlichste Fehlerursache nicht die „schlechte Code-Generierung“, sondern schlechte Signatur-Entscheidungen – insbesondere unter Phishing-Druck.
Zwei Unverzichtbarkeiten:
- Fügen Sie niemals Seed-Phrasen in einen KI-Chat, einen „Support-Bot“ oder ein Browser-Formular ein.
- Trennen Sie „Rat“ von „Autorisierung“: Lassen Sie die KI zusammenfassen, aber fordern Sie zur Bewegung von Geldern eine physische Bestätigung an.
Diese Trennung ist genau das, wofür ein Hardware-Wallet seinen Wert hat.
5) Wo OneKey passt: KI optional machen, Signatur explizit machen
Wenn Ihr Workflow (oder Ihre Benutzer) zunehmend auf KI angewiesen ist – sei es für Transaktionserklärungen, Contract-Interaktionen oder On-Chain-„Agenten“-Automatisierung – ist die sicherste Architektur:
- KI kann vorschlagen
- Ihre App kann simulieren
- Ihre Hardware-Wallet muss genehmigen
Der praktische Wert von OneKey in einem KI-gesättigten Krypto-Stack ist einfach: Es hilft, private Schlüssel offline zu halten und erzwingt einen expliziten Signaturschritt, wodurch die Wahrscheinlichkeit verringert wird, dass ein verschlechtertes Modell, ein vergifteter Prompt oder eine überzeugende Deepfake-„Support-Nachricht“ zu einem irreversiblen On-Chain-Verlust führt.
Abschließender Gedanke: „Günstigere Denkprozesse“ sind nicht günstiger – besonders in Krypto
Der AMD-Bericht ist ein seltenes Geschenk: Er verwandelt eine vage Angst („Das Modell fühlt sich in letzter Zeit schlechter an“) in messbares Systemverhalten und eine harte Kostenkurve. In der Blockchain, wo Korrektheit Geld bedeutet und Fehler permanent sind, ist die Lektion eindeutig:
Optimieren Sie nicht für Token-Kosten pro Anfrage. Optimieren Sie für Korrektheit pro Entscheidung.
