Din kodagent förbrukar mer energi än du gör när du skriver för hand — men lönar det sig?

41 Wh. Så mycket förbrukar en medelsession med Claude Code — data direkt uppmätt av forskaren Simon P. Couch i januari 2026.

Det motsvarar 136 vanliga textförfrågningar. Eller en LED-lampa tänd i fyra timmar. Eller 12 % av den energi din bärbara dator förbrukar under en hel arbetsdag.

Och det är medelsessionen. En komplex session — en hel dag med agenten aktiv — kan nå 50–200 Wh.

Frågan är inte om förbrukningen är hög. Frågan är om det lönar sig.

Vad är en kodagent och varför förbrukar den så mycket

Det finns en grundläggande skillnad mellan en kodassistent och en kodagent.

Klassisk autokomplettering — den ursprungliga GitHub Copilot, smarta snippets — gör ett enda anrop till modellen per förslag. Kostnaden är liten och punktuell: 0,5–2 Wh per arbetssession.

En agent är något annat. Den väntar inte på att du skriver: den agerar. Den tar emot en uppgift i naturligt språk (“implementera autentisering med OAuth”, “migrera dessa tester till det nya API:et”, “hitta och fixa prestandabuggen i checkout”) och agerar autonomt.

För att slutföra den uppgiften gör agenten följande:

• Läser projektfiler — ibland tiotals
• Planerar och bryter ner uppgiften innan den rör koden
• Skriver kod, kör den i en sandbox-miljö och läser utdatan
• Tolkar fel och bestämmer hur de ska åtgärdas
• Börjar om om resultatet inte klarar testerna

En “enkel uppgift” kan utlösa 20–50 anrop till modellen. En komplex uppgift, hundratals. Och varje anrop inkluderar den ackumulerade kontexten — alla lästa filer, hela historiken — vilket gör att antalet tokens per anrop också växer över tid.

Resultatet: förbrukningen skalar inte linjärt med uppgiftens komplexitet. Den skalar superlinjärt.

Datan: verktyg för verktyg

Här är de dokumenterade förbrukningsintervallen för de främsta kodagenterna, med deras multiplikatorer jämfört med en enkel textförfrågan (0,3 Wh som referens):

Några observationer om denna tabell:

Aider är den positiva avvikelsen. Open source-agenten förbrukar x4 färre tokens än Claude Code för likvärdiga uppgifter. Effektivitet är inte ett monopol för kommersiella lösningar.

Devin 2.0 är den mest oförutsägbara. Intervallet 10–60 Wh speglar en enorm varians: dess helautonoma läge kan förbruka lika mycket som en lång session med Claude Code med Opus.

GPT-5.3-Codex fördubblar sin föregångare. Hoppet från x20–x67 till x40–x133 mellan versionerna illustrerar trenden: modeller med integrerat resonemang kostar mer, även om de också är mer kapabla.

Fallet Claude Code: den enda datan med publik metodik

Av hela listan ovan finns det bara en publik analys med detaljerad metodik: den av Simon P. Couch, publicerad i januari 2026.

Couch analyserade sina egna arbetssessioner med Claude Code under flera veckor och dokumenterade följande:

• Medelsession: 592 000 tokens i 24 interaktiva utbyten
• Förbrukning per medelsession: 41 Wh
• Motsvarighet: 136 vanliga textförfrågningar
• Session med intensivt användande (flera instanser, hel dag): 50–200 Wh

“En utvecklare som använder kodagenter 8 timmar om dagen förbrukar energi motsvarande att ha ett kylskåp igång i 24 timmar.” — Simon P. Couch, analys av energiförbrukning för Claude Code, januari 2026

Det som gör denna analys värdefull är inte bara siffran: det är att ingen annan har publicerat liknande data. Varken Anthropic, OpenAI, GitHub eller Cursor. Företagen som säljer dessa verktyg publicerar inte Wh per uppgift. De publicerar bara pris per token — vilket är en proxyvariabel för förbrukningen, men inte motsvarar den verkliga förbrukningen i kontext.

Produktivitetsparadoxen

Här kommer den obekväma delen av analysen: den höga energikostnaden kan vara motiverad om produktivitetsvinsten är verklig.

Intern data från GitHub pekar på +55 % snabbare i avgränsade uppgifter med Copilot Agent. Studier av team som adopterar fullständiga kodagenter rapporterar motsvarigheter av 3–4 arbetsdagar komprimerade till en för vissa typer av uppgifter.

Om det stämmer — och metodiken har begränsningar som vi ska diskutera — kan ROI vara positiv även med energiförbrukningen inräknad.

Men det finns ett problem med dessa data:

Produktivitetsbenchmarks produceras av företagen själva. GitHub mäter effekten av Copilot. Anthropic mäter effekten av Claude Code. Ingen oberoende studie har samtidigt mätt:

1. Utvecklingshastighet
2. Total energiförbrukning
3. Kvalitet på den producerade koden
4. Långsiktig underhållsbarhet
5. Genererad teknisk skuld

Rekyleffekten är verklig och dokumenterad i andra teknologier: när något blir snabbare används det mer. Ett team som adopterar kodagenter gör inte bara samma sak snabbare — de genererar också mer kod, fler iterationer, fler granskningar, fler PR:er. Mer total förbrukning? Troligen ja.

Frågan som ingen besvarar är: genererar den extra koden värde, eller bara ackumulerar den teknisk skuld?

