Arkkitehtimalli: anna kalliin mallin päättää ja halvemman kirjoittaa

Lyhyt versio

• Viiden viikon ajan ajoin koodausagenttiani jaettuna: päämalli, Opus ja myöhemmin Fable, lukee, päättää ja tarkistaa, ja työntekijäagentti kirjoittaa koodin kirjallisen briefin pohjalta. Kutsun sitä arkkitehtimalliksi, ja se on nyt julkinen taito: architect-skill GitHubissa , MIT-lisenssillä.
• Päämalli lakkasi kirjoittamasta. 49 arkkitehti-istunnossa se muokkasi lähdetiedostoa 6 kertaa 1 467 kehoitteessa. 275 tavallisessa istunnossa samojen viikkojen aikana se muokkasi 244 tiedostoa 3 081 kehoitteessa. Se on 0,4 vastaan 7,9 sataa kehoitetta kohti.
• Tokenien kokonaismäärä kehoitetta kohti ei laskenut. Se nousi, pahasti, kahden viikon ajan, ja palasi sitten sinne, missä tavalliset istunnot ovat. Muutos on siinä, kuka ne kulutti: Opusin osuus työntekijätokeneista putosi 100 %:sta noin 4 %:iin, ja 14. syyskuuta lähtien kehoite arkkitehti-istunnossa maksaa 364k painotettua tokenia päämallilla, 205k Sonnet-työntekijöillä ja 80k Opus-työntekijöillä.
• Juuri tuo jakautuminen on se, millä tilaukselle on väliä. Claude Max mittaa kaikkien mallien viikkorajaansa kunkin mallin hinnalla, joten Sonnet-token kuluttaa sitä 40 %:lla Opus-tokenin hinnasta, ja Fablella on oma erillinen, tiukempi viikkorajansa, jota mikään työntekijä ei kosketa.
• Kokeilin myös työntekijöiden ohjaamista DeepSeekiin headless Claude Coden kautta. Listahinnoilla sama liikenne maksoi 10 dollaria sen sijaan, että se olisi maksanut 202 dollaria Sonnetilla tai 505 dollaria Opusilla. Tilauksella tuota säästöä ei ole, koska tilaus on jo maksettu. Luovuin siitä. Jos maksat tokeneista, lue se osio silti, sillä luvut ovat koko pointti.

Tämä on sarjan kolmas kirjoitus. Ensimmäinen mittasi, mitä yksi asetus teki konteksti-ikkunalle, 17 % vähemmän tokeneita , ja toinen selittää, mitä konteksti-ikkuna todella maksaa ja miksi. Tämä käsittelee toista vipua: ei sitä, kuinka suuri konteksti on, vaan sitä, mikä malli sitä pitää hallussaan.

Mikä malli on

Koodausagentin istunto tekee kahdenlaista työtä. Se ajattelee: lukee koodikantaa, selvittää mitä pitää muuttaa, päättää nimet ja allekirjoitukset ja reunatapaukset, tarkistaa diffin. Ja se kirjoittaa: kirjoittaa koodin, ajaa testitiedoston, korjaa lintin. Ajattelu on se, missä huippumalli ansaitsee hintansa. Kirjoittaminen ei ole. Suurin osa siitä määräytyy sitä edeltävän päätöksen mukaan, ja pienempi malli toteuttaa päätetyn suunnitelman suunnilleen yhtä hyvin kuin suuri.

Niinpä taito jakaa istunnon. Päämalli on arkkitehti. Se tekee kaiken pääsilmukassa paitsi lähdetiedoston muokkauksen:

• Kuulustelee vaatimusta ja tutkii koodikantaa.
• Tekee suunnittelupäätökset: lähestymistapa, tiedonkulku, nimet, allekirjoitukset, reunatapaukset. Lähin olemassa oleva kuvio, jota peilata. Pienin muutos, joka korjaa juurisyyn.
• Pilkkoo paloiksi, jotka omistavat erilliset tiedostojoukot.
• Kirjoittaa yhden toteutusbriefin per pala.
• Tarkistaa takaisin tulevan diffin, ajaa portit, committoi.

