Dein Code-Agent verbraucht mehr Energie als du beim Selbstschreiben — aber lohnt es sich?

41 Wh. So viel verbraucht eine durchschnittliche Sitzung von Claude Code — direkt gemessene Daten des Forschers Simon P. Couch im Januar 2026.

Das entspricht 136 normalen Text-Anfragen. Oder einer LED-Lampe, die vier Stunden lang brennt. Oder 12 % der Energie, die dein Laptop an einem vollen Arbeitstag verbraucht.

Und das ist die durchschnittliche Sitzung. Eine komplexe Sitzung — ein ganzer Tag mit aktivem Agent — kann 50-200 Wh erreichen.

Die Frage ist nicht, ob der Verbrauch hoch ist. Die Frage ist, ob er sich lohnt.

Was ein Code-Agent ist und warum er so viel verbraucht

Es gibt einen fundamentalen Unterschied zwischen einem Code-Assistenten und einem Code-Agent.

Die klassische Autovervollständigung — das ursprüngliche GitHub Copilot, intelligente Snippets — macht pro Vorschlag nur einen einzigen Aufruf an das Modell. Die Kosten sind gering und punktuell: 0,5-2 Wh pro Arbeitssitzung.

Ein Agent ist etwas anderes. Er wartet nicht darauf, dass du schreibst: Er handelt. Er erhält eine Aufgabe in natürlicher Sprache („implementiere die Authentifizierung mit OAuth”, „migriere diese Tests zur neuen API”, „finde und behebe den Performance-Bug im Checkout”) und geht autonom vor.

Um diese Aufgabe zu erledigen, macht der Agent Folgendes:

• Liest Projektdateien — manchmal Dutzende
• Plant und zerlegt die Aufgabe, bevor er Code anfasst
• Schreibt Code, führt ihn in einer Sandbox-Umgebung aus und liest die Ausgabe
• Interpretiert Fehler und entscheidet, wie er sie korrigiert
• Fängt von vorne an, wenn das Ergebnis die Tests nicht besteht

Eine „einfache Aufgabe” kann 20-50 Modellaufrufe auslösen. Eine komplexe Aufgabe Hunderte. Und jeder Aufruf beinhaltet den angesammelten Kontext — alle gelesenen Dateien, den gesamten Verlauf — was dazu führt, dass auch die Tokens pro Aufruf im Zeitverlauf wachsen.

Das Ergebnis: Der Verbrauch skaliert nicht linear mit der Aufgabenkomplexität. Er skaliert superlinear.

Die Daten: Tool für Tool

Dies sind die dokumentierten Verbrauchsspannen für die wichtigsten Code-Agents, mit ihren Multiplikatoren gegenüber einer einfachen Text-Anfrage (0,3 Wh als Referenz):

Einige Beobachtungen zu dieser Tabelle:

Aider ist der positive Ausreißer. Der Open-Source-Agent verbraucht x4 weniger Tokens als Claude Code für vergleichbare Aufgaben. Effizienz ist kein Monopol kommerzieller Lösungen.

Devin 2.0 ist am unberechenbarsten. Die Spanne von 10-60 Wh spiegelt eine enorme Varianz wider: Sein vollautonomer Modus kann genauso viel verbrauchen wie eine ausgedehnte Claude Code-Sitzung mit Opus.

GPT-5.3-Codex verdoppelt seinen Vorgänger. Der Sprung von x20-x67 auf x40-x133 zwischen den Versionen illustriert den Trend: Modelle mit integriertem Reasoning kosten mehr, sind aber auch leistungsfähiger.

Der Fall Claude Code: die einzigen Daten mit öffentlicher Methodik

Von der gesamten obigen Liste existiert nur eine öffentliche Analyse mit detaillierter Methodik: die von Simon P. Couch, veröffentlicht im Januar 2026.

Couch analysierte seine eigenen Arbeitssitzungen mit Claude Code über Wochen hinweg und dokumentierte Folgendes:

• Durchschnittliche Sitzung: 592.000 Tokens in 24 interaktiven Austauschen
• Verbrauch pro durchschnittlicher Sitzung: 41 Wh
• Äquivalenz: 136 normale Text-Anfragen
• Intensivnutzungs-Sitzung (mehrere Instanzen, ganzer Tag): 50-200 Wh

„Ein Entwickler, der Code-Agents 8 Stunden am Tag nutzt, verbraucht eine Energiemenge, die dem 24-stündigen Betrieb eines Kühlschranks entspricht.” — Simon P. Couch, Analyse des Energieverbrauchs von Claude Code, Januar 2026

