/goal i Claude Code: autonomt läge och Agent View 2026

Ailoots referensdokumentation: ailoot.ai/docs/.

Vad är /goal i Claude Code?#

Tidigare stannade Claude Code efter varje svar och väntade på din nästa prompt. Det fungerade för korta uppgifter, men föll på längre: en API-migrering, att fixa 12 misslyckade tester, att refaktorera en fil på 800 rader – sådana uppgifter kräver 20–30 iterationer, och varje gång behövde du återvända till terminalen.

/goal löser problemet med en enkel idé: skilj ”den som utför arbetet” från ”den som avgör vad som är klart”. Huvudagenten skriver kod. En separat utvärderare (den snabba Haiku-modellen) läser konversationen efter varje tur och besvarar en fråga: ”Är villkoret uppfyllt?” Om inte startar agenten en ny tur. Om ja återgår kontrollen till dig.

Anthropics officiella dokumentation definierar det så här:

Tusentals agenter på natten från en telefon – det är inte marknadsföring, utan Anthropic-ingenjörens nuvarande arbetssätt. Mekanismen som gör det möjligt är kombinationen av /goal + Agent View, som introducerades i samma version den 11 maj 2026.

Varför behövs autonomt läge: vad fanns före och efter 11 maj 2026?#

Idén att ”låta AI arbeta över natten” hade funnits sedan hösten 2025, då Cursor Composer och Cline auto mode redan kunde köras i bakgrunden. Men före 11 maj 2026 krävde Claude Code en manuell wrapper för detta: en cron-uppgift som anropade claude -p var N:e minut, eller en wrapper som bevakade git status och startade nästa prompt.

Det här gör-det-själv-upplägget ledde regelbundet till katastrofer. Den 22 maj 2026 vaknade en utvecklare till en räkning på 6 000 dollar efter att ha låtit ett sådant skript köras över natten. Grundorsaken: Anthropic ändrade i tysthet Claude Codes cache-TTL från en timme till fem minuter utan att meddela det. Cron anropade produktion var 30:e minut – cachen hann löpa ut mellan körningarna. Varje körning byggde upp en historik på 800 000 tokens från grunden. Att skriva färska data till cachen kostar mycket mer än att läsa från en aktiv cache.

Utvecklaren gjorde inget exotiskt – hen använde verktyget precis som Anthropic hade marknadsfört det.

/goal löser problemet med en inbyggd arkitektur:

1. Supervisor-process som håller sessionen utanför terminalen och överlever att fönstret stängs och att den bärbara datorn går i viloläge.
2. Haiku-utvärderare – en billig modell kontrollerar varje tur; utvärderarens tokens kostar småpengar.
3. Hård turgräns i villkoret – du kan uttryckligen skriva or stop after 20 turns, och sessionen garanteras att stanna.
4. Worktree-isolering för bakgrundssessioner – ändringar går till en separat gren utan att röra din arbetskopia.

Skillnaden mot upplägget ”skriv ditt eget bash-skript” är att Anthropic gör alla de här mekanismerna till förstklassiga delar av verktyget, i stället för tredjepartshack.

Så aktiverar du /goal i 3 steg#

Steg 1. Uppdatera Claude Code till 2.1.139 eller senare.

Kontrollera versionen:

claude --version

Om den är äldre än 2.1.139, uppdatera:

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

Versioner mellan 12 och 19 maj 2026 rättade viktiga buggar i den första versionen. I 2.1.140 rättade de en tyst låsning där disableAllHooks blockerade utvärderaren. I 2.1.143 tillkom worktree.bgIsolation: "none" och en korrigering för loopar i stop hooks. I 2.1.144 (19 maj) lades --resume för bakgrundssessioner och agents --json för skriptning till. Minimikravet är 2.1.143.

Steg 2. Skriv /goal med ett villkor.

Öppna en vanlig Claude Code-session och skriv kommandot:

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