Työntekijä on alialainen, jolla on tuore konteksti-ikkuna. Se saa briefin eikä mitään muuta, kirjoittaa koodin, ajaa briefin nimeämät testitiedostot ja palauttaa lyhyen jäsennellyn raportin. Sen jälkeen sen konteksti heitetään pois. Siitä ei koskaan tule osaa pääistunnon historiaan, millä on enemmän väliä kuin miltä kuulostaa: kaikki, mitä pääistunto lukee, lähetetään uudelleen jokaisella myöhemmällä kutsulla, joten työntekijä, joka lukee kaksitoista tiedostoa ja testilokin omassa kontekstissaan, pitää kaiken sen poissa arkkitehdin laskusta.

Briefi on koko sopimus. Omassani on seitsemän kenttää ja taito on enimmäkseen niiden hyvästä täyttämisestä:

## Implementation brief: <slice>
Goal: one sentence, observable outcome
Context: what exploration found: excerpts, the pattern to mirror, line anchors, gotchas
Files: paths to create/modify, exclusive ownership for this slice
Design: the decided approach: data flow, names, signatures, edge cases
Constraints: project rules that apply: style, layers, security
Out of scope: what not to touch, including files owned by other slices
Verify: exact commands and expected outcome

Briefi sisältää päätöksiä, ei vaihtoehtoja. Jos vielä punnitsen kahta lähestymistapaa, en ole valmis delegoimaan.

On yksi poikkeus. Delegoinnilla on kiinteä yleiskustannus: briefin kirjoittaminen, työntekijän käynnistys, raportin lukeminen, diffin tarkistaminen. Kirjoitusvirheen korjaus, konfiguraatioarvo, versionosto, kuolleen avaimen poisto, yhden rivin korjaus ja sen regressiotesti: ne arkkitehti muokkaa suoraan, koska briefi maksaisi enemmän kuin muokkaus. Testi on kustannus, ei rivimäärä. Heti kun muokkaus vaatii suunnitteluharkintaa tai koskettaa polkua, jonka repo merkitsee kriittiseksi, se menee työntekijälle.

Valmis kasvattamaan liiketoimintaasi?

Aloita ilmainen kokeilujakso tänään ja näe tulokset muutamassa päivässä.

Pyydä demo Kirjaudu sisään

Miksi tilaus muuttaa laskutoimitusta

Jos maksat tokeneista, perustelu on yksinkertainen. Opus 5:n listahinta on 5 dollaria miljoonalta syöttötokenilta ja 25 dollaria miljoonalta tuottotokenilta; Sonnet 5:n 2 ja 10. Jokainen toteutuksen token, joka siirtyy Opusilta Sonnetille, maksaa 40 % siitä, mitä se maksoi.

Maksan tilausta, ja siinä perustelu on erilainen ja mielestäni vahvempi. Claude Maxissa on kaksi viikkorajaa, ei yksi: raja kaikkien mallien yli, jota jokainen token kuluttaa kyseisen mallin hinnalla, ja erillinen, tiukempi raja, jota vain Fable kuluttaa. Opusilla ei ole omaa rajaa. Tämä antaa jaolle kaksi vaikutusta. Sonnet-työntekijän tekemä työ kuluttaa jaettua rajaa 40 %:lla siitä hinnasta, jolla Opus-työntekijä tekisi sen, joten kahden kolmanneksen siirtäminen istunnon tokeneista Sonnetille pidentää viikkoa, vaikka tokenien kokonaismäärä pysyisi samana. Ja kun arkkitehti on Fable, jokainen token, jota se ei kuluta kirjoittamiseen, on token, joka jää rajalle, joka loppuu ensin. Joten vaikka arkkitehtimalli kuluttaisi täsmälleen saman määrän tokeneita kuin tavallinen istunto, se, kuka ne kuluttaa, ratkaisisi silti, milloin viikko loppuu.

Tuo “vaikka” osoittautui tekevän paljon työtä.