Was diese Analyse wertvoll macht, ist nicht nur die Zahl: Es ist die Tatsache, dass niemand sonst vergleichbare Daten veröffentlicht hat. Weder Anthropic noch OpenAI, noch GitHub, noch Cursor. Die Unternehmen, die diese Tools verkaufen, veröffentlichen keine Wh pro Aufgabe. Sie veröffentlichen nur den Preis pro Token — der eine Proxy-Variable für den Verbrauch ist, aber nicht dem tatsächlichen Verbrauch im Kontext entspricht.

Das Produktivitätsparadoxon

Hier kommt der unbequeme Teil der Analyse: Die hohen Energiekosten können gerechtfertigt sein, wenn der Produktivitätsgewinn real ist.

Interne Daten von GitHub deuten auf eine +55 % höhere Geschwindigkeit bei abgegrenzten Aufgaben mit Copilot Agent hin. Studien von Teams, die vollständige Code-Agents einsetzen, berichten von Äquivalenzen von 3-4 Arbeitstagen, die für bestimmte Aufgabentypen auf einen Tag komprimiert werden.

Wenn das stimmt — und die Methodik hat Einschränkungen, die wir noch diskutieren werden — kann der ROI selbst unter Berücksichtigung des Energieverbrauchs positiv sein.

Aber es gibt ein Problem mit diesen Daten:

Die Produktivitäts-Benchmarks werden von den Unternehmen selbst erstellt. GitHub misst den Einfluss von Copilot. Anthropic misst den Einfluss von Claude Code. Keine unabhängige Studie hat gleichzeitig gemessen:

1. Entwicklungsgeschwindigkeit
2. Gesamtenergieverbrauch
3. Qualität des produzierten Codes
4. Langfristige Wartbarkeit
5. Erzeugte technische Schulden

Der Rebound-Effekt ist real und aus anderen Technologien dokumentiert: Wenn etwas schneller wird, wird es mehr genutzt. Ein Team, das Code-Agents einsetzt, macht nicht nur dasselbe schneller — es erzeugt auch mehr Code, mehr Iterationen, mehr Reviews, mehr PRs. Höhere Gesamtkosten? Wahrscheinlich ja.

Die Frage, die niemand beantwortet, lautet: Generiert dieser zusätzliche Code Wert, oder akkumuliert er nur technische Schulden?

In welchen Fällen lohnen sich die Kosten?

Nicht alle Anwendungsfälle sind gleich. Dies sind die Situationen, in denen die Energiekosten eines Code-Agents einen klaren Return haben:

Migrationen und Refactoring mit klar definierten Mustern. Von einer API-Version zur anderen migrieren, Abhängigkeiten aktualisieren, Tests von einem Framework in ein anderes konvertieren. Der Agent kennt das Muster, wendet es konsistent auf Hunderte von Dateien an. Der Mensch würde Tage brauchen; der Agent Stunden. Das Zeitdifferenzial hat realen Geschäftswert.

Schnelles Prototyping, wenn Time-to-Market zählt. In Explorationsphasen mit realen Deadlines — eine Demo für Investoren, ein MVP zur Validierung einer Hypothese — können die Kosten der Geschwindigkeit die Energiekosten bei Weitem übersteigen.

Verständnis großer Codebasen. Einen Agent bitten, die Architektur eines 200.000-Zeilen-Projekts zu erklären, den Fluss einer Funktion nachzuverfolgen oder alle Nutzungsstellen einer API zu identifizieren. Hier liest der Agent mehr als er schreibt, und der Wert liegt in der Synthese.

Regressionstests und Testabdeckung. Tests für gut dokumentierten bestehenden Code zu generieren ist vorhersagbar, und der Agent macht das gut. Die freigesetzte menschliche Arbeitszeit kann für Aufgaben mit höherem kognitivem Wert eingesetzt werden.

In welchen Fällen lohnt es sich NICHT?

Offene Exploration. „Mach etwas Interessantes mit diesen Daten.” „Verbessere die Performance der Anwendung.” „Refaktoriere, damit es sauberer ist.” Ohne klares Erfolgskriterium iteriert der Agent, ohne zu konvergieren. Viele Modellaufrufe, unsicheres Ergebnis, manuelle Überprüfung in jedem Fall unvermeidlich.

Domänen, die das Modell nicht gut beherrscht. Wenn der Agent die Domäne nicht gut kennt — eine sehr spezifische Bibliothek, eine seltene Programmiersprache, undokumentierte Geschäftslogik — wird er Fehler machen und viele Iterationen zur Korrektur brauchen. Hoher Verbrauch, mittelmäßiges Ergebnis.