Du behöver inte skicka någon separat prompt efteråt – kommandot startar den första turen direkt. Villkoret kan skrivas på svenska, engelska eller en blandning; modellen förstår båda språken. Längdgränsen är upp till 4 000 tecken.

Steg 3. Följ förloppet via det aktiva överlägget.

När /goal startar visas en panel längst ned i terminalen:

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

Det här visar den:

• Turns – hur många turer som har slutförts
• Elapsed – hur lång tid som har gått sedan start
• Tokens – totalt antal förbrukade tokens (den viktigaste siffran för budgetbevakning)
• Last – utvärderarens senaste skäl till att säga ”inte än”

Ett användbart knep: om utvärderaren ger samma skäl tre turer i rad är det ett tecken på att du har fastnat i en loop. Tryck då Ctrl+C eller skriv /goal clear (synonymer: stop, off, reset, cancel), formulera om villkoret och starta igen. Den här regeln förekommer i communityguider om /goal som det främsta tecknet på en loop: ”fast på samma skäl tre gånger – det här är en loop, avsluta.”

Så skriver du ett bra villkor: 5 regler + 5 exempel#

Anthropics dokumentation beskriver tre nödvändiga delar av ett bra villkor:

En färdig mall täcker alla tre delarna på en rad:

/goal [utför arbetet] tills [mätbart slutläge] utan [begränsningar som måste följas]

En färdig mall täcker alla tre delarna på en rad:

/goal [utför arbetet] tills [mätbart slutläge] utan [begränsningar som måste följas]

Fem regler som ställer till det för de flesta:

Regel 1. Slutläget måste kunna verifieras med ett kommando, inte med tycke och smak.

Inte ”få det att se bra ut”, utan npm test exits 0. Inte ”förbättra UX”, utan Lighthouse Performance score above 90. Utvärderaren läser bara transkriptet – den kör inte kommandon och tittar inte på skärmbilder. Om resultatet inte kan dokumenteras i text kommer utvärderaren aldrig att säga ”ja”.

Regel 2. Begränsningarna måste vara uttryckliga och snäva.

Utan begränsningar kan Claude fixa tester genom att radera själva testerna eller kommentera bort misslyckade kontroller. Ange without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Regel 3. En hård turgräns krävs.

Lägg till or stop after N turns i varje villkor. Det är en livlina mot en oändlig loop. Utan en gräns förbrukar en loop som körs i en timme fler tokens än att göra samma uppgift manuellt. Budgetera för detta.

Utan en gräns förbrukar en loop som körs i en timme fler tokens än att göra samma uppgift manuellt. Budgetera för detta.

Regel 4. Beskriv VAD, inte bara HUR.

Om du inte nämnde det visuella i villkoret kommer Claude inte att skapa det. Om villkoret bara kräver ”tester godkända” kan Claude kommentera bort komplexa tester. Beskriv VAD du vill ha, inte bara HUR du ska verifiera det.

Regel 5. Be Claude visa bevis i chatten.

Utvärderaren kör inte kommandon – den läser bara det Claude redan har visat. Om villkoret kräver att ”npm test är grönt” men Claude inte visade utdata från npm test i transkriptet kommer utvärderaren för alltid att säga ”inte än”. Lägg till frasen ”visa utdata från <command> i konversationen” i villkoret.

Fem fungerande exempel för vanliga uppgifter:

1. API-migrering:
/goal every call to getUser() has been replaced with fetchUser(), npm test passes, npm run build is green, no other API names have been touched, or stop after 30 turns

2. Fixa tester:
/goal all failing tests in test/auth are now green (npm test shows 0 fails in the chat), without changing assertions or deleting tests, or stop after 20 turns

3. Kodkvalitet (filstorlek):
/goal src/legacy/UserService.ts has been split into files under 200 lines each, all imports are updated, npm run build is green, or stop after 25 turns

4. Beta av ärendekön:
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a worktree branch, open a PR. Continue until the queue is empty or 6 issues have been processed

5. Säkerhetsgranskning:
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns

Vill du göra mer än att bara köra /goal och bygga ett upplägg där autonomt läge verkligen fungerar i ditt projekt? /goal är bara den sista länken. Innan dess behöver tre grundpelare finnas på plats: en AI-klon (din metodik i Skills och Subagents), en andra hjärna (CLAUDE.md och en plans/-mapp) samt kontexthantering (Plan Mode och /compact). Alla tre komponenterna bör utformas tillsammans – det är kombinationen som stöder arbete med kontext.

5 exempel där /goal fungerar i praktiken#

Anthropics dokumentation anger fyra typer av uppgifter som passar bra för /goal:

Här är fem exempel med färdiga villkor – använd dem och anpassa dem till ditt projekt.

Exempel 1. Migrera en modul till ett nytt API.

Scenario: du går från REST till GraphQL eller ersätter den gamla funktionen getUser() med den nya fetchUser(). Uppgiften är mekanisk men berör 30–50 filer.

Villkor:

/goal every getUser() in src/ has been replaced with fetchUser(), all calls updated to the new interface (id instead of userId), npm test passes, no files outside src/ touched, or stop after 30 turns

Varför det fungerar: slutläget kan kontrolleras med grep -r getUser src/ | wc -l (bör vara 0) och npm test exits 0. Begränsningen skyddar testfilerna.

Exempel 2. Fixa misslyckade tester.

Scenario: efter en biblioteksuppdatering fallerade 15 tester. Du vet att lösningen är mekanisk – uppdatera mockar och justera kontrollerna till det nya formatet. Du vill inte göra det för hand.

Villkor:

/goal all failing tests in test/ are now green, npm test shows the results in the chat with 0 failures, without deleting tests or commenting out assertions, or stop after 25 turns

Ett annat exempel på samma sorts villkor:

Fixa alla misslyckade tester tills npm test ger 0, utan att ändra någon fil utanför katalogen /auth

Ett annat exempel på samma sorts villkor:

Fixa alla misslyckade tester tills npm test ger 0, utan att ändra någon fil utanför katalogen /auth

Exempel 3. Dela upp en gudaklass.

Scenario: en fil på 1 200 rader innehåller allt – modellen, tjänsten, hjälpfunktionerna och API-klienten. Du vill dela upp den enligt principen ”en fil, ett ansvarsområde”, uppdatera alla importer och låta testerna fortsätta godkännas.

Villkor:

/goal src/legacy/UserService.ts has been split into files under 200 lines, each file handles one responsibility (model, repository, api-client, validator), all imports are updated, npm run build is green, existing tests pass, or stop after 25 turns

Exempel 4. Beta av ärendekön över natten.

Scenario: du har ett repository med öppen källkod och 20 ärenden märkta good-first-issue. Du vill att Claude arbetar igenom dem över natten.

Villkor:

/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a separate worktree branch worktree-issue-N, open a PR with a description. Continue until the queue is empty or 6 issues have been processed, or stop after 80 turns

Siffran 6 valdes inte på måfå – det är ett realistiskt tak för en natt med en Pro-plan. Om du vill köra många agenter parallellt behöver du Max eller Enterprise.

Exempel 5. Säkerhetsgranskning.

Scenario: npm audit visar 8 sårbarheter med hög allvarlighetsgrad. Du vill att Claude fixar dem utan att uppdatera större versionsnummer.

Villkor:

/goal every npm audit vulnerability with severity high+ is fixed, npm audit shows 0 high in the chat, all existing tests pass, no breaking API changes, no major version bumps to packages, or stop after 15 turns

Vad du INTE ska göra med /goal:

Croucher formulerar tumregeln kraftfullt i sin fältguide: använd inte /goal för uppgifter där ”klart” betyder ”ser bra ut”, ”känns rätt”, ”väldesignat” eller ”roligt”. Utvärderaren läser bara transkriptet – den kör inte verktyg och kan inte bedöma hur resultatet fungerar. Den här regeln utesluter 80% av subjektiva uppgifter där /goal loopar utan användbart resultat.

