Äntligen här! Ralph TUI, visualisera Ralph Loop
Äntligen här! Ralph TUI, visualisera Ralph Loop
Jag skrev tidigare en handledning om ralph-loop, och många vänner som har kört den har gett liknande feedback: Det är grymt, Claude Code kan äntligen köras under lång tid. Men ibland när du observerar den verkar den stå still, och du undrar oundvikligen: "Går den framåt, eller snurrar den bara runt på samma ställe?"
Det är därför jag har hållit på med ralph-tui på sistone.

ralph-tui är inte tvungen att binda sig till Claude Code, den ärver och utvecklar essensen i ralph loop och visualiserar uppgiftsutförandet och processen, vilket avsevärt sänker tröskeln för att få stora modeller att arbeta under lång tid. Du kan helt och hållet ansluta andra agenter, andra modeller, inhemska, billiga, sådana som du har råd att köra under lång tid. Med ralph-tui är det för oss vanliga människor lika betydelsefullt som att byta från manuell växellåda till automatisk växellåda med farthållare.
Vad är det egentligen?
Du kan se ralph-tui som en "AI coding agents loop-orkestrator", men den nöjer sig inte med att bara "kunna köras", den bryr sig mer om att "du kan se, kontrollera och återställa".
Dess grundläggande arbetssätt är mycket enkelt:
- Du ger den en massa uppgifter (från PRD eller från andra uppgiftssystem)
- Den väljer den med högst prioritet
- Sätter ihop prompten
- Startar agenten för att utföra den
- Bedömer om uppgiften är slutförd
- Skriver status
- Fortsätter till nästa runda
Viktigt är att du kan se allt detta i terminalen och att du kan stoppa och ta över när som helst. Den officiella beskrivningen är också mycket tydlig: en agent loop orchestrator med interaktivt TUI, och den stöder TUI / headless / remote.
Varför säger jag att den är mer lämpad för "långvarig körning"?
Det största problemet med att köra loopar med skript är inte att de inte kan köras, utan att du inte vet var de har kommit.
Du ser loggarna rulla snabbt, och fläkten snurrar glatt, men du är osäker:
- Upprepar den samma bugg?
- Ändrar den hela tiden samma kod och sedan ändrar tillbaka den?
- Är den redan klar, men har inte avslutats?
- Har den fastnat i en dödlig loop i något test?

ralph-tui:s lösning är mycket "ingenjörsmässig":
- Har ett sessionskoncept, status sparas på disk (.ralph-tui/session.json)
- Kan återställas efter krasch (crash recovery)
- Har en låsmekanism för att undvika att du öppnar flera instanser och förstör katalogen
- Kan även köras headless i CI, och till och med remote med en lyssnare på distans, och den lokala TUI ansluter till den
Kort sagt: Det är mer som att "du hanterar en arbetare som kan skriva kod" än att "du tittar på ett skript som flippar ut".
Hur man installerar
ralph-tui är en del av Bun/TypeScript-ekosystemet, så det är ganska enkelt att installera. Den officiella sidan har också en installationssida.
Kontrollera först att du har bun på din maskin:
bun --versionInstallera sedan ralph-tui (jag ger här en typisk installation, se den officiella installationssidan för detaljer):
bun add -g ralph-tuiKontrollera efter installationen:
ralph-tui --helpOm du är en Node-anhängare och inte vill röra bun, så går det också bra:
npm i -g ralph-tui
Kör ett minimalt slutet loop, innan du gör något stort
Jag rekommenderar att du inte gör något stort direkt när du använder den för första gången, som att "omstrukturera hela repo". Gör bara en sak: Få den att köra igenom en liten, godtagbar uppgift.
Initialisering
Öppna en valfri katalog:
mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setupDetta kommer att gå in i en interaktiv guide, vilket i princip är "installera ralph-tui i din repository", den kommer att:
- Upptäcker automatiskt vilka agenter som är installerade på din maskin (t.ex. Claude Code, OpenCode etc.)
- Genererar en konfigurationsfil i projektet: .ralph-tui/config.toml
- Installerar PRD-generering/uppgiftskonverteringsrelaterade skills (du behöver inte pilla med det manuellt senare)
Min personliga rekommendation: Var inte lat första gången, kör setup en gång.
Generera projekt-PRD
När setup är klar är nästa steg det mest centrala i den officiella handledningen, och det som lämpar sig bäst för att skriva en demo för en officiell konto: create-prd.
ralph-tui create-prd --chat kommandot kommer att gå in i ett konversationsflöde, det kommer att fråga dig om dina behovsmål, gränsvillkor och acceptanskriterier som en produktchef. Efter att ha frågat kommer det att spotta ut två saker direkt i projektet (detta är huvudpunkten):
- En PRD markdown-fil: ./tasks/prd-feature.md
- En körbar uppgiftsfil: ./prd.json
Vid det här laget har du verkligen gått in i ralph-tui:s "standard closed loop":
Behov (PRD) → Uppgift (prd.json) → Kör (run)
Kör igång
Med prd.json är det naturligt att köra:
ralph-tui run --prd ./prd.json Du kommer att se TUI starta och börja loopa: välja uppgift → utföra → bedöma slutförande → skriva status → avsluta eller nästa runda.
Första gången jag kör rekommenderar jag starkt att du lägger till en iterationsgräns, lås in den i en bur först:
ralph-tui run --prd ./prd.json --iterations 5 Efter att ha kört, titta på ändringarna, kör tester, se om PRD och uppgifter uppfyller förväntningarna. Bekräfta att denna länk är öppen, släpp sedan iterationerna och gå sedan till headless/remote, det är det pålitliga tempot.
Vid det här laget kan du i princip bekräfta: Denna loop körs verkligen.
Hur väljer man modell/Agent? Att spara pengar måste sägas ärligt
Jag vet att många är mest bekymrade över: "Kan jag undvika att använda Claude Code? Kan jag använda billigare modeller?"
Svaret är: Ja.
ralph-tui i sig stöder dig att specificera agent och model (det finns exempel i den officiella run-dokumentationen).
Till exempel med Claude Opus:
ralph-tui run --prd ./prd.json --agent claude --model opus Men ärligt talat skulle jag inte använda Opus för att göra "komplettera tester, fixa lint"-jobb, det är för dyrt. Min vana är att skikta:
- Billiga modeller: Kör massor av repetitivt arbete (komplettera tester, komplettera kommentarer, fixa format, lägg till gränser)
- Dyra modeller: Dyker bara upp vid viktiga noder (arkitekturjusteringar, svåra buggar, kärnlogik)
Om du är en vanlig utvecklare är detta tankesätt ännu viktigare. Eftersom du inte har en stor företagsbudget måste du göra kostnaderna kontrollerbara för att kunna köra länge.
Vill du ha det ännu roligare? Låt agenten skriva PRD också
ralph-tui har en design som jag gillar: den stöder skills (i grund och botten en uppsättning agent-plugins).
Det officiella sättet att installera är med add-skill:
bunx add-skill subsy/ralph-tui --all Eller installera till en specifik agent, till exempel claude-code:
bunx add-skill subsy/ralph-tui -a claude-code -g -y Efter installationen kan du använda slash-kommandon i agentsessionen:
/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads Detta är väldigt likt att installera ett plugin i IDE, förutom att detta plugin är för agenten. Dess betydelse är att minska tiden för "manuellt flytt av behov", vilket gör behov → uppgift → utförande mer som ett löpande band.
När ska man använda det? När ska man inte använda det?Jag gillar inte riktigt narrativet "AI kan fixa allt", det är lätt att det blir missvisande. Verktyg är verktyg, de är värdefulla först när de passar in i ett sammanhang.
Scenarier där ralph-tui passar bra
Du har en massa sånt här att göra:
- Komplettera tester (särskilt i gamla projekt)
- Fixa lint / formatering
- Små steg av refaktorisering (samla ihop upprepad kod)
- Lägg till typer i batch, komplettera gränser
- Dela upp krav och mata på dem i en uppgiftskö
Den gemensamma nämnaren för dessa uppgifter är: Många uppgifter, hög grad av repetition, kan godkännas, kan itereras framåt.
Scenarier där du inte ska tvinga in ralph-tui
Du ska göra sånt här:
- En stor engångsrefaktorisering, oklara godkännandekriterier
- Krav som är vaga och bygger på din implicita kunskap
- Kräver mycket kommunikation/bekräftelse mellan team
- Kräver att du gör produktbedömningar
I sådana uppgifter kommer agent loop bara att förstärka förvirringen.
Vad är skillnaden mellan den och ralph-loop (ralph-claude-code)?
ralph-claude-code är mer som ett "autonomt kör-plugin för Claude Code": Skriptet startar det, kör loopen, utgångsdetektering, begränsning och brytare är alla täckta. Du vill ha "snabbt", och det är snabbt.
ralph-tui är mer som en "teknisk kontrollpanel för agent loop": Den är inte fastlåst till någon specifik modell, och inte heller till något specifikt uppgiftssystem. Den vill lösa tekniska problem som "långvarig körning, observerbarhet, kontroll, återställningsbarhet, fjärrstyrning".
Så du frågar mig hur man väljer?
- Du är en Claude Code-användare och vill få igång den snabbt → ralph-claude-code
- Du vill ansluta olika modeller, spara pengar, hantera loopen som en tjänst → ralph-tui
Slutligen: Låt inte den använda din repository som ett laboratorium
Jag har några järnregler för att köra agent loop, skrivna här så att du kan följa dem, så minskar du risken för att det går fel:
- Kör på en branch, spela inte högt spel på main.
- Lägg alltid till --iterations första gången du kör, bekräfta i små steg att den inte kommer att flippa ur.
- Uppgiften måste vara godkännbar: Antingen kan den köra tester, eller kan den köra lint, eller kan den jämföra utdatafiler.
- Du måste lära dig att stanna: Om du ser att den börjar gå i cirklar är det smartare att pausa än att fortsätta bränna pengar.
- Billiga modeller gör grovjobbet, dyra modeller gör det viktiga jobbet: Kostnaden är något man får fram genom drift, inte genom att be till högre makter.Projektadress: https://github.com/subsy/ralph-tui