Aufgaben, bei denen Geschwindigkeit keine Rolle spielt. Wenn es keine Deadline gibt, wenn der generierte Code ohnehin eine gründliche Überprüfung braucht, wenn das Team mehr Zeit mit der Überprüfung der Agent-Ausgabe verbringt, als es zum Selbstschreiben gebraucht hätte: Der ROI ist negativ.

Wenn der generierte Code mehr technische Schulden erzeugt, als er löst. Agents sind darauf optimiert, die zugewiesene Aufgabe abzuschließen. Sie haben keinen eigenen Geschäftskontext, kennen nicht die impliziten Konventionen des Teams, wissen nicht, welche Teile des Codes am kritischsten sind. Der Code, den sie generieren, kann funktionieren und trotzdem in sechs Monaten ein Problem darstellen.

Der Messungs-Bias

Es gibt ein strukturelles Problem in der Art und Weise, wie der Einfluss von Code-Agents bewertet wird:

Die Produktivitätsstudien werden von denen finanziert, die Produktivität verkaufen. Die meistzitierte Studie über die Auswirkungen von Copilot stammt von GitHub, das zu Microsoft gehört, das Copilot verkauft. Die wohlwollendste Analyse von Claude Code stammt von Anthropic. Das invalidiert die Daten nicht, erfordert aber eine kritische Lektüre.

Die Erfolgsmetriken sind auf das ausgerichtet, was leicht messbar ist. Geschwindigkeit beim Abschließen einer abgegrenzten Aufgabe: messbar. Codequalität nach sechs Monaten: in einer dreiwöchigen Studie nicht messbar. Angesammelte technische Schulden: ebenfalls nicht. Auswirkungen auf die Fähigkeit des Entwicklers, seinen eigenen Code zu pflegen und zu verstehen: fast unmöglich zu isolieren.

Kein Anbieter veröffentlicht Energieverbrauchsmetriken pro Aufgabe. Die Preise pro Token sind öffentlich. Die Wh pro Aufgabe nicht. Die Energietransparenz, die von Haushaltsgeräten verlangt wird, wird nicht von Software-Tools verlangt, die Größenordnungen mehr Energie verbrauchen als jede Waschmaschine.

Von AISHA aus stellen wir eine konkrete Forderung: dass Anbieter von Code-Agents Wh-Metriken pro Aufgabe veröffentlichen, genauso wie sie Preis pro Token und Generierungsgeschwindigkeit veröffentlichen. Es sind keine schwer zu berechnenden Informationen für jemanden, der Zugang zu seinen eigenen Systemen hat. Es sind Informationen, die Nutzer und Engineering-Teams benötigen, um fundierte Entscheidungen zu treffen.

Ein Code-Agent ist nicht besser als ein menschlicher Entwickler. Er ist anders: schneller bei bestimmten Aufgabentypen, energetisch kostspieliger, ohne eigenen Geschäftskontext. Die Entscheidung, ihn sinnvoll einzusetzen, erfordert zu wissen, welche Art von Aufgabe man genau vor sich hat.

Was kann ich tun?

• Wenn du Entwickler bist: Unterscheide, welche Art von Aufgabe du hast, bevor du den Agent aufrufst. Repetitive Aufgabe mit klarem Kriterium → Agent. Offene Exploration → schreib erst mal selbst. Ziehe Aider für Aufgaben in Betracht, bei denen maximale Autonomie nicht nötig ist: x4 weniger Verbrauch bei vergleichbaren Ergebnissen.

• Wenn du ein Engineering-Team leitest: Lege eine Nutzungsrichtlinie fest, nicht nur eine Zugangsregelung. Miss die Gesamtzykluszeit — einschließlich Review und Korrektur des generierten Codes — nicht nur die Generierungszeit. Definiere, welche Aufgabentypen einen vollständigen Agent rechtfertigen versus einfache Assistenz.

• Wenn du CTO oder technisch Verantwortlicher bist: Ein Team von 20 Ingenieuren, die Code-Agents 6 Stunden täglich nutzen, verbraucht das energetische Äquivalent von mehreren hundert Kühlschränken im 24/7-Betrieb. Das ist ein relevantes Datum für ESG und für Betriebskosten, wenn die Rechenleistung nach Nutzung bezahlt wird.

• Wenn du im Bereich technologische Nachhaltigkeit arbeitest: Fordere von Anbietern von Entwicklungstools, dass sie Wh-Metriken pro Aufgabe in ihre Dashboards aufnehmen. Die Kosten pro Token sind bereits veröffentlicht. Die Kosten in Wh sollten es ebenfalls sein — es ist technisch nicht schwierig, es ist eine Entscheidung für Transparenz.