I vilka fall lönar sig kostnaden?

Inte alla användningsfall är lika. Här är situationerna där energikostnaden för en kodagent har tydlig avkastning:

Migreringar och refaktorering med väl definierade mönster. Migrera från en API-version till en annan, uppdatera beroenden, konvertera tester från ett ramverk till ett annat. Agenten känner till mönstret, tillämpar det på hundratals filer med konsistens. Människan skulle behöva dagar; agenten, timmar. Tidsskillnaden har reellt affärsvärde.

Snabb prototypning där tid till marknad spelar roll. I utforskningsfaser med verkliga deadlines — en demo för investerare, en MVP för att validera en hypotes — kan hastighetskostnaden vida överstiga energikostnaden.

Förståelse av stora kodbaser. Be en agent förklara arkitekturen i ett projekt med 200 000 rader, spåra flödet av en funktion eller identifiera alla användningspunkter för ett API. Här läser agenten mer än den skriver, och värdet ligger i syntesen.

Regressionstester och täckning. Generera tester för befintlig väldokumenterad kod är förutsägbart och agenten gör det bra. Den frigjorda mänskliga tiden kan ägnas åt uppgifter med högre kognitivt värde.

I vilka fall lönar det sig INTE?

Öppen utforskning. “Gör något intressant med dessa data.” “Förbättra applikationens prestanda.” “Refaktorera så att det blir renare.” Utan tydliga framgångskriterier itererar agenten utan att konvergera. Många modellanrop, osäkert resultat, manuell granskning oundviklig i alla fall.

Domäner som modellen inte behärskar väl. Om agenten inte känner till domänen väl — ett mycket specifikt bibliotek, ett ovanligt programmeringsspråk, affärslogik utan dokumentation — kommer den att göra fel och behöva många iterationer för att rätta dem. Hög förbrukning, mediokert resultat.

Uppgifter där hastighet inte spelar roll. Om det inte finns någon deadline, om den genererade koden ändå kommer att behöva grundlig granskning, om teamet kommer att lägga mer tid på att granska det agenten gjorde än det hade tagit att skriva det själv: ROI är negativ.

När den genererade koden skapar mer teknisk skuld än den löser. Agenter optimerar för att slutföra den tilldelade uppgiften. De har ingen egen affärskontext, de känner inte till teamets implicita konventioner, de vet inte vilka delar av koden som är mest kritiska. Koden de genererar kan fungera och ändå vara ett problem om sex månader.

Mätningens bias

Det finns ett strukturellt problem i hur effekten av kodagenter utvärderas:

Produktivitetsstudierna finansieras av de som säljer produktivitet. Den mest citerade studien om Copilots effekt kommer från GitHub, som tillhör Microsoft, som säljer Copilot. Den mest gynnsamma analysen av Claude Code kommer från Anthropic. Detta ogiltigförklarar inte datan, men det kräver att man läser den med kritiskt sinne.

Framgångsmåtten är biasade mot det som är lätt att mäta. Hastighet att slutföra en avgränsad uppgift: mätbart. Kodkvalitet efter sex månader: inte mätbart i en studie på tre veckor. Ackumulerad teknisk skuld: inte heller. Påverkan på utvecklarens förmåga att underhålla och förstå sin egen kod: nästan omöjligt att isolera.

Ingen leverantör publicerar mätvärden för energiförbrukning per uppgift. Tokenpriser är publika. Wh per uppgift är det inte. Den energitransparens som krävs av hushållsapparater krävs inte av mjukvaruverktyg som förbrukar storleksordningar mer energi än någon tvättmaskin.

Från AISHA framför vi en konkret begäran: att leverantörer av kodagenter publicerar mätvärden i Wh per uppgift, på samma sätt som de publicerar pris per token och genereringshastighet. Det är inte svår information att beräkna för den som har tillgång till sina egna system. Det är information som användare och ingenjörsteam behöver för att fatta informerade beslut.

En kodagent är inte bättre än en mänsklig utvecklare. Den är annorlunda: snabbare på vissa typer av uppgifter, mer energikrävande, utan egen affärskontext. Beslutet att använda den väl kräver att man vet exakt vilken typ av uppgift man har framför sig.

Vad kan jag göra?

• Om du är utvecklare: Skilj på vilken typ av uppgift du har innan du anropar agenten. Repetitiv uppgift med tydliga kriterier → agent. Öppen utforskning → skriv själv först. Överväg Aider för uppgifter där maximal autonomi inte behövs: x4 lägre förbrukning för jämförbara resultat.

• Om du leder ett ingenjörsteam: Inför en policy för användning, inte bara för tillgång. Mät den totala cykeltiden — inklusive granskning och korrigering av genererad kod — inte bara genereringstiden. Definiera vilka typer av uppgifter som motiverar fullständig agent kontra enkel assistans.

• Om du är CTO eller tekniskt ansvarig: Ett team på 20 ingenjörer som använder kodagenter 6 timmar dagligen förbrukar energi motsvarande flera hundra kylskåp igång dygnet runt. Det är ett relevant faktum för ESG och för driftkostnader när beräkningskraft betalas per användning.

• Om du arbetar med teknologisk hållbarhet: Kräv att leverantörer av utvecklingsverktyg inkluderar mätvärden i Wh per uppgift i sina dashboards. Kostnaden per token är redan publicerad. Kostnaden i Wh borde vara det också — det är inte tekniskt svårt, det är ett beslut om transparens.