När /goal bränner pengar i onödan: 3 antipatterns#

Antipattern 1. Vagt villkor utan en hård turgräns.

Det vanligaste misstaget är ett villkor som ”förbättra koden” / ”gör den bra” / ”optimera den”. Utan en turgräns fortsätter agenten tills den har förbrukat din kvot.

Findskill beskrev ett verkligt fall:

En utvecklare rapporterade att hen hade bränt 200 dollar under en 14-timmarssession med vaga villkor: ett svagt villkor som får utvärderaren att fortsätta säga ”inte än” kan köra i 50, 100 eller 500 turer innan du märker det.

200 dollar under 14 timmar på ett vagt villkor motsvarar hela veckogränsen på Max-planen. Du vaknar på morgonen utan kvot och utan användbart resultat.

Skyddsåtgärd: avsluta varje villkor med or stop after N turns (15 för enkla uppgifter, 50 för svåra och högst 100 för körningar över natten).

Antipattern 2. Rekursiv loop med trasig cache.

6 000 dollar över natten eftersom Anthropic i tysthet ändrade cache-TTL från en timme till 5 minuter. Utvecklaren använde inte /goal direkt, men logiken var densamma: en autonom loop med en cron-timer på 30 minuter byggde varje gång upp en historik på 800 000 tokens från grunden.

Grundproblemet var att extern automatisering inte kände till leverantörens interna ändringar. Samma sak skulle kunna hända med /goal om du kör det i 8 timmar utan tillsyn: tokenförbrukningen växer icke-linjärt och promptcachen fungerar inte som du tror.

Skyddsåtgärder:

1. Kör inte /goal i 8+ timmar utan mellanliggande kontroller.
2. Aktivera användningsgränser i Settings → Usage (en ny skyddsåtgärd efter incidenten på 6 000 dollar).
3. Öppna claude agents två gånger under natten – ta en snabb titt med Space och kontrollera att antalet turer inte ökar snabbare än väntat.
4. För dyra modellkedjor (Opus 4.7), sätt en striktare turgräns – högst 30.

Antipattern 3. Kreativitet via /goal.

Croucher använde /goal för att bygga ett spel – villkoret omfattade determinism, invarianter och kontroll av att nivån gick att klara. Spelet byggdes, testerna godkändes och utvärderaren sade ”uppnått”. Spelet saknade visuella element – villkoret nämnde inte grafik.

Det här illustrerar den allmänna regeln: utvärderaren optimerar exakt det du mäter. Om villkoret inte nämner visuella element kommer de inte att finnas. Om det bara nämner tester kan Claude kommentera bort kontroller.

Skyddsåtgärd: använd inte /goal för något som bygger på smak (design, text, UX). Återgå till en vanlig session eller Plan Mode – där behåller du beslutskontrollen.

Vad är Agent View och hur öppnar du kontrollpanelen?#

Om /goal är kommandot ”arbeta tills du är klar” är Agent View kontrollrummet där du kan se alla sådana kommandon samtidigt. Anthropic beskriver det så här:

Kommando för att öppna den:

claude agents

Ett TUI öppnas – en textbaserad kontrollpanel i terminalen. Sessionslistan finns till vänster, och förhandsvisningspanelen med det senaste meddelandet från den markerade raden finns till höger.

Sex sessionstillstånd:

Viktigaste kortkommandona:

↑ / ↓             bläddra i sessionslistan
Space             förhandsvisningspanel (visa utan att ansluta)
Enter / →         anslut till en session (öppna den)
←                 koppla från (lämna utan att avsluta den)
Ctrl+T            nåla fast (skydda sessionen från att stoppas automatiskt)
Ctrl+X            stoppa sessionen; tryck igen inom 2 sec för att radera
Ctrl+R            byt namn
Ctrl+S            växla gruppering (status ↔ katalog)

Så startar du en bakgrundssession:

Från interaktiv Claude Code:

/bg fix the failing test test/auth/login.test.ts

Eller direkt från skalet:

claude --bg "fix the failing test test/auth/login.test.ts"

Eller med ett namn (så att den visas i Agent View med en igenkännbar etikett):

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

Bakgrundssessionen läggs automatiskt till i Agent View – starta med --bg, öppna claude agents så ser du den i listan.

Den viktigaste funktionen: sessioner överlever att den bärbara datorn går i viloläge och att fönstret stängs:

Men stäng av datorn eller starta om den manuellt, så avslutas bakgrundssessionerna som misslyckade. Övernattningskörningar med många bakgrundsagenter fungerar bara på en bärbar dator som inte stängs av.

Worktrees: så isolerar Claude parallella sessioner#

Worktrees löser huvudproblemet med parallellt autonomt arbete: tänk om två sessioner försöker redigera src/auth.ts samtidigt? Före 2.1.139 kunde sådana sessioner faktiskt skriva över varandras ändringar. Med Agent View införde Anthropic automatisk isolering:

Så fungerar det i praktiken:

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice

Varje session arbetar i sin egen kopia. När uppgiften är klar sammanfogar du de grenar du behöver till main.

Riskabel fallgrop – om du raderar en session raderas dess worktree.

Om du avslutar en session i Agent View (tryck Ctrl+X två gånger) försvinner dess worktree. Alla ej incheckade ändringar går förlorade. Innan du raderar en session i Agent View ska du alltid göra en commit eller pusha.

Välj bort isolering (för ovanliga fall):

Om du har ett repository där git worktrees inte fungerar (till exempel en konfiguration med symlänkar eller ett stort monorepo med långsam checkout) kan du inaktivera isoleringen:

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

Då redigerar bakgrundssessionerna din arbetskopia direkt. Möjligheten att välja bort isolering tillkom i 2.1.143 efter synpunkter från team med stora monorepon.

Parallellism förbrukar kvot:

Det betyder att en Pro-plan (20 dollar/månad) räcker för 1–2 parallella sessioner över natten, inte tio. Om du vill köra många agenter parallellt behöver du Max eller Enterprise.

Kombinera /goal + Plan Mode + subagents för långa uppgifter#

Ett typiskt misstag är att genast skriva /goal build a new feature. Det fungerar inte eftersom utvärderaren inte vet hur en ”färdig funktion” ser ut. Du behöver en plan med kryssrutor som utvärderaren kan verifiera en efter en.

Lager 1. Plan Mode skriver en plan i faser.

Be Claude i Plan Mode skapa en detaljerad ändringsplan uppdelad i 5–7 faser med verifierbara kryssrutor. Spara den som plans/2026-05-24-google-oauth.md. Varje fas har 3–7 kryssrutor med konkreta åtgärder.

Lager 2. Subagents delar upp arbetet per fas.

Om planen kan parallelliseras (till exempel om faserna är oberoende – en backend-endpoint + ett frontend-formulär + en DB-migrering) kan du starta varje fas i en separat bakgrundssession via claude --bg --name "<phase>". Varje session får en egen worktree.

Lager 3. /goal kör cykeln tills kryssrutorna är klara.

/goal all phases 1–7 in plans/2026-05-24-google-oauth.md are complete and marked [x], all tests in test/auth pass (npm test shows 0 failures), npm run build is green, or stop after 50 turns

Efter varje tur läser utvärderaren planen, kontrollerar vilka rutor som är klara och fortsätter om något återstår.

Den här kombinationen bygger på tre komponenter:

• kontexthantering: rätt sammanhang i plans/ – utvärderaren läser det
• andra hjärnan: mappen plans/ lagrar planen mellan sessionerna
• AI-klon: CLAUDE.md anger reglerna som agenten följer

Utan CLAUDE.md kan /goal föreslå en lösning som bryter mot arkitekturen. Utan en plan i plans/ känner utvärderaren inte till framgångskriterierna. Utan subagents finns inga parallella faser; allt sker sekventiellt.

Så jämför du /goal med Codex, Cursor och andra agentlägen#

/goal lägger till separat slutförandekontroll efter varje tur. Andra produkter har olika lägen och lokal CLI, driftad molnuppgift och övervakad redigerarsession är inte utbytbara jämförelseenheter. Beskriv inte all Codex-CLI-användning som molncontainer och anta inte en validerarmodell eller faktureringsmetod för varje Codex-körning.

Använd samma kodförrådsbild och uppgift med samma acceptanskontroller. Dokumentera följande för varje kandidat:

Ett påstående om en fast multipel fler tokens behöver dessa villkor och uppmätta antal för samma lyckade utfall. En benchmarkprocent behöver också benchmarkversion, modell, agentmiljö och körinställningar; Terminal-Bench-procent utan dessa uppgifter ersätter inte de beläggen. Artikeln ger inget oberoende benchmark mellan verktygen.

Välj efter arbetsflödet du behöver: övervakad redigering, avgränsad bakgrundsuppgift eller flertursuppgift med uttryckligt slutförandevillkor. Testa installerad produkts stödda läge i stället för att anta att en hel konkurrent saknar självständig körning. Håll behörighetsgodkännande skilt från uppgiftsfortsättning: automatiskt godkänt verktygsanrop fastställer inte i sig att användarens mål uppnåtts.

/goal jämfört med /loop:

/loop är ett annat kommando från samma version, och det startar periodiska uppgifter med ett tidsintervall (var N:e minut). /goal är villkorsbaserat (tills villkoret är uppfyllt). Använd /loop för cron-liknande uppgifter och /goal för att uppnå ett avgränsat mål.

Från Anthropics dokumentation:

Checklista före start av /goal: 7 punkter#

Checklista före varje körning av /goal:

1. Claude Code-version 2.1.139+ – kontrollera med claude --version och uppdatera om den är äldre. Den rekommenderade minimiversionen är 2.1.143 (15 maj 2026), som rättar loopar i stop hooks.

2. Villkoret innehåller ett verifierbart slutläge – i stället för ”förbättra det”, ange npm test exits 0. Om du inte kan komma på ett bash-kommando för att verifiera resultatet passar /goal inte för den här uppgiften.

3. Det finns en hård turgräns – varje villkor anger or stop after N turns. Använd 15 för enkla uppgifter, 50 för svåra och högst 100 för körningar över natten.

4. Begränsningarna är uttryckliga och snäva – without modifying files outside /auth, without removing existing assertions, without bumping major versions. Utan dem kan Claude fixa tester genom att radera själva testerna.

5. Alla viktiga ändringar är incheckade eller pushade – om du inte arbetar i en worktree (till exempel worktree.bgIsolation: "none") redigerar Claude din arbetskopia. Ett misstag kan då innebära att du förlorar osparat arbete.

6. Användningsgränser är aktiverade i Settings → Usage – en ny skyddsåtgärd efter incidenten på 6 000 dollar. Sätt en gräns per dag, per session och per månad.

7. Agent View claude agents är öppet i ett separat fönster – för långa uppgifter, ta en titt med Space en gång i timmen. Om antalet turer växer snabbare än väntat eller utvärderaren upprepar samma skäl i tre turer ska du trycka Ctrl+C och formulera om villkoret.

En sak till – kör aldrig /goal med --dangerously-skip-permissions på någon annans eller obekant kod. Den kombinationen inaktiverar alla kontroller och låter agenten göra vad den vill i ditt projekt. Författaren till den här analysen använder det bara i en ny worktree där det inte finns något att förlora.

/goal är en kraftfull funktion, men ingen magi. Den fungerar precis så bra som du kan formulera villkoret. Om du kan beskriva ”klart” med ord så att ett kommando kan verifiera det gör /goal resten. Om du inte kan det, återgå till en vanlig session eller Plan Mode.

Du kan fortsätta utforska Ailoot på ailoot.ai.