För några dagar sedan gjorde Anthropic Fable till en permanent del av Max-abonnemangen. Tajmingen säger sitt: det landade precis efter att OpenAI släppt GPT-5.6 Sol, och – ännu mer relevant – precis efter att Kimi K3 släppt sina vikter. Det krävdes en öppen källkods-modell för att tvinga det största AI-labbet till en verklighetscheck och sätta stopp för marknadsbruset kring dess flaggskepp. Bara det förtjänar en skål från alla som betalar dessa fakturor.
Men “ingår i din prenumeration” är inte samma sak som “billigt”, och det är definitivt inte samma sak som “billigt för alltid”. Därför byggde vi, medan Fable fortfarande mättes per användning, om vårt arbetsflöde så att den dyra modellen mekaniskt blockeras från att skriva kod. Den tänker, planerar och granskar. Billigare modeller skriver. Det här inlägget visar hur det fungerar, och vad det faktiskt gav mätt över varje transkript vi har – 606 verkliga sessioner som spänner över ett produktions-SaaS-monorepo, en drönaroperativ app, en marknadsföringssajt och de CI-agenter som betjänar dem.
Del 1 – fällan och principen
Här är vår ärliga utgångspunkt: vi kan inte längre arbeta utan spjutspetsmodeller. Ingen i teamet skulle kunna hålla nuvarande produktionstakt utan dem – och det beroendet är precis den hävstång de stora labben har. Enligt vår läsning levererar dagens AI-abonnemang betydligt mer beräkningskapacitet än de kostar; det är lockpriser, och lockpriser tar slut. När de gör det betalar den som byggt sin ingenjörskultur kring “obegränsade spjutspetstokens” vad som än begärs.
Det finns två försvar. Det första är att hålla en trovärdig utgång: öppna modeller som DeepSeek och Kimi är det som tvingade fram veckans priskorrigering, och de förblir bara en hävstång om vi faktiskt håller våra arbetsflöden portabla till dem. Det andra är arbetsflödesdisciplin: spendera spjutspetstokens bara där inget billigare fungerar. Det här inlägget handlar om det andra – eftersom det är det man kan börja med på måndag.
Principen är tillräckligt gammal för att ha en byggnad uppkallad efter sig: arkitekten lägger inte tegelstenar. En spjutspetsmodells försprång framför en mellanklassmodell är enormt inom design, nedbrytning och granskning – och nära noll när man ska skriva ut ett namnbyte över fyrtio filer. Så dela upp rollerna. Prisstegen säger samma sak i dollar:
Så fungerar fable-architect-mönstret
Färdigheten fable-architect är en markdown-fil på cirka 100 rader plus en shell-krok, som laddas varje gång en Claude Code-session körs på spjutspetsmodellen. Den upprätthåller en arbetsdelning:
- Arkitekten gör: ifrågasätter kravet, utforskar kodbasen, fattar varje designbeslut – angreppssätt, dataflöde, namn, signaturer, kantfall – bryter ner arbetet i oberoende skivor, granskar de returnerade diffarna, kör verifiering och skriver all prosa (planer, briefer, PR-texter, commit-meddelanden).
- Arkitekten gör aldrig: skriver eller redigerar en källkodsfil. Ingen kod i chatten utöver korta signaturer inuti en brief.
Tre saker gör att detta fungerar i praktiken i stället för på en slide.
1. Brieffen är gränssnittet
Varje skiva får en implementeringsbrief. Implementeraren startar med ett färskt kontextfönster – allt som inte står i brieffen måste den återupptäcka eller gissa. Det tvånget är en funktion: det tvingar arkitekten att fatta alla beslut innan den delegerar. En brief innehåller beslut, inte alternativ.
## Implementeringsbrief: <skiva>
Mål: en mening, ett observerbart utfall
Kontext: vad utforskningen redan hittat – utdrag, det närmaste
mönstret att spegla, radankare, fallgropar
Filer: sökvägar att skapa/ändra – denna skivas exklusiva ägo
Design: det beslutade angreppssättet – dataflöde, namn, signaturer, kantfall
Villkor: projektregler som gäller: stil, lager, säkerhet
Ingår inte: vad som inte får röras, inklusive filer som andra skivor äger
Delegering: får denna skiva starta under-implementerare, och hur många
Verifiera: exakta kommandon och förväntat utfall
Två av dessa rader är nyare än resten, och de finns därför att implementerarnivån förändrades under oss – se uppdateringen nedan.
2. Tvingande, inte magkänsla
En skyddskrok av typen PreToolUse bevakar sessionen: om arkitekten försöker redigera en fil som inte är prosa avfyras en behörighetsfråga. Att godkänna frågan är det dokumenterade undantaget för triviala ändringar (ett stavfel, en versionsbump – fall där delegeringskostnaden är högre än att skriva själv). Friktion är policyn. Utan kroken håller “den dyra modellen ska inte koda” exakt till första deadline.
3. Granskningsloopen stänger kvalitetsgapet
Arkitekten läser agentens rapport och den faktiska diffen – och litar inte på någon av dem ensam – och kör om de viktigaste verifieringskommandona när påståendet spelar roll. Hittade den ett problem? Rättelsen går tillbaka till samma agent, som fortfarande har hela sin arbetskontext kvar. Ingen handpåläggning, ingen ny spawn.
Notera att detta är arkitektens verifiering, och den ligger kvar. Det vi har börjat ta bort är den verifiering vi brukade skriva in i brieferna – instruktioner som säger åt implementeraren att dubbelkolla sig själv. Nyare implementerarmodeller gör det utan att bli ombedda, och att be dem göra det igen köper en andra genomgång du redan har betalat för.
Redo att växa ditt företag?
Starta din kostnadsfria provperiod idag och se resultat inom några dagar.
Vad vi mätte
För att kontrollera om detta är en verklig ekonomisk mekanism eller bara en trevlig ritual, grävde vi igenom varje Claude Code-transkript i våra projekt, dubblettrensade API-anrop och prissatte varje token enligt aktuella listpriser. Tre hypoteser, registrerade innan vi tittade på siffrorna per session:
- H1 – Implementerarna står för skrivandet. Om det stämmer bör implementerar-subagenter producera fler output-tokens än arkitektens huvudloop i delegerade sessioner.
- H2 – Delegering är billigare. Om det stämmer bör en omprissättning av implementerarnas arbete enligt arkitektmodellens priser bli betydligt dyrare än vad vi faktiskt betalade.
- H3 – Kvaliteten håller. Den svåra: delegerad kod bör inte kräva mer omarbete än kod som arkitekten skrivit själv.
Grundregler. Ett API-anrop spänner över många transkriptrader som upprepar samma usage-objekt – vi grupperade per request-ID, räknade input- och cache-tokens en gång per anrop och tog den högsta output-ögonblicksbilden (naiv summering per rad överskattar 2–3×). Kostnader använder Anthropics aktuella listpriser – Fable $10/$50, Opus $5/$25, Sonnet $3/$15 per miljon input-/output-tokens – med cache-läsningar på 10 % av inputpriset och cache-skrivningar till sina TTL-specifika priser. 31 av 354 interactive-store-sessioner kvalificerar som fable-architect-sessioner enligt en konservativ klassificerare; siffrorna visar de åtta dyraste. Vi rapporterar kvoter och procenttal i stället för vår absoluta spendering.
Del 2 – kvittona
H1 – Blandat … sa den första bokföringen. I de största delegeringssessionerna håller hypotesen bestämt – upp till 2,3× mer implementerar-output än arkitekt-output. Men över alla 31 fable-architect-sessioner producerade arkitekten fortfarande mer än implementerarna, 3,59M mot 3,15M tokens. Delvis är det rimligt – arkitektens output inkluderar alla planer, briefer och granskningsprosa, vilket är precis dess jobb – och delvis såg det ut som sessioner som delegerade en skiva och behöll resten. Sedan kom vi ihåg att vår sajtomdesign inte alls hade känts arkitekt-tung, och gick för att leta efter de tokens som subagentbokföringen inte kunde se.
Gå med i vårt nyhetsbrev
Få de senaste tipsen, trenderna och erbjudandena gratis.
Den andra kanalen: issue-trackern som delegeringsbuss
Subagentbokföringen har en blind fläck: den ser bara delegering som sker inuti en session. Sessionen för sajtomdesignen – den största posten i diagrammet ovan – visade sig vara något helt annat: en enda arkitektloop-session som körde i 107 timmar i sträck (292 schemalagda väckningar), bröt ner omdesignen i GitHub-issues, taggade dem för vår CI-pipeline och sedan övervakade: pollade körningar, granskade pipelines pull requests och lade uppföljningsissues när QA hittade buggar.
Skrivandet skedde någonstans där vår grävning per session inte ens hade tittat: en separat flotta av självhostade runners, där pipelines steg plan → implementera → gapanalys → granska kördes som 252 oberoende Opus-sessioner under 4,5 dagar, och rörde 48 distinkta issues och PR:er.
H1, återbesökt – Bekräftat i projekt-skala. Räkna båda kanalerna och bilden vänds: pipelinen skrev 10× fler output-tokens än arkitektloopen som skickade ut den (9,07M mot 877k), allt till Opus-priser. Att köra den implementeringsvågen på arkitektens modell skulle ha kostat 2,1× så mycket – för en enda omdesign, under en enda vecka, innan man räknar in subagenterna i sessionen. Ett issue är bara en grövre brief: samma gränssnitt, samma ekonomi, en nivå upp.
H2 – Bekräftad, med en twist. Att prissätta implementerarnas exakta tokenvolymer enligt arkitektmodellens priser gör varje session dyrare – från +2 % till +54 %, 17 % över de åtta största. Riktiga pengar, men mindre än vad 2×-gapet i outputpris antyder. Twisten: output är inte där pengarna går. I den största sessionen kostade arkitektens cache-läsningar ungefär 13× så mycket som allt den skrev – den dominerande utgiften är den dyra modellen som håller och läser om en stor orkestreringskontext, inte att skriva. Delegering begränsar outputräkningen; nästa hävstång är att hålla arkitektens kontext slimmad.
H3 – Inte mätt här. Tokenbokföring kan inte se kodkvalitet. Vad vi kan säga observatoriskt: granskningsloopen är bärande – rapporter och diffar går isär tillräckligt ofta för att det är icke förhandlingsbart att läsa båda – och rättelser som skickas tillbaka till en kontextvarm agent konvergerar snabbt. Om du replikerar detta och mäter omarbete ordentligt vill vi se det, särskilt om det motbevisar oss.
Vad den bredare datan lärde oss
- Adoption är en gradient, inte en strömbrytare. I drönarappen – mindre och snabbare i rörelsen – kör 18 % av sessionerna fable-architect-mönstret; i det äldre SaaS-monorepot är det 9 %. Projektet som delegerade mest gjorde det på båda nivåerna samtidigt: implementerarbriefer i sessionen och 252 pipelinesessioner utskickade via issue-trackern.
- CI-flottan kör inte färdigheten – eftersom den är implementeraren. Våra automatiserade runner-sessioner startar aldrig någon implementerar-subagent, och först lästes det som utebliven adoption. Prompterna säger något annat: var och en är ett pipeline-steg – verifiera, granska, gapanalys – och ungefär sex av tio arbetar mot ett specifikt issue eller PR. I projekt-skala är pipeline-runnarna implementerarnivån.
- Den billigaste nivån har inte haft sin första arbetsdag än. Alla 78+ implementerarkörningar var av Opus-klass; Sonnet-nivån för mekaniska ändringar lades till nyligen och har inte använts. Vilka besparingar detta än mäter, utgör de en undre gräns.
Gränssnittet är poängen: brief in, diff ut – issue in, PR ut. Den dag prishöjningen landar byter du ut muraren, inte processen.
Full transparens. Modeller verifierade från transkriptsträngar, inte antagna. Vi korrigerade oss själva två gånger (en överskattning av tokens per rad, sedan en platshållarpristabell). Kontrafaktiken antar att arkitekten skulle ha spenderat samma tokenvolymer som implementerarna gjorde – felstaplarna går åt båda hållen. Pipelinesessionerna finns i ett transkriptlager som våra två första grävningspass inte omfattade; en bokföringsmässig gräns gömde en delegeringskanal på 9M tokens för oss, och din har förmodligen också en. En ingenjörs projekt, mestadels review-and-fix och feature-arbete – inte en kontrollerad benchmark. Korpusen stänger också innan Opus 5 släpptes: varje siffra ovan är Fable-som-arkitekt över implementerare av Opus-4-klass. Nivåernas priser rörde sig inte när Opus 5 landade, så de uppmätta kvoterna står – men se nästa avsnitt för vad som faktiskt rörde sig.
Uppdatering – stegen rörde sig under oss
Opus 5 släpptes efter att dessa mätningar stängdes, och inget i prisstegen förändrades: Opus kostar fortfarande $5/$25 per miljon input-/output-tokens, Fable fortfarande $10/$50, och diagrammet ovan är fortfarande korrekt. Det som förändrades är förmågan på varje nivå. Anthropic positionerar Opus 5 som ett stegbyte inom djupt resonemang och långsiktigt agentiskt arbete – det vill säga exakt det arbete arkitektrollen består av, till halva arkitektnivåns pris.
Det pekar rakt på vår egen H2-twist. Om arkitektens dominerande kostnad är cache-läsningar, och cache-läsningar faktureras till 10 % av inputpriset, läser en arkitekt som kör på Opus 5 om sin orkestreringskontext för $0,50 per miljon tokens i stället för Fables $1,00. Posten som kostade 13× allt arkitekten skrev halveras. Vi har inte mätt detta – det är aritmetik under samma antagande om lika tokenvolymer som vi flaggade för 2,1×-kontrafaktiken, och det är nästa sak vi tänker testa. Om det håller slutar den intressanta frågan vara vilka modeller och blir om arkitekten behöver den översta nivån alls.
Tre saker med den nya implementerarnivån förändrar själva mönstret, inte bara dess pris:
- Den sträcker sig efter subagenter utan vidare – motsatsen till sin föregångare, som måste övertalas att delegera över huvud taget. En implementerare som tyst startar sina egna implementerare mångdubblar räkningen utan att någon tittar. Därav raden
Delegering:i brieffen: en skiva anger nu om den får förgrena sig, och hur brett. - Den verifierar sitt eget arbete utan att bli ombedd. Verifieringsinstruktioner skrivna för äldre modeller köper nu en redundant andra genomgång, så de tas bort ur brieferna. Arkitektens granskningsloop är orörd.
- Den utökar omfattningen.
Ingår inte:slutar vara boilerplate och blir raden som håller en skiva som en skiva.
Och nivån vi aldrig använde blev vassare medan vi inte tittade: Sonnet 5 kommer nära Opus-kvalitet i kodarbete för $3/$15, med introduktionspris under det fram till slutet av augusti. “Vilka besparingar detta än mäter, utgör de en undre gräns” var en gardering när vi skrev det. Det låter som en underdrift nu.
Del 3 – vart detta medvetet är på väg
Vi styr med avsikt mot en uppdelning som vi tror att varje ingenjörsteam till slut tvingas in i: dyra spjutspetsmodeller enbart för idégenerering, arkitektur och granskning; allt billigare modeller för själva programmeringen. I dag är våra implementerare av Opus-klass. Inget i arbetsflödet ändras när de blir Sonnet-klass, DeepSeek-klass eller Kimi-klass – gränssnittet är modellagnostiskt i sin konstruktion. Det är hela det strategiska värdet: den dag subventionen tar slut och fakturan fördubblas byter team med denna disciplin en konfigurationsrad. Team utan den omförhandlar hela sin kostnadsstruktur under press.
Fable-architect är ett barnsteg – adoptionen är delvis och den billigaste nivån har inte sett sin första körning. Men det är steget som bygger muskeln: att skriva briefer som fullt ut specificerar en skiva, granska diffar du inte skrivit, behandla den dyra modellens uppmärksamhet som en budget. Och omdesignvågen visar vart muskeln leder: när briefer fungerar fungerar issues, och den dyra modellen slutar delta i implementationen helt.
Vad du kan göra på måndag
- Dela rollerna i din agent-harness. En regel på sessionsnivå: spjutspetsmodellen planerar och granskar; delegera alla filändringar till en billigare implementeraragent. I Claude Code är det en färdighet plus subagentdefinitioner – en eftermiddags setup.
- Gör gränsen mekanisk. Lägg till en för-redigering-krok som utmanar den dyra modellens egna filskrivningar. En regel som inte kostar något att bryta bryts före fredag.
- Skriv briefer med en fast mall. Mål, kontext, filer, design, villkor, ingår inte, delegeringsbudget, verifiera. Mallen är disciplinen – och delegeringsbudgeten är det som hindrar en implementerare från att tyst anställa sina egna.
- Granska både rapporten och diffen. Lita aldrig på någon av dem ensam; kör om de verifieringskommandon som spelar roll.
- Mät din egen uppdelning. Dina transkript innehåller redan datan – gruppera per request, prissätt per modell och se vem som faktiskt skriver. Våra visade oss en oanvänd billig nivå och en delegeringskanal på 9M tokens som vi inte kände till.
- Vidga gränssnittet från briefer till issues. En brief delegerar en timmes arbete; ett issue delegerar en dag av det. När dina issues bär acceptanskriterier som en pipeline kan agera på, kan den dyra modellen lägga in arbete i trackern och övervaka i stället för att sitta i loopen för varje skiva.
- Håll en utgång varm. Kör en billig eller öppen modell som implementerare för en lågrisk-skiva i veckan. Portabilitet du aldrig övar är portabilitet du inte har.
- Prissätt om arkitekten, inte bara muraren. Varje modellsläpp flyttar stegpinnarna utan att flytta stegen. Om merparten av din arkitektkostnad är kontext snarare än skrivande är en billigare arkitektnivå värd mer än en billigare implementerarnivå – kolla vilken av dem dina egna transkript säger att du köper.
Labben kommer att fortsätta säga att deras toppmodeller är värda vilket pris som helst, och – frustrerande nog – för bedömningsarbete har de mestadels rätt. Draget är inte att avstå. Det är att sluta betala spjutspetspriser för for-loopar.
