` | Parallell mekanisk refaktorering | v2.1.63+ | Varje enhet får sin egen git worktree |
`/goal` är det kommando som mest liknar Ralph Loop. Under huven kontrollerar en utvärderarmodell (Haiku som standard) vid varje tur om målet har uppnåtts. Om inte, kommer nästa iteration med en ledtråd om exakt vad som ska åtgärdas. Om ja, stannar den. Jag har gått igenom `/goal` i detalj i guiden om [att köra Claude Code autonomt över natten med /goal](https://ailoot.ai/blog/sv/goal-mode-claude-code-codex/) – där ingår färdiga scenarier för 14 timmars arbete.
`/batch` är ett ovanligt men kraftfullt kommando. När du behöver göra samma ändring i över 100 filer (API-migrering, komponentbyte, namnbyte) skickar `/batch` varje fil till en separat underagent i dess egen git worktree. Ändringarna krockar inte – varje agent arbetar i en isolerad kopia. Mer om underagenter finns i guiden om [nästlade underagenter](https://ailoot.ai/blog/sv/claude-code-nested-subagents/).
I författarens beskrivning av det här arbetssättet kallas det helt enkelt:
Hårda gränser för `/loop` och `/goal`:
- En uppgift körs så länge Claude Code är öppet. Stäng terminalen så dör loopen. För en seriös nattlig cykel använder du en fjärrserver eller ditt eget skalskript.
- Den maximala livslängden för en återkommande uppgift är **7 dagar** (därefter raderas den automatiskt som skydd mot bortglömda loopar).
- Upp till **50 samtidiga uppgifter** i en session.
Vill du bygga ett upplägg som gör Claude tillförlitlig? Ralph Loop är bara en del av det. Det är värt att överväga alla tre komponenterna: **AI-klon + Second Brain + Context Engineering** – den här kombinationen förvandlar Claude från en ”assistent som hallucinerar” till ett verktyg som du kan ge en uppgift och sedan ägna dig åt annat.
## Så startar du din första autonoma loop på 5 minuter
Det viktigaste
Det snabbaste sättet att börja är med det inbyggda `/goal`. Öppna Claude Code, ange ett kommando med ett mål och ett verifierbart stoppvillkor och ägna dig åt annat. Claude genererar kod, kör tester, läser felmeddelanden, rättar dem och kör testerna igen tills de går igenom.
5 steg:
1. ### Öppna projektet i Claude Code
Gå till projektroten i terminalen och kör `claude`. Vänta tills Claude har läst `CLAUDE.md` och indexerat kodförrådet.
2. ### Definiera ett mål och ett stoppvillkor
Målet är det som behöver göras. Stoppvillkoret är hur Claude vet att det är klart. Helst är det ett kommando som returnerar 0 eller 1. Exempel: ”Mål: alla 23 tester i `tests/api/*.test.ts` ska gå igenom. Stoppa när `pnpm test` returnerar avslutskod 0.”
3. ### Kör /goal
Kommando:
```
/goal Alla tester i tests/api/*.test.ts måste gå igenom. Kör pnpm test, läs felen, rätta dem och kör testet igen. Stoppa när avslutskoden = 0. Högst 20 iterationer.
```
Claude startar loopen: kör tester – upptäcker ett fel – öppnar filen – rättar det – kör dem igen.
4. ### Sätt ett budgettak
Använd `/usage` på en bakgrundsflik för att övervaka användningen. Sätt en token- eller kostnadsgräns för dagen så att du inte bränner hela saldot på en enda loop. Mer information finns i guiden om [hur du undviker att förbruka Claude Code-gränserna](https://ailoot.ai/blog/sv/claude-code-token-limits-saving/).
5. ### Ägna dig åt annat
Kom tillbaka om 30 minuter. Om uppgiften är enkel står det redan ”DONE, alla tester går igenom”. Om den är mer komplicerad läser du rapporten: ”stannade vid iteration 20, orsak X”. Rätta för hand det som loopen inte klarade, starta sedan om den.
```markdown
Hitta 10 skäl till varför det här projektet kan ha gått åt helvete.
Utgå från att något har gått fel.
Jag kan gå igenom den här historien många gånger –
innan jag släpper den till allmänheten.
```
Det vanligaste nybörjarmisstaget är **att starta en loop utan en verifierare**. Agenten stampar på stället: skriver kod, kontrollerar den inte, tror att den är klar, går vidare till nästa iteration och skriver om det den redan gjort. Tre timmar senare är det en enda röra och räkningen är 200 dollar.
Den bästa regeln: **skriv verifieraren först och starta sedan loopen**. Om du inte kan formulera stoppvillkoret på en rad är uppgiften inte redo för autonom körning.
## Hur undviker du att bränna tusentals dollar över natten: budgettak och stoppvillkor
Det viktigaste
En loop utan budgettak, kostnadsbaserat stoppvillkor eller verifierare kan dra på sig en stor räkning innan någon märker det. Tre skyddsåtgärder kan förhindra detta: en iterationsgräns, en token- eller kostnadsgräns och en stagnationsdetektor.
Tre viktiga bromsar för varje nattlig loop:
**1. Iterationsgräns.** `--max-iterations 20`. Loopen kan inte köras mer än N gånger – även om verifieraren inte utlöses. Om den inte har nått stoppvillkoret efter 20 iterationer har uppgiften fastnat och behöver mänsklig inblandning.
**2. Token- eller kostnadsgräns.** `/usage limit 50` – högst 50 dollar per dag. När gränsen närmar sig stannar loopen av sig själv och skickar en avisering.
**3. Framstegskontroll med ett uttryckligt kontrakt.** Jämförelsen av `HEAD` nedan upptäcker nya commits, inte alla kodändringar. Använd den bara i en isolerad worktree där varje iteration som ändrar kod registrerar en lokal checkpoint-commit före jämförelsen. Användbara oincheckade ändringar ändrar inte `HEAD`; utan kontraktet kan en oförändrad hash ge en falsk stagnationssignal. Behåll också verifierarens resultat: en ny commit bevisar en registrerad ändring, inte att uppgiften förbättrades eller godkändes.
Illustrativ struktur för ett omslagsskript med dessa tre kontroller. Raderna för kostnadsrapportering och agentanrop är körarspecifika exempel, inte ett verifierat installationsrecept för CLI; bekräfta gränssnitten för installerad version innan du anpassar dem. Kräv en lokal checkpoint-commit för varje kodändrande iteration om du använder commit-baserad framstegskontroll. Om köraren lämnar ändringar oincheckade ska du stoppa för granskning i stället för att märka dem ”inga framsteg”.
```bash
#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0
for i in $(seq 1 $MAX_ITER); do
# Kostnadsgräns
CURRENT_COST=$(claude usage --json | jq '.cost_usd')
if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
echo "STOP: budget cap $MAX_COST_USD reached"
break
fi
# Kör
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# Kontrollera att uppgiften är klar
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: completion signal"
break
fi
# Bara commit-framsteg: varje kodändrande iteration måste spara en checkpoint-commit.
# HEAD upptäcker inte användbara ändringar som förblir oincheckade.
CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
STAGNATION=$((STAGNATION + 1))
if [ "$STAGNATION" -ge 3 ]; then
echo "STOP: stagnation 3 iterations"
break
fi
else
STAGNATION=0
fi
PREV_HASH="$CURRENT_HASH"
done
```
Verifiera framstegskontrollen innan du bygger ut skelettet: en ändring utan commit ska behandlas som oregistrerat arbete; en checkpoint-commit ändrar `HEAD`; bara den separata verifieraren kan fastställa framgång. Tre oförändrade commits visar inga registrerade ändringar enligt kontraktet, inte att alla arbetsfiler förblev oförändrade. Sedan kan du lägga till: en Slack-avisering när det stannar, en automatisk Telegram-rapport på morgonen, en pushnotis när budgeten når 80 %. Principen är densamma: en loop behöver **bromsar**, inte bara en gaspedal.
## 5 färdiga scenarier för loopar som körs över natten
Det viktigaste
Alla uppgifter lämpar sig inte för en autonom loop. Bra kandidater är uppgifter med en entydig verifierare som fungerar iterativt: tester, refaktorering, övervakning, artikelpipelines, dataimporter. Dåliga kandidater är uppgifter utan formella kontroller eller med flera subjektiva kriterier.
**Scenario 1: Få alla underkända tester att passera**
```
/goal There are 47 failing tests in the tests/ directory. Goal: make them all pass.
Run pnpm test, read stderr, open the file with the error, fix it, and run pnpm test again.
Stop when exit 0. Max 30 iterations.
```
**Scenario 2: Stor refaktorering över 200 filer**
```
/batch Replace the old apiV1 API client with the new apiV2 in all files under `src/**/*.ts`.
Each file gets its own worktree. After the replacement, run tsc --noEmit; fix any errors.
Merge the worktrees at the end.
```
**Scenario 3: Produktionsövervakning över natten**
```
/loop 30m Every 30 minutes, check https://your-app.example.com/api/health.
If it doesn't return 200, read the logs, find the cause, fix it, and redeploy.
Log each iteration to /tmp/night-monitor.log.
```
**Scenario 4: Importera en stor datamängd med deduplicering**
```
/goal Import the CSV file /tmp/import.csv (12,000 rows) into the clients table.
For each row, check for a duplicate by email; if none, insert it; if one exists, update it.
Log conflicts to /tmp/conflicts.log. Stop when the last row has been processed.
```
**Scenario 5: Artikelpipeline (typisk konfiguration)**
För en onlinetjänst eller byrå som regelbundet behöver SEO-artiklar ser scenariot ut så här:
```
/loop 8h Every 8 hours: open the backlog file for topics with status 'queued'.
If a topic is available, run the skill for writing a guide.
Publish to dev. Change the status to 'review'. Notify the person responsible in Telegram.
```
För en entreprenör utan programmerare innebär det här något konkret. Du har ett Claude-konto för 200 $/månad och en vanlig bärbar dator. Du kan starta **5 loopar parallellt** – support, artiklar, mätvärden, testning av en ny produkt och konkurrentbevakning. Var och en körs i en egen Claude Code-flik. På morgonen läser du sammanfattningen. Det här är redan normen för arbete sommaren 2026.
## Fyra vanliga fel i autonoma loopar
Det viktigaste
De flesta fel i autonoma loopar följer fyra mönster: ingen verifierare – agenten avgör själv att den är klar; inget budgettak – loopen kan förbruka en stor del av budgeten över natten; inget tillstånd mellan iterationerna – besluten motsäger varandra; otydligt stoppvillkor – loopen vet inte när den ska stanna.
**Fel 1: ”Hallucinationsloop”**
Agenten bestämmer sig för att den är klar trots att verifieraren inte har aktiverats. Eller så finns ingen verifierare alls. Tre timmar senare säger Claude: ”Allt klart!” – men testerna underkänns, sidan går inte att öppna och ingenting fungerar. Du har redan lagt 80 $ på meningslösa iterationer.
**Åtgärd:** en strikt verifierare (kommandots `exit code`), inte en muntlig kontroll.
**Fel 2: ”Budgeten brändes över natten”**
Utan ett budgettak blir en loop en handgranat utan sprint.
**Åtgärd:** `/usage limit` eller ett externt skript som använder `claude usage --json` för att stoppa loopen när den når en tröskel.
**Fel 3: ”Loopen tappade sammanhanget mellan iterationerna”**
I iteration 1 fattade Claude ett arkitekturbeslut. Vid iteration 7 hade den glömt det och fattat motsatt beslut. Efter 15 iterationer är koden en röra.
**Åtgärd:** ett tillståndslager via `CLAUDE.md` och mappen Second Brain. Loopen **skriver** varje arkitekturbeslut till en fil som den läser i nästa iteration.
**Fel 4: ”Stoppvillkoret är oprecist – loopen kör för evigt”**
`/goal "Make the page beautiful"` – vad betyder ”vacker”? Utan ett entydigt mått kommer loopen aldrig att stanna. Den fortsätter tills den når iterations- eller budgetgränsen.
**Åtgärd:** stoppvillkoret måste alltid vara **mätbart**. Inte ”vacker”, utan ”Lighthouse Performance ≥ 90, Accessibility ≥ 95”. Inte ”fungerar”, utan ”tester i `tests/pricing.test.ts` passerar.”
## När loopteknik inte behövs
Det viktigaste
Loopteknik är ett verktyg för repetitiva, verifierbara uppgifter. Den behövs inte för engångsuppgifter med kreativt innehåll, uppgifter utan en formell verifierare och uppgifter som kräver subjektiv bedömning. Det är viktigare att känna till begränsningarna än att kunna tekniken.
Det här lämpar sig inte för en autonom loop:
- **Engångsuppgift med kreativt innehåll.** En webbplats för en ny produkt, en logotyp, ett strategimemo. En loop är överdrivet här; det är enklare att skriva en prompt och förfina resultatet för hand.
- **Uppgift utan verifierare.** Om du inte kan uttrycka stoppvillkoret som en exitkod eller en entydig signal ska du inte starta loopen; annars blir det ett ändlöst bål.
- **Uppgift som kräver subjektiv bedömning.** ”Få det att låta bättre”, ”förbättra UX så att den blir trevligare” – det här kräver dig, inte en loop.
- **En ny, obekant domän.** Om du själv inte förstår hur ”klart” ska se ut ska du inte köra Claude i en loop. Förstå det först och automatisera sedan.
Och huvudregeln jag lärde mig den hårda vägen:
Den viktigaste frågan innan du startar en loop: **Kan jag beskriva med en enda rad hur jag vet att Claude är klar?** Om ja kan loopen hjälpa. Om inte, definiera först ett verifierbart villkor och starta sedan.
### Källor
- [Ralph Loop Claude Plugin - Anthropic](https://claude.com/plugins/ralph-loop) - officiellt plugin
- [Ralph Wiggum plugin on GitHub - Anthropic](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum) - källkod
- [Claude Code Review - Anthropic blog](https://claude.com/blog/code-review) - förhandsvisning av forskning om granskning av PR:er med flera agenter, 84 % träffsäkerhet
- [Documentation /goal - Claude Code Docs](https://code.claude.com/docs/en/goal) - officiell kommandodokumentation
- [Documentation /loop scheduled tasks - Claude Code Docs](https://code.claude.com/docs/en/scheduled-tasks) - officiell dokumentation
Loopteknik är ett lager ovanpå allt du redan kan om Claude Code. Först behöver du de tre grundpelarna: AI-klon + Second Brain + kontextteknik. Utan dem försämras loopen redan vid iteration 5. Fortsätt utforska Ailoot på [ailoot.ai](https://ailoot.ai/).
## Frågor om den här guiden: Claude Code över natten: loop engineering och Ralph Loop i 2026
### Varför kan oförändrat HEAD felaktigt antyda att loopen inte gjort framsteg?
HEAD identifierar en commit. Användbara ändringar i arbetskopian ändrar inte HEAD förrän de checkas in. Exempeldetektorn kräver därför en lokal checkpoint-commit efter varje iteration som ändrar kod; utan det kontraktet bör du pausa och granska oincheckat arbete i stället för att kalla det stagnation.
### Bevisar en ny commit att loopen förbättrade resultatet?
Nej. Den bevisar bara att en ändring registrerades. Spara verifierarens resultat tillsammans med checkpointen och stoppa på det faktiska acceptansvillkoret. Omslagsskriptets körarspecifika anrop och kostnadsgränssnitt måste verifieras före användning.
## Ailoot · Företaget och dess projektportfölj
Ailoot bygger på etablerad driftserfarenhet, en stor kundbas, stabil service och löpande KPI-kontroll.
Företaget och dess projektportfölj: miljontals kunder; månatlig försäljning för miljarder.
Ailoot använder denna driftserfarenhet för API-åtkomst till AI-funktioner i kundernas produkter, agenter, applikationer och automatiseringar.