Mitä litteraatit kertovat

Claude Code kirjoittaa jokaisen istunnon JSONL-litteraattiin ja jokaisen työntekijäajon sisarustiedostoon istunnon hakemistossa. Minulla on ne kaikki 19. elokuuta lähtien: 324 interaktiivista istuntoa, joissa oli kolme tai enemmän kehoitetta, joista 49 käytti mallia eli synnytti toteuttaja-agentin tai lähetti briefin sellaiselle. Tokenit on painotettu samoin kuin lasku: tuore syöte 1, välimuistiin kirjoitus 1,25 tai 2, välimuistiluku 0,1. CI-ajot on jätetty pois.

Lue sitä vasemmalta oikealle, eikä se ole menestystarina kahdelta ensimmäiseltä viikolta.

24. elokuuta alkaneella viikolla arkkitehti-istunto maksoi 1,40M painotettua tokenia kehoitetta kohti. Tavalliset istunnot samalla viikolla maksoivat 0,42M. Kolme ja puoli kertaa enemmän, ja lähes kaikki ylimäärä oli oranssia: Opus-työntekijöitä. Olin antanut työntekijöille hyvän mallin ja ei sääntöjä, ja ne käyttäytyivät kuin hyvä malli ilman sääntöjä. Opus-työntekijän ajon mediaani oli tuolla viikolla 176 vuoroa. Useat ajoivat koko backendin testisarjan, mikä työntää noin 100 kt tulostetta kontekstiin, joka lähetetään uudelleen jokaisella sen jälkeisellä vuorolla. Yksi kuuden työntekijän istunto 14. syyskuuta, senkin jälkeen kun olin jo alkanut kiristää asioita, poltti silti 245M syöttötokenia 1 585 vuoron aikana tuottaakseen noin kuusituhatta riviä diffiä. Kehoitevälimuisti toimi koko ajan 91,6 %:n osumatarkkuudella. Lasku tuli volyymistä, ei hinnoittelusta.

Työntekijäpalkki näyttää, mihin säännöt iskivät. Kolme niistä teki suurimman osan työstä, ja kirjoitin ne agenttien määritelmiin enkä briefiin, joten ne pätevät riippumatta siitä, muistanko ne:

• Työntekijä ei koskaan aja täyttä testisarjaa. Se ajaa briefinsä nimeämät testitiedostot. Arkkitehti ajaa portit.
• maxTurns on rajattu agentin määritelmässä, 140 Sonnetille ja 160 Opusille. Pala, joka tarvitsee 250 vuoroa, oli briefattu väärin.
• Pala pysyy alle noin kahdessatoista tiedostossa ja briefi alle noin 8 kt:ssa. Myös briefi lähetetään uudelleen joka vuorolla.

31. elokuuta alkaneella viikolla työntekijäajon mediaani oli 57 vuoroa ja 0,8M painotettua tokenia. 14. syyskuuta lähtien, kun siirsin oletusreitin Sonnetille, se oli 40 vuoroa ja 0,6M, eikä yksikään työntekijä ole sen jälkeen ajanut täyttä sarjaa.

Kehoitekohtainen kokonaismäärä seurasi perässä: 711k, 425k, 684k, 483k neljän viime viikon aikana, kun tavalliset istunnot olivat 505k, 425k, 318k, 431k. Arkkitehti-istunnot maksavat nyt suunnilleen sen, mitä tavalliset istunnot maksavat. Hieman enemmän kahdella neljästä viikosta, hieman vähemmän yhdellä. Se, mitä ne sillä ostavat, näkyy seuraavissa kahdessa kaaviossa.

Liity uutiskirjeellemme

Saa uusimmat vinkit, trendit ja tarjoukset ilmaiseksi.

Sähköpostiosoite

Tilaa

Päämalli lakkasi kirjoittamasta

Tämä on luku, jota lähdin muuttamaan, ja se muuttui. Tavallisissa istunnoissa päämalli teki 244 Edit- tai Write-kutsua lähdetiedostoihin 3 081 kehoitteen aikana. Arkkitehti-istunnoissa se teki 6 1 467:n aikana. Ne 6 ovat kaikki pienten muokkausten poikkeuksia, jotka pystyn selittämään.

Sillä välin työntekijät olivat tuottavia. 85 työntekijäajoa tekivät 2 510 lähdetiedostomuokkausta. Laskettaessa pääsilmukka ja työntekijät yhteen arkkitehti-istunto tuotti 2 516 koodimuokkausta 1 467 kehoitteesta; tavalliset istunnot tuottivat 943 3 081:stä. Koodimuokkausta kohti arkkitehti-istunto kulutti yhteensä 403k painotettua tokenia ja 330k Opus-perheen mallilla. Tavallinen istunto kulutti 1 410k ja 1 324k. Haluan olla varovainen tuon vertailun kanssa, koska nämä kaksi joukkoa eivät ole sama työ: istunto luokitellaan arkkitehdiksi delegoimalla koodia, joten arkkitehti-istunnot ovat rakenteellisesti koodipainotteisia, ja tavallisiin istuntoihin sisältyy tutkimusta, katselmointeja ja virheenkorjausta, jotka eivät koskaan muokkaa mitään. Lue se niin, että “malli saa paljon koodia kirjoitetuksi per token”, ei nelinkertaisena tehokkuusväitteenä.

Selkeämpi väite on mallien jakautuminen. 14. syyskuuta lähtien kehoite arkkitehti-istunnossa maksaa 364k painotettua tokenia pääsilmukassa, 205k Sonnet-työntekijöillä ja 80k Opus-työntekijöillä. Opus-työntekijöiden osuus kaikista työntekijätokeneista oli 100 % elokuussa ja noin 4 % 21. syyskuuta alkaneella viikolla. Max-suunnitelmassa se tarkoittaa, että jaettua viikkorajaa kulutetaan Sonnetin hinnalla Opusin sijaan lähes kaikessa toteutustyössä, eikä mikään siitä kosketa Fable-rajaa.

Kaksi asiaa ei parantunut, ja sanon sen mieluummin kuin annan kaavioiden antaa ymmärtää muuta. Pääistunnon oma konteksti ei kutistunut: arkkitehti-istunnot kompaktoituivat 8,7 kertaa 100 kehoitetta kohti, kun tavallisilla istunnoilla luku oli 4,7, koska arkkitehti lukee paljon ennen kuin briefaa. Ja malli on hitaampi seinäkellossa pienissä tehtävissä, koska työntekijän käynnistys ja raportti ovat minuutteja, joita et maksa, kun teet muokkauksen itse. Pienten muokkausten poikkeus on olemassa siksi, että taidon ensimmäisessä versiossa ei ollut sellaista, ja katselin itseäni kirjoittamassa 3 kt:n briefiä kahden rivin muutokselle.

DeepSeek-harharetki

Kun työntekijät olivat Sonnet, ilmeinen seuraava kysymys oli, täytyikö niiden olla lainkaan Claude-malli. 13.–18. syyskuuta ohjasin työntekijän DeepSeek V4.1 Flashiin headless Claude Coden kautta, jossa ANTHROPIC_BASE_URL oli asetettu yhteensopivaan päätepisteeseen, ensin OpenRouterin kautta ja sitten natiivisti. Sama briefimuoto, sama raporttimuoto, sama arkkitehti. 2 732 kutsua, 431M syöttötokenia, joista 88 % oli välimuistilukuja, 1,7M tuottotokeneita.

Listahinnoilla 22. syyskuuta tuo liikenne maksaa noin 10 dollaria DeepSeekillä off-peak, 21 dollaria peak-hinnoilla, 202 dollaria Sonnet-API:lla ja 505 dollaria Opus-API:lla. Jos maksaisin tokeneista, tämä olisi kirjoituksen otsikko ja olisin pitänyt sen.

En maksa tokeneista, ja siinä on koko argumentti. Max-tilaus on 100 dollaria kuukaudessa riippumatta siitä, käytänkö 30 % vai 100 % viikkorajasta. Työntekijäliikenteen siirtäminen DeepSeekiin ei laskenut tuota laskua senttiäkään. Se lisäsi sen päälle toisen, 10–21 dollarin viikkolaskun säästääkseen kapasiteettia suunnitelmassa, jonka kapasiteetin olin jo maksanut. Olin sekoittanut “halvempi kuin API” ja “halvempi kuin se, mitä maksan”, eivätkä ne ole sama asia, kun maksamasi summa on kiinteä. Oikea vertailu tilaajalle on DeepSeek vastaan toinen tilaus, ja siinä toinen Claude-suunnitelma tai ChatGPT-suunnitelma Codexilla maksaa suunnilleen saman verran kuin kuukausi kohtalaista DeepSeekin käyttöä ja tulee mukanaan oma viikkoraja, oma malli eikä mitään mitattavaa.

Laatu oli toinen puoli. Viisi backend-palaa palautui puhtaana ja committoitiin sellaisenaan. Yksi frontend-pala poisti viedyn symbolin ja jätti kaikki sen käyttäjät ennalleen, joten puu ei kääntynyt ja myöhemmän palan piti siivota se. Juuri tällainen on se epäonnistuminen, joka tapahtuu mallille, joka toteuttaa spesifikaation, mutta ei mallille, joka päättelee komponentin muodon sen sisaruksista, ja taito sanookin nyt niin: jaetun API-pinnan muutokset menevät Sonnetille, ja työntekijäsääntö kuuluu “älä koskaan poista tai nimeä uudelleen vietyä symbolia siirtämättä jokaista käyttäjää samalla ajolla”. DeepSeek Flash on hyvä toteuttaja. Arkkitehtimalli tarvitsee työntekijän, joka huomaa, kun briefi aliarvioi käyttäjien määrän, ja se on ainoa asia, jota briefi ei voi tarjota.

Niinpä reititystaulukossa on tänään kaksi riviä. Rutiinityö, backend-työ yksityiskohtaisen briefin pohjalta testeineen, frontend-työ, joka noudattaa olemassa olevaa suunnittelukielioppia, ja mikä tahansa muutos jaettuun API-pintaan menevät sonnet-implementerille. Työ, jonka vaikeus on päättelyssä, menee opus-implementerille: asynkroninen kilpailutilanne, monikohteinen refaktorointi, jonka oikeellisuus riippuu kohteista, joita briefi ei pysty luettelemaan, backfill-migraatio, jota yksikään testi ei todista. Reititä muodon, älä koskaan riskin mukaan. Riski muuttaa sitä, kuinka tiukasti diff katselmoidaan ja allekirjoittaako sen ihminen. Se ei koskaan muuta sitä, kuka sen kirjoittaa.

Katselmointisilmukka, jossa malli ansaitsee tai menettää paikkansa

Työntekijän raportti on väite. Taidon katselmointisilmukka on lyhyt ja jokainen rivi syntyi siitä, että poltin näppini:

• Lue raportti ja todellinen git diff. Ristiintarkista työntekijän lainaama diffstat sen kanssa, minkä itse näet.
• Aja keskeinen varmistus itse uudelleen, kun väitteellä on väliä.
• Löysit ongelman? Lähetä korjaus samalle työntekijälle. Sillä on vielä kontekstinsa ja se jatkaa siitä, mihin se jäi. Älä korjaa käsin, älä käynnistä uutta.
• Kaksi epäonnistunutta korjausta tarkoittaa, että briefi oli alimääritelty, ei että malli on liian pieni. Pilko osiin, laita puuttuva ote Context-kenttään, aja uudelleen. Älä kiipeä isompaan malliin, koska se toteuttaa saman väärinkäsityksen sujuvammin.
• Aja rajattu portit ennen kuin hyväksyt mitään: kosketetut testit, lintteri kosketettuihin tiedostoihin, mikä tahansa konventioskripti, jota repo kantaa.

Litteraateissa lähetin noin yhden korjauksen työntekijäajoa kohti, 52: 85:stä, ja 7 Opus-ajoa osui 160 vuoron kattoonsa, jokainen palassa, jonka nyt pilkkoisin. Ne ovat ne kaksi lukua, joita seuraan. Jos korjauksia per ajo kasvaa, briefini käyvät laiskoiksi. Jos työntekijät osuvat kattoon, palani ovat liian suuria.

Mitä tästä kannattaa ottaa mukaan

Jos maksat tokeneista: laita kallis malli päätöksiin ja katselmointiin, laita halpa toteutukseen ja hinnoittele työntekijäliikenteesi listahinnalla ennen kuin valitset, mikä halpa malli. Neljän palkin kaavio on se argumentti.

Jos maksat tilausta: malli ei leikkaa tokenmäärääsi. Se siirtää toteutustokenit mallille, joka kuluttaa jaettua viikkorajaa hitaimmin, säästää Fable-rajan työlle, jonka vain Fable tekee, ja lopettaa kalleimman mallisi vuorojen tuhlaamisen kirjoittamiseen. Älä lisää sivulle mitattua API:ta “säästääksesi” kapasiteettia, jonka olet jo ostanut. Jos työntekijäkapasiteettisi loppuu, osta toinen tilaus.

Kummassakin tapauksessa säännöt, jotka saivat sen toimimaan, olivat tylsiä. Ei täysiä testisarjoja työntekijälle. Rajaa vuorot. Pieniä paloja, lyhyitä briefejä. Korjaa samaa työntekijää kerran ja korjaa sitten briefi.

Taito, kolme agenttimääritelmää ja vartijakoukku ovat osoitteessa github.com/LivinTribunal/architect-skill MIT-lisenssillä. Kumppanitaito, joka kertoo työntekijälle, miten kirjoittaa koodia, joka sopii siihen repoon, johon se laskeutuu, on grain-skill , ja siitä kertova kirjoitus on koodia syiden mukaan .

Menetelmä

Kaikki, mitä kirjoitus kuvaa, on osoitteessa github.com/LivinTribunal/architect-skill : itse taito, briefipohja, reititystaulukko, kolme toteuttaja-agentin määritelmää vuororajoineen ja kontekstisääntöineen sekä vartijakoukku. Asenna se, niin sinulla on kokoonpano, josta alla olevat luvut tulivat.

Istunnot ovat Claude Coden JSONL-litteraatteja 19. elokuuta – 22. syyskuuta 2026, entrypoint cli, kolme tai enemmän käyttäjän kehoitetta. Istunto luokitellaan arkkitehdiksi, jos se synnytti opus-implementerin, opus-implementer-xhighin tai sonnet-implementerin, ajoi ds-slice-työntekijän, kutsui arkkitehtitaitoa tai lähetti toteutusbriefin sisältävän viestin yleiskäyttöiselle agentille, mikä oli se, miten ensimmäiset viikot toimivat ennen nimettyjä agentteja. Työntekijäajot ovat kunkin istunnon hakemiston alialaislitteraatteja. Käyttö on deduplikoitu pyyntötunnuksen mukaan ja painotettu: tuore syöte 1, viiden minuutin välimuistikirjoitus 1,25, tunnin välimuistikirjoitus 2, välimuistiluku 0,1. “Koodimuokkaus” on Edit- tai Write-kutsu .py-, .ts-, .tsx-, .js-, .sql- tai vastaavaan lähdetiedostoon, pois lukien markdown ja kaikki ~/.claude-hakemiston alla. DeepSeekin hinnoittelu on natiivihinta 22. syyskuuta 2026, off-peak ja peak, välimuistiluvut välimuistiosuman hinnalla ja välimuistikirjoitukset tuoreena syötteenä hinnoiteltuina; Claude API:n hinnat ovat julkaistut Opus 5:n ja Sonnet 5:n listahinnat, välimuistiluvut kymmenesosalla syötteestä. 21. syyskuuta alkava viikko on kahden päivän dataa.