# /goal i Claude Code: autonom tilstand og Agent View i 2026
> Kommandoen /goal i Claude Code 2.1.139 starter autonom tilstand: agenten arbejder, indtil målet er nået. Jeg forklarer Agent View, worktrees og 5 eksempler.
Source: https://ailoot.ai/blog/da/claude-code-goal-agent-view/
Canonical: https://ailoot.ai/blog/da/claude-code-goal-agent-view/
Language: da
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-102
Revision: sha256-9a34545166f402c388e8be8d3d8d57ba4d387f8ebd12ae94242fdaa99b75600d
Ailoots referencedokumentation: [ailoot.ai/docs/](https://ailoot.ai/docs/).
## Hvad er /goal i Claude Code?
Vigtigste pointer
`/goal` er en kommando i Claude Code 2.1.139+ (udgivet 11. maj 2026), der starter autonom tilstand: Du angiver en afslutningsbetingelse, og Claude skriver kode, kører tests og fortsætter med næste tur, indtil målet er nået. Efter hver tur læser en lille model (Haiku som standard) transskriptionen og svarer ”ja/nej” på betingelsen. Den kan aktiveres i en almindelig session eller i headless-tilstand via `claude -p`.
Tidligere stoppede Claude Code efter hvert svar og ventede på din næste prompt. Det fungerede til korte opgaver, men brød sammen ved lange opgaver: en API-migrering, rettelse af 12 fejlslagne tests, refaktorering af en fil på 800 linjer – den slags opgaver kræver 20–30 iterationer, og hver gang måtte du tilbage til terminalen.
`/goal` løser problemet med en enkel idé: Adskil ”den, der udfører arbejdet” fra ”den, der afgør, hvornår det er færdigt”. Hovedagenten skriver kode. En separat evaluator (den hurtige Haiku-model) læser samtalen efter hver tur og besvarer ét spørgsmål: ”Er betingelsen opfyldt?” Hvis ikke starter agenten en ny tur. Hvis ja, får du kontrollen tilbage.
Anthropics officielle dokumentation definerer det sådan:
Kommandoen /goal angiver en afslutningsbetingelse, og Claude arbejder hen imod den uden at vente på din prompt ved hvert trin. Efter hver tur kontrollerer en lille, hurtig model, om betingelsen er opfyldt. Hvis ikke starter Claude næste tur i stedet for at give kontrollen tilbage til dig. Målet ryddes automatisk, så snart betingelsen er opfyldt.
— Anthropic Docs, https://code.claude.com/docs/en/goal
Tusindvis af agenter om natten fra en telefon – det er ikke markedsføring, men den nuværende praksis hos en Anthropic-ingeniør. Mekanismen, der gør det muligt, er kombinationen af `/goal` + Agent View, som blev introduceret i samme udgivelse den 11. maj 2026.
## Hvorfor er autonom tilstand nødvendig: hvad fandtes før og efter 11. maj 2026?
Vigtigste pointer
Før 11. maj 2026 havde Claude Code ingen indbygget autonom tilstand. Udviklere skrev deres egne bash-scripts med cron-timere, hvilket førte til økonomiske katastrofer – en udvikler brugte 6.000 dollars natten over den 22. maj, fordi cache-TTL'en uden varsel blev ændret fra én time til 5 minutter. `/goal` byggede autonomi ind i selve værktøjet med en supervisor-arkitektur, en turgrænse i betingelsen og en evaluatormodel, der stopper loopsessioner.
Idéen om at ”lade AI arbejde natten over” havde eksisteret siden efteråret 2025, hvor Cursor Composer og Cline auto mode allerede kunne køre i baggrunden. Men før 11. maj 2026 krævede Claude Code en manuel wrapper til det: en cron-opgave, der kaldte `claude -p` hvert N. minut, eller en wrapper, der overvågede git status og startede næste prompt.
Denne gør-det-selv-tilgang førte jævnligt til katastrofer. Den 22. maj 2026 lod en udvikler sådan et script køre natten over og vågnede op til en regning på 6.000 dollars. Grundårsagen: Anthropic ændrede i stilhed Claude Codes cache-TTL fra én time til fem minutter uden at annoncere det. Cron kaldte produktion hvert 30. minut – cachen nåede at udløbe mellem kørslerne. Hver kørsel genopbyggede en historik på 800.000 tokens fra bunden. Det koster langt mere at skrive nye data til cachen end at læse fra en aktiv cache.
Udvikleren gjorde ikke noget usædvanligt – han brugte værktøjet præcis, som Anthropic havde annonceret det.
`/goal` løser problemet med en indbygget arkitektur:
1. **Supervisor-proces**, der holder sessionen uden for terminalen og overlever, at vinduet lukkes, og at den bærbare computer går i dvale.
2. **Haiku-evaluator** – en billig model kontrollerer hver tur; evaluatorens tokens koster småpenge.
3. **Hård turgrænse i betingelsen** – du kan udtrykkeligt skrive `or stop after 20 turns`, så sessionen med sikkerhed stopper.
4. **Worktree-isolering** for baggrundssessioner – ændringer går til en separat gren uden at røre din arbejdskopi.
Forskellen fra tilgangen ”skriv dit eget bash-script” er, at Anthropic gør alle disse mekanismer til førsteklasses dele af værktøjet i stedet for tredjepartshacks.
## Sådan aktiverer du /goal i 3 trin
Vigtigste pointer
Den korte fremgangsmåde: 1) Opdater Claude Code til 2.1.139+ via `claude update` eller `npm i -g @anthropic-ai/claude-code`, 2) skriv `/goal` + en betingelse direkte i sessionen, 3) følg fremdriften via det aktive overlay (forløbet tid, antal ture, tokens). Kommandoen virker både i en interaktiv session og i headless-tilstand `claude -p`. Tryk på `Ctrl+C` for at stoppe den; brug `/goal clear` for at annullere målet.
**Trin 1. Opdater Claude Code til 2.1.139 eller nyere.**
Kontrollér versionen:
```bash
claude --version
```
Hvis den er ældre end 2.1.139, så opdatér:
```bash
claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest
```
Udgivelserne mellem 12. og 19. maj 2026 rettede vigtige fejl i den første version. I 2.1.140 rettede de et lydløst hæng, hvor `disableAllHooks` blokerede evaluatoren. I 2.1.143 kom `worktree.bgIsolation: "none"` og en rettelse af stop hook-loops. I 2.1.144 (19. maj) blev `--resume` til baggrundssessioner og agents `--json` til scripting tilføjet. Minimumskravet er 2.1.143.
**Trin 2. Skriv `/goal` med en betingelse.**
Åbn en almindelig Claude Code-session, og skriv kommandoen:
```
/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns
```
Du behøver ikke sende en separat prompt bagefter – kommandoen starter første tur med det samme. Betingelsen kan skrives på dansk, engelsk eller en blanding; modellen forstår begge sprog. Længdegrænsen er op til 4.000 tegn.
**Trin 3. Følg med via det aktive overlay.**
Når `/goal` starter, vises et livepanel nederst i terminalen:
```
/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail
```
Det viser:
- **Turns** – hvor mange ture der er gennemført
- **Elapsed** – hvor lang tid der er gået siden start
- **Tokens** – samlet antal brugte tokens (det vigtigste tal til budgetovervågning)
- **Last** – evaluatorens seneste begrundelse for at sige ”ikke endnu”
Et nyttigt trick: Hvis evaluatoren giver samme begrundelse tre ture i træk, er det et tegn på, at du sidder fast i et loop. Tryk så på `Ctrl+C`, eller skriv `/goal clear` (synonymer: `stop`, `off`, `reset`, `cancel`), omformulér betingelsen, og start igen. Denne regel nævnes i communityguider til `/goal` som det vigtigste tegn på et loop: ”fastlåst på samme begrundelse tre gange – det er et loop, afslut.”
## Sådan skriver du en god betingelse: 5 regler + 5 eksempler
Vigtigste pointer
En betingelse er en verificerbar afslutningsbetingelse, ikke en prompt. En god betingelse har tre elementer: en målbar sluttilstand (tests består, build er grøn), en verificeringsmetode (`npm test exits 0`) og begrænsninger, der ikke må overtrædes (”ingen ændringer i filer uden for /auth”). Dårlige betingelser er vage (”få det til at se godt ud”), umulige at verificere (”optimer UX”) eller mangler en turgrænse. En udvikler brændte 200 dollars af over 14 timer på en vag betingelse.
Anthropics dokumentation beskriver tre nødvendige elementer i en god betingelse:
En betingelse, der holder over mange ture, indeholder som regel: én målbar sluttilstand – et testresultat, en build-exitkode, et antal filer eller en tom kø; en udtrykkelig verificeringsmetode – hvordan Claude skal bevise det, f.eks. npm test exits 0 eller en ren git status; og vigtige begrænsninger – hvad der ikke må ændres undervejs, f.eks. no other test file is modified.
— Anthropic Docs, https://code.claude.com/docs/en/goal
A ready-made template covers all three elements in one line:
```/goal [udfør arbejdet] indtil [målbar sluttilstand] uden [begrænsninger, der skal overholdes]```
**Fem regler, der giver de fleste problemer:**
**Regel 1. Sluttilstanden skal kunne verificeres med en kommando, ikke med smag og behag.**
Ikke ”få det til at se godt ud”, men `npm test exits 0`. Ikke ”forbedr UX”, men `Lighthouse Performance score above 90`. Evaluatoren læser kun transskriptionen – den kører ikke kommandoer og ser ikke på skærmbilleder. Hvis resultatet ikke kan dokumenteres i tekst, siger evaluatoren aldrig ”ja”.
**Regel 2. Begrænsninger skal være udtrykkelige og snævre.**
Uden begrænsninger kan Claude løse problemer med tests ved at slette selve testene eller kommentere fejlslagne assertions ud. Angiv `without modifying any file outside /auth`, `without removing existing assertions`, `without bumping major versions of dependencies`.
**Regel 3. En hård turgrænse er nødvendig.**
Tilføj `or stop after N turns` til hver betingelse. Det er en livline mod et endeløst loop. Uden en grænse bruger et loop, der kører i en time, flere tokens end at udføre den samme opgave manuelt. Tag højde for det i budgettet.
**Regel 4. Beskriv HVAD, ikke kun HVORDAN.**
Don’t use `/goal` for tasks where “done” means “looks good,” “feels right,” “well designed,” or “fun.” Evaluatoren læser kun transskriptet, den kører ikke værktøjer og kan ikke vurdere, hvordan resultatet fungerer.
Hvis du ikke nævnte det visuelle i betingelsen, skaber Claude det ikke. Hvis betingelsen kun kræver, at ”tests består”, kan Claude kommentere komplekse tests ud. Beskriv HVAD du ønsker, ikke kun HVORDAN du vil verificere det.
**Regel 5. Få Claude til at vise dokumentation i chatten.**
Evaluatoren kører ikke kommandoer – den læser kun det, Claude allerede har vist. Hvis betingelsen kræver, at ”`npm test` er grøn”, men Claude ikke viste outputtet fra `npm test` i transskriptionen, siger evaluatoren ”ikke endnu” for evigt. Føj formuleringen ”vis outputtet fra `` i samtalen” til betingelsen.
**Fem fungerende eksempler på almindelige opgaver:**
```
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. Rettelse af tests:
/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. Kodekvalitet (filstørrelse):
/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. Nedbringelse af backloggen:
/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. Sikkerhedsrevision:
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns
```
Vil du mere end blot at køre `/goal` og opbygge et setup, hvor autonom tilstand virkelig fungerer i dit projekt? `/goal` er kun det sidste led. Før det skal tre grundpiller være på plads: en AI-klon (din metode i Skills og Subagents), en [anden hjerne](https://ailoot.ai/blog/da/claude-code-second-brain/) (`CLAUDE.md` og en `plans/`-mappe) samt kontekstarbejde (Plan Mode og /compact). Alle tre komponenter bør tænkes sammen – det er kombinationen, der understøtter arbejde med kontekst.
## 5 eksempler på, hvor /goal virkelig fungerer
Vigtigste pointer
`/goal` fungerer godt til opgaver med en verificerbar sluttilstand: API-migreringer, rettelse af fejlslagne tests, opdeling af store filer, nedbringelse af backloggen og sikkerhedsrevisioner. Det fungerer dårligt til subjektive opgaver som design, finpudsning af UX, at finde indsigter og kreativt arbejde. Tommelfingerregel: Kan du beskrive ”færdig” med en `bash`-kommando? Hvis ja, egner opgaven sig. Hvis ikke, så gå tilbage til en almindelig session eller Plan Mode.
Anthropics dokumentation nævner fire typer opgaver, der egner sig godt til `/goal`:
Brug goal til større opgaver med en verificerbar sluttilstand: migrér et modul til et nyt API, indtil alle kald kompilerer og tests består; implementér et designdokument, indtil alle acceptkriterier er opfyldt; opdel en stor fil i fokuserede moduler, indtil hvert modul overholder sin størrelsesgrænse; gennemgå en backlog med mærkede issues, indtil køen er tom.
— Anthropic Docs, https://code.claude.com/docs/en/goal
Her er fem eksempler med færdige betingelser – brug dem, og tilpas dem til dit projekt.
**Eksempel 1. Migrér et modul til et nyt API.**
Scenarie: Du går fra REST til GraphQL eller erstatter den gamle funktion `getUser()` med den nye `fetchUser()`. Opgaven er mekanisk, men berører 30–50 filer.
Betingelse:
```
/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
```
Hvorfor det virker: Sluttilstanden kan kontrolleres med `grep -r getUser src/ | wc -l` (bør være 0) og `npm test exits 0`. Begrænsningen beskytter testfilerne.
**Eksempel 2. Ret fejlslagne tests.**
Scenarie: Efter en biblioteksopdatering gik 15 tests i stykker. Du ved, at rettelsen er mekanisk – opdatér mocks, og tilpas assertions til det nye format. Du vil ikke gøre det i hånden.
Betingelse:
```
/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
```
Et andet eksempel på samme type betingelse:
```Fix alle fejlslagne tests, indtil npm test returnerer 0, uden at ændre nogen fil uden for /auth-mappen```
**Eksempel 3. Opdel en gudeklasse.**
Scenarie: Én fil på 1.200 linjer indeholder det hele – modellen, tjenesten, hjælpefunktionerne og API-klienten. Du vil opdele den efter princippet ”én fil, ét ansvarsområde”, opdatere alle imports og sikre, at tests fortsat består.
Betingelse:
```
/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
```
**Eksempel 4. Nedbring issue-backloggen natten over.**
Scenarie: Du har et open source-repository med 20 issues mærket `good-first-issue`. Du vil have Claude til at arbejde sig igennem dem natten over.
Betingelse:
```
/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
```
Tallet 6 er ikke valgt tilfældigt – det er en realistisk grænse for én nat på en Pro-plan.
**Eksempel 5. Sikkerhedsrevision.**
Scenarie: `npm audit` viser 8 sårbarheder med høj alvorlighedsgrad. Du vil have Claude til at rette dem uden at opdatere større versionsnumre.
Betingelse:
```
/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
```
**Hvad du IKKE skal gøre med /goal:**
| Opgavetype | Hvorfor det ikke virker |
|----|----|
| ”Lav en smuk brugergrænseflade” | Evaluatoren ser kun tekst, ikke design |
| ”Find en indsigt i dataene” | Ingen verificerbar sluttilstand |
| ”Optimér sidens UX” | Subjektiv smag; agenten optimerer det, der måles |
| Research / udforskning | Åbent – evaluatoren ved ikke, hvornår det er ”nok” |
| Produktionsudrulning | Eksterne sideeffekter kan ikke rulles tilbage |
| Oprettelse af indhold / markedsføring | Tekstkvalitet kan ikke kontrolleres med en kommando |
Croucher formulerer tommelfingerreglen kraftigt i sin feltguide: Brug ikke `/goal` til opgaver, hvor ”færdig” betyder ”ser godt ud”, ”føles rigtigt”, ”er veldesignet” eller ”er sjovt”. Evaluatoren læser kun transskriptionen – den kører ikke værktøjer og kan ikke vurdere, hvordan resultatet fungerer. Denne regel udelukker 80% af subjektive opgaver, hvor `/goal` går i loop uden et nyttigt resultat.
## Når /goal brænder penge af uden resultat: 3 antipatterns
Vigtigste pointer
Tre typiske antipatterns for `/goal`: en vag betingelse uden turgrænse (en udvikler brændte 200 dollars af over 14 timer), et rekursivt loop med forældet cache (6.000 dollars natten over, fordi cache-TTL'en blev ændret) og kreative opgaver uden en verificerbar sluttilstand (et spil blev genereret uden grafik, mens evaluatoren sagde ”færdig”, selvom grafikken manglede). Sikkerhedsforanstaltningerne er altid at inkludere `or stop after N turns`, angive et målbart resultat og først kontrollere, om opgaven egner sig til autonomi.
**Antipattern 1. Vag betingelse uden en hård turgrænse.**
Den mest almindelige fejl er en betingelse som ”forbedr koden” / ”gør den god” / ”optimér den”. Uden en turgrænse fortsætter agenten, indtil den har brugt din kvote op.
Findskill beskrev et virkeligt tilfælde:
En udvikler rapporterede at have brugt 200 dollars på en 14-timers session med vage betingelser: En svag betingelse, der får evaluatoren til at blive ved med at sige “ikke endnu”, kan køre i 50, 100 eller 500 ture, før du opdager det.
200 dollars over 14 timer for en vag betingelse svarer til hele den ugentlige grænse på Max-planen. Du vågner om morgenen uden kvote og uden et nyttigt resultat.
Sikkerhedsforanstaltning: Afslut hver betingelse med `or stop after N turns` (15 for lette opgaver, 50 for svære og højst 100 for kørsler natten over).
**Antipattern 2. Rekursivt loop med ødelagt caching.**
Historien fra den 22. maj 2026: 6.000 dollars natten over, fordi Anthropic i stilhed ændrede cache-TTL'en fra én time til 5 minutter. Udvikleren brugte ikke `/goal` direkte, men logikken var den samme: Et autonomt loop med en cron-timer på 30 minutter genopbyggede en historik på 800.000 tokens fra bunden hver gang.
Grundproblemet var, at ekstern automatisering ikke kendte til udbyderens interne ændringer. Det samme kunne ske med `/goal`, hvis du kører det i 8 timer uden opsyn: tokenforbruget vokser ikke-lineært, og promptcachen fungerer ikke, som du tror.
Sikkerhedsforanstaltninger:
1. **Kør ikke `/goal` i 8+ timer uden mellemliggende kontroller.**
2. **Aktivér forbrugsgrænser i Settings → Usage** (en ny sikkerhedsforanstaltning efter hændelsen med 6.000 dollars).
3. **Åbn `claude agents` to gange i løbet af natten** – tag et hurtigt kig med `Space`, og kontrollér, at antallet af ture ikke vokser hurtigere end forventet.
4. **For dyre modelkæder (Opus 4.7):** Sæt en strammere turgrænse – højst 30.
**Antipattern 3. Kreativitet via `/goal`.**
Croucher brugte `/goal` til at bygge et spil – betingelsen omfattede determinisme, invarianter og kontrol af, om niveauet kunne gennemføres. Spillet blev bygget, testene bestod, og evaluatoren sagde ”opnået”. Spillet havde ingen visuelle elementer – betingelsen nævnte ikke grafik.
Det illustrerer den generelle regel: Evaluatoren optimerer præcis det, du måler. Hvis betingelsen ikke nævner visuelle elementer, kommer de ikke med. Hvis den kun nævner tests, kan Claude kommentere assertions ud.
Sikkerhedsforanstaltning: Brug ikke `/goal` til noget, der afhænger af smag (design, tekst, UX). Gå tilbage til en almindelig session eller [Plan Mode](https://ailoot.ai/blog/da/claude-code-plan-mode/) – dér beholder du beslutningskontrollen.
## Hvad er Agent View, og hvordan åbner du dashboardet?
Vigtigste pointer
Agent View er et visuelt dashboard til styring af Claude Code-baggrundssessioner. Åbn det med kommandoen `claude agents` i terminalen. Hver baggrundssession vises som en række med en status (Working, Needs input, Idle, Completed, Failed, Stopped). Det er nyttigt, når du kører 2–5 autonome opgaver samtidig – i stedet for at skifte mellem terminaler kan du se alt på én skærm. Det omfatter peek (Space – hurtigt overblik uden at tilknytte), attach (Enter), detach (venstrepil) og pin (Ctrl+T).
Hvis `/goal` er kommandoen ”arbejd, indtil du er færdig”, er Agent View kontrolrummet, hvor du kan se alle de sessioner på én gang. Anthropic beskriver det sådan:
Agent View åbnes med claude agents – én skærm til alle dine baggrundssessioner: hvad der arbejder, hvad der kræver dit input, og hvad der er færdigt. Start nye sessioner, se deres status med et hurtigt blik uden at rulle gennem transskriptioner, og tilknyt kun, når en session har brug for dig.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
**Kommando til at åbne den:**
```bash
claude agents
```
Et TUI åbnes – et tekstbaseret dashboard i terminalen. Sessionslisten er til venstre, og forhåndsvisningspanelet med den seneste besked fra den valgte række er til højre.
**Seks sessionstilstande:**
| Tilstand | Betydning |
|----|----|
| **Working** | Claude arbejder aktivt – foretager værktøjskald eller genererer et svar |
| **Needs input** | Claude venter på dit svar på et konkret spørgsmål eller din tilladelse |
| **Idle** | Sessionen er inaktiv og klar til næste prompt |
| **Completed** | Opgaven er fuldført |
| **Failed** | Sessionen sluttede med en fejl |
| **Stopped** | Sessionen blev stoppet med Ctrl+X eller `claude stop` |
**Vigtigste genveje:**
```
↑ / ↓ gå gennem sessionslisten
Space forhåndsvisningspanel (vis uden at tilknytte)
Enter / → tilknyt en session (gå ind i den)
← frakobl (forlad den uden at afslutte den)
Ctrl+T fastgør (beskyt sessionen mod at blive stoppet automatisk)
Ctrl+X stop sessionen; tryk igen inden for 2 sec for at slette den
Ctrl+R omdøb
Ctrl+S skift gruppering (tilstand ↔ mappe)
```
**Sådan starter du en baggrundssession:**
Fra interaktiv Claude Code:
```
/bg fix the failing test test/auth/login.test.ts
```
Eller direkte fra skallen:
```bash
claude --bg "fix the failing test test/auth/login.test.ts"
```
Eller med et navn (så den vises i Agent View under en genkendelig betegnelse):
```bash
claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"
```
Baggrundssessionen føjes automatisk til Agent View – start med `--bg`, åbn `claude agents`, og så kan du se den på listen.
**Den vigtigste funktion: sessionerne overlever, at den bærbare computer går i dvale, og at vinduet lukkes:**
Sessionstilstanden gemmes på disken og overlever automatiske opdateringer og genstarter af supervisoren. Sessioner gemmes også, når maskinen går i dvale. Når den vågner, genoptages processerne, og supervisoren genopretter forbindelsen til dem i stedet for at behandle pausen som inaktiv tid.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
Men lukker du den bærbare computer ned eller genstarter den manuelt, ender baggrundssessionerne med status Failed. Overnight-kørsler med mange baggrundsagenter fungerer kun på en bærbar computer, der ikke slukkes.
## Worktrees: Sådan isolerer Claude parallelle sessioner
Vigtigste pointer
En worktree er en separat kopi af dit repository i `.claude/worktrees//` på en separat `worktree-`-gren. Når du starter en baggrundssession via `/bg` eller Agent View, flytter Claude den automatisk ind i en worktree, før filer redigeres. Parallelle sessioner kan læse fra det samme checkout, men hver skriver til sin egen kopi, så de overskriver ikke hinandens arbejde. Du kan fravælge det med `worktree.bgIsolation: "none"` i `.claude/settings.json` (en funktion siden 2.1.143).
Worktrees løser hovedproblemet ved parallelt autonomt arbejde: Hvad nu, hvis to sessioner forsøger at redigere `src/auth.ts` på samme tid? Før 2.1.139 kunne sådanne sessioner bogstaveligt talt overskrive hinandens ændringer. Med Agent View indførte Anthropic automatisk isolering:
Enhver baggrundssession, der startes fra Agent View, via /bg eller med claude --bg, starter i din arbejdsmappe. Før filer redigeres, flytter Claude sessionen til en isoleret git-worktree i .claude/worktrees/, så parallelle sessioner læser fra det samme checkout, men hver skriver til sin egen kopi.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
**Sådan fungerer det i praksis:**
```bash
# 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
```
Hver session arbejder i sin egen kopi. Når opgaven er færdig, fletter du de nødvendige grene ind i main.
**Farlig faldgrube – hvis du sletter en session, slettes dens worktree.**
Worktrees, som Claude opretter, fjernes sammen med sessionen i Agent View: flet eller push ændringerne, før du sletter en session, der har redigeret filer i sin egen worktree.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
Hvis du afslutter en session i Agent View (tryk på `Ctrl+X` to gange), forsvinder dens worktree. Alle ikke-committede ændringer går tabt. Før du sletter en session i Agent View, skal du altid committe eller pushe.
**Fravælg isolering (i sjældne tilfælde):**
Hvis du har et repository, hvor git worktrees ikke fungerer (for eksempel et setup med symlinks eller et stort monorepo med et langsomt checkout), kan du deaktivere isoleringen:
```json
// .claude/settings.json
{
"worktree": {
"bgIsolation": "none"
}
}
```
Så redigerer baggrundssessionerne din arbejdskopi direkte. Muligheden for at fravælge isolering kom i 2.1.143 efter klager fra teams med store monorepos.
**Parallelitet bruger kvote:**
Forbrugsgrænser gælder også her: Baggrundssessioner bruger abonnementskvote ligesom interaktive sessioner, så 10 parallelle agenter bruger kvoten cirka 10 gange hurtigere end én.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
Det betyder, at en Pro-plan (20 dollars/måned) rækker til 1–2 parallelle sessioner natten over, ikke ti. Hvis du vil køre mange agenter parallelt, skal du have Max eller Enterprise.
## Sådan kombinerer du /goal + Plan Mode + subagents til lange opgaver
Vigtigste pointer
`/goal` er kun det sidste led i kæden. Før det bruger du [Plan Mode](https://ailoot.ai/blog/da/claude-code-plan-mode/) til at udarbejde en faseopdelt plan i `plans/` og [subagents](https://ailoot.ai/blog/da/claude-code-subagenter/) til at fordele arbejdet. Kombinationen fungerer sådan: 1) Plan Mode skriver en detaljeret plan med verificerbare afkrydsningsfelter, 2) subagents kan arbejde parallelt på forskellige faser i deres egne worktree-grene, 3) `/goal` kører cyklussen ”arbejde → evaluator → næste tur”, indtil alle felter er afkrydset. Uden Plan Mode er `/goal` ubrugelig til komplekse opgaver.
En typisk fejl er straks at skrive `/goal build a new feature`. Det virker ikke, fordi evaluatoren ikke ved, hvordan en ”færdig funktion” ser ud. Du har brug for en plan med afkrydsningsfelter, som evaluatoren kan verificere ét ad gangen.
**Lag 1. Plan Mode skriver en faseopdelt plan.**
Bed Claude i [Plan Mode](https://ailoot.ai/blog/da/claude-code-plan-mode/) om at lave en detaljeret ændringsplan opdelt i 5–7 faser med verificerbare afkrydsningsfelter. Gem den som `plans/2026-05-24-google-oauth.md`. Hver fase har 3–7 afkrydsningsfelter med konkrete handlinger.
**Lag 2. Subagents fordeler arbejdet efter fase.**
Hvis planen kan paralleliseres (for eksempel fordi faserne er uafhængige – et backend-endpoint + en frontend-formular + en DB-migrering), kan du starte hver fase i en separat baggrundssession via `claude --bg --name ""`. Hver session får sin egen worktree.
**Lag 3. `/goal` kører cyklussen, indtil afkrydsningsfelterne er fuldført.**
```
/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 hver tur læser evaluatoren planen, kontrollerer, hvilke felter der er fuldført, og fortsætter, hvis der mangler noget.
**Denne kombination bygger på tre komponenter:**
- kontekstarbejde: den rette kontekst i `plans/` – evaluatoren læser den
- [anden hjerne](https://ailoot.ai/blog/da/claude-code-second-brain/): mappen `plans/` gemmer planen mellem sessioner
- AI-klon: CLAUDE.md fastlægger de regler, agenten følger
Uden CLAUDE.md kan `/goal` foreslå en løsning, der bryder arkitekturen. Uden en plan i `plans/` kender evaluatoren ikke succeskriterierne. Uden subagents findes der ingen parallelle faser; alt foregår sekventielt.
## Sådan sammenligner du /goal med Codex, Cursor og andre agenttilstande
Vigtigste pointer
Den nyttige forskel er, hvordan en opgave fortsætter, hvor den kører, hvilke tilladelser den har, og hvordan fuldførelse kontrolleres. Her findes ingen kildeunderbygget måling under ens betingelser, der dokumenterer en universel tokeneffektivitetsfaktor eller et fast antal trin, hvorefter et andet værktøj mister sammenhæng. Sammenlign faktisk model, klient, version, udførelsestilstand og opgave før valg.
`/goal` tilføjer en separat fuldførelseskontrol efter hver tur. Andre produkter har forskellige tilstande, og et lokalt CLI, en hostet cloudopgave og en overvåget editorsession er ikke udskiftelige sammenligningsenheder. Beskriv især ikke alt Codex CLI-arbejde som en cloudcontainer, og antag ikke én validatormodel eller faktureringsmetode for enhver Codex-kørsel.
Brug samme repositoryøjebliksbillede og opgave med samme acceptkontroller. Registrér disse dimensioner for hver kandidat:
| Dimension | Hvad skal registreres |
|----|----|
| Udførelse | Klient/version og lokal eller hostet runtime |
| Model | Præcis model, ræsonnements-effort og kontekstgrænser |
| Fortsættelse | Hvad starter en ny tur, og hvad stopper den |
| Isolering | Arbejdskopi, tilladelser, hemmeligheder og netværksadgang |
| Resultat | Accepterede kontroller, fejl og menneskelige rettelser |
| Forbrug | Input, cachelæsning/-skrivning, outputtokens, forløbet tid og faktisk faktureringsmetode |
En påstand om en fast faktor for højere tokenforbrug kræver disse betingelser og målte antal for samme vellykkede resultat. En benchmarkprocent kræver ligeledes benchmarkversion, model, testopsætning og kørselsindstillinger; Terminal-Bench-procenter uden disse oplysninger erstatter ikke denne evidens. Artiklen leverer intet uafhængigt benchmark på tværs af værktøjer.
Vælg efter nødvendig arbejdsgang: overvågede redigeringer, en afgrænset baggrundsopgave eller en opgave over flere ture med udtrykkelig fuldførelsesbetingelse. Test det installerede produkts understøttede tilstand frem for at antage, at en hel konkurrent mangler autonom drift. Hold tilladelsesgodkendelse adskilt fra opgavefortsættelse: Automatisk godkendelse af et værktøjskald dokumenterer ikke i sig selv opfyldelse af brugerens mål.
**`/goal` sammenlignet med `/loop`:**
`/loop` er en anden kommando fra samme udgivelse, og den starter periodiske opgaver med et tidsinterval (hvert N. minut). `/goal` er betingelsesbaseret (indtil den er opfyldt). Brug `/loop` til cron-lignende opgaver og `/goal` til at nå et afgrænset mål.
Fra Anthropics dokumentation:
| Tilgang | Næste tur starter, når | Den stopper, når |
|----|----|----|
| `/goal` | Den foregående tur er afsluttet | Modellen bekræfter betingelsen |
| `/loop` | Tidsintervallet er gået | Du stopper den, eller Claude vurderer, at arbejdet er færdigt |
| Stop hook | Den foregående tur er afsluttet | Dit script eller din prompt afgør det |
## Tjekliste før start af /goal: 7 punkter
Vigtigste pointer
Kontrollér 7 punkter før hver `/goal`-kørsel: Claude Code-version 2.1.139+, betingelsen indeholder en verificerbar sluttilstand, der er en hård turgrænse, begrænsningerne er udtrykkelige, alle vigtige ændringer er committet, forbrugsgrænser er aktiveret i Settings, og Agent View er åbent til overvågning. Hvis blot ét punkt mangler, kan det koste dig flere hundrede dollars og tabt arbejde.
Tjekliste før hver `/goal`-kørsel:
1. **Claude Code-version 2.1.139+** – kontrollér med `claude --version`, og opdatér, hvis versionen er lavere. Den anbefalede minimumsversion er 2.1.143 (15. maj 2026), som retter stop hook-loops.
2. **Betingelsen indeholder en verificerbar sluttilstand** – angiv `npm test exits 0` i stedet for ”forbedr den”. Hvis du ikke kan finde på en `bash`-kommando til at verificere resultatet, er `/goal` ikke egnet til denne opgave.
3. **Der er en hård turgrænse** – hver betingelse angiver `or stop after N turns`. Brug 15 til lette opgaver, 50 til svære og højst 100 til kørsler natten over.
4. **Begrænsningerne er udtrykkelige og snævre** – `without modifying files outside /auth`, `without removing existing assertions`, `without bumping major versions`. Uden dem kan Claude løse problemer med tests ved at slette selve testene.
5. **Alle vigtige ændringer er committet eller pushet** – hvis du ikke arbejder i en worktree (for eksempel med `worktree.bgIsolation: "none"`), redigerer Claude din arbejdskopi. En fejl kan betyde, at du mister ikke-gemt arbejde.
6. **Forbrugsgrænser er aktiveret i Settings → Usage** – en ny sikkerhedsforanstaltning efter hændelsen med 6.000 dollars. Sæt en grænse pr. dag, pr. session og pr. måned.
7. **Agent View `claude agents` er åbent i et separat vindue** – ved lange opgaver kan du kaste et hurtigt blik med Space én gang i timen. Hvis antallet af ture vokser hurtigere end forventet, eller evaluatoren gentager samme begrundelse i tre ture, skal du trykke på `Ctrl+C` og omformulere betingelsen.
Et punkt mere – **kør aldrig `/goal` med `--dangerously-skip-permissions` på andres eller ukendt kode**. Den kombination deaktiverer alle kontroller og lader agenten gøre, hvad den vil, i dit projekt. Forfatteren til denne analyse bruger det kun i en ny worktree, hvor der ikke er noget at miste.
`/goal` er en stærk funktion, men ikke magi. Den virker præcis så godt, som du formulerer betingelsen. Hvis du kan beskrive ”færdig” med ord, så en kommando kan verificere det, klarer `/goal` resten. Hvis du ikke kan det, så gå tilbage til en almindelig session eller Plan Mode.
Du kan fortsætte med at udforske Ailoot på [ailoot.ai](https://ailoot.ai/).
## Spørgsmål og svar
### Hvordan skriver jeg en fuldførelsesbetingelse, evaluatoren kan kontrollere?
Angiv ét målbart resultat, kommando eller evidens der beviser det, og begrænsninger som bevarelse af assertions eller bestemte filer. Medtag en udtrykkelig stopgrænse, og kræv verifikationsoutput i samtalen.
### Er en fast tokeneffektivitetsfaktor nok til at vælge agent?
Nej. Ingen måling under ens betingelser understøtter faktoren. Sammenlign samme accepterede opgave, og registrér model, klientversion, udførelsestilstand, cache- og tokenforbrug, forløbet tid og menneskelige rettelser.
## Ailoot · Virksomheden og dens projektportefølje
Ailoot bygger på solid driftserfaring, en stor kundebase, stabil service og løbende kontrol af KPI.
Virksomheden og dens projektportefølje: millioner af kunder; månedligt salg for milliarder.
Ailoot bruger denne driftserfaring til API-adgang til AI-funktioner i kundernes produkter, agenter, applikationer og automatiseringer.