Anthropic skar 80 procent af Claude Codes systemprompt væk

Anthropic har beskrevet, hvordan de bygger konteksten op omkring den nye generation af Claude-modeller. En af oplysningerne var, at de til modeller som Opus 5 og Fable 5 har fjernet mere end 80 procent af Claude Codes systemprompt uden målbare forringelser i deres kodeevalueringer.

Det kan undersøges direkte.

Systemprompten følger med i hvert API-kald, som Claude Code sender. De samtalelogfiler, Claude Code gemmer på computeren, indeholder kun dialogen, men selve API-kaldet kan opsnappes.

Vi satte derfor et lokalt endepunkt op, som registrerede præcis, hvad Claude Code sendte. Derefter kørte vi det samme kald med syv forskellige modeller fra den samme tomme mappe og talte antallet af tegn. Til sidst trak vi den del af Claude Codes binære fil ud, som bestemmer, hvilken prompt den enkelte model modtager.

Anthropics tal holder.

Målingen viste samtidig, at Claude Code sender forskellige korrigerende instruktioner til Fable 5 og Opus 5. Hver model får et sæt instruktioner, som den anden aldrig ser. De instruktioner giver et ret præcist billede af, hvilken adfærd Anthropic forsøger at dæmpe hos de to modeller.

Sådan målte vi

Claude Code kommunikerer med Anthropics API via HTTP. Adressen styres af en miljøvariabel. Peger man den mod en lille lokal server, der gemmer forespørgslen og returnerer et minimalt, gyldigt svar, kan man få hele API-kaldet ned på disken.

Det omfatter systemprompten, beskrivelserne af samtlige værktøjer og den kontekst, der bliver føjet til den første besked.

Vi kørte følgende kald med syv modeller:

claude -p "hi"

Alle kørsler blev foretaget fra den samme tomme mappe og med de samme indstillinger. Kun modelnavnet blev ændret.

Tallene nedenfor er optællinger af de tegn, der faktisk blev sendt i API-kaldene.

Vi kontrollerede også vores omregning fra tegn til tokens. Et rigtigt kald i en af vores kodebaser blev faktureret til 36.909 input-tokens. Vores beregning lød på 33.677. Estimatet lå omkring ni procent for lavt, men var præcist nok til at sammenligne de forskellige dele af konteksten.

Den fælles prompt er blevet 81 procent kortere

Claude Codes systemprompt består overordnet af to dele.

Den første er en fast instruktionskerne, som Anthropic har skrevet, og som ikke afhænger af, hvor Claude Code kører. Den anden består af skiftende oplysninger om blandt andet computeren, arbejdsmappen, hukommelsen og den aktuelle session.

Anthropics artikel handler om den faste kerne. Det er derfor den, vi har målt.

Den gamle instruktionskerne fylder 12.512 tegn og er opdelt i seks afsnit med navnene System, Doing tasks, Executing actions with care, Using your tools, Tone and style og Text output.

I den nye udgave er de seks afsnit erstattet af fem punkter under overskriften Harness. Den fælles kerne fylder nu 2.377 tegn.

Det svarer til en reduktion på 81,0 procent.

Claude Code vælger dog ikke prompt ud fra, om en model tilhører Claude 5-generationen. Valget styres af en liste i Claude Codes kode, og betegnelsen "Claude 5" optræder ikke på listen.

Modeller, hvis navne matcher haiku, sonnet eller Opus 4.7 og ældre, får fortsat den gamle prompt. Sonnet 5 er derfor en Claude 5-model, men modtager stadig den lange udgave.

Den korte prompt bruges til Opus 4.8 og nyere samt Fable.

Fable 5 og Opus 5 får forskellige instruktioner

Hver model har en række egenskaber i Claude Codes modelregister. Opus 5 har flaget opus_5_prompt_bundle, mens Fable 5 har fable_5_mitigations.

Flagene aktiverer hver sin prompttekst. Den ene model ser ikke den andens tillæg.

Vi kontrollerede det både i de opsnappede API-kald og i de funktioner i Claude Codes kode, der slår modellernes egenskaber op.

Fable 5 får ekstra instruktioner om kommunikation

Fable 5 modtager godt 4.000 tegn med instruktioner om, hvordan den skal kommunikere.

Den skal skrive, som om den orienterer en kollega, der har været væk og nu skal sættes ind i sagen. Resultatet skal stå først, og alt, hvad brugeren har brug for, skal være med i turens sidste besked.

Modellen bliver også bedt om at skrive i hele sætninger frem for at bruge:

Fragmenter, forkortelser, pilekæder som A → B → fejler eller jargon.

Derudover får Fable 5 følgende instruktion, som Opus 5 ikke ser:

Du arbejder selvstændigt. Brugeren følger ikke med i realtid og kan ikke svare undervejs. Spørgsmål som "vil du have, at jeg …?" blokerer derfor arbejdet. Handlinger, der kan fortrydes, og som naturligt følger af den oprindelige opgave, skal du blot udføre. Stop kun ved ødelæggende handlinger eller reelle ændringer af opgavens omfang.

Instruktionerne skal blandt andet få modellen til at afslutte arbejdet uden løbende at bede brugeren om tilladelse.

Opus 5 får instruktioner om at holde sig til opgaven

Opus 5 får et andet sæt instruktioner.

Modellen må hverken indsnævre, udvide eller omformulere den opgave, den har fået. Den skal gøre arbejdet færdigt og kun stille spørgsmål, når ethvert rimeligt gæt ville være for usikkert.

Et andet afsnit handler om rettelser. Modellen bliver bedt om ikke at undskylde for eller revidere udsagn, der allerede var korrekte.

Den får også følgende instruktioner:

Kald ikke AgentTool, medmindre brugeren har bedt om det.
Brug ikke workflows eller deep research, medmindre brugeren har bedt om det.

Fable 5 bliver altså korrigeret for sin kommunikation og sin tendens til at spørge om lov. Opus 5 bliver korrigeret for at ændre opgavens omfang, overkorrigere tidligere udsagn og uddelegere arbejdet.

De forskelle fremgår ikke af den offentlige dokumentation, men kan ses direkte i API-kaldene.

Citaterne ovenfor er vores danske oversættelser af den prompttekst, vi opsnappede. Indholdet er bevaret, men den danske ordlyd er vores egen.

Beskrivelserne af de mest brugte værktøjer er også blevet kortere

Modellerne har fortsat adgang til de samme 27 værktøjer. Det er beskrivelserne af dem, der er blevet ændret.

Den samlede reduktion på 23,5 procent dækker over store forskelle. Flere værktøjsbeskrivelser er ikke ændret, mens der er skåret mellem 56 og 87 procent i beskrivelserne af de værktøjer, en kodeagent bruger ofte.

Bash-beskrivelsen er gået fra 10.067 til 1.353 tegn. Den gamle udgave indeholder 35 forekomster af ord som "VIGTIGT", "ALDRIG", "SKAL" og "UNDGÅ". Den nye indeholder én.

Anthropic beskriver ændringen som et skifte fra at "give eksempler" til at "designe grænsefladen".

Agent-værktøjets seks blokke med eksempler er fjernet, og overskriften "hvornår du ikke skal bruge det" er erstattet af "hvornår du skal bruge det".

Parameterskemaerne er derimod ikke ændret. Vi sammenlignede skemaerne for alle 27 værktøjer, og de er identiske ned til den enkelte byte. Der er ingen nye enums og ingen omskrevne feltbeskrivelser.

I Claude Code er ændringen derfor primært foretaget ved at fjerne forklarende tekst.

Ét værktøj er blevet længere.

AskUserQuestion, som modellen bruger til at stille brugeren et spørgsmål med flere svarmuligheder, har fået et ekstra afsnit, som kun Claude 5-modellerne ser.

Værktøjet skal kun bruges, når brugerens svar reelt ændrer det videre arbejde. Hvis der findes et oplagt standardsvar, eller hvis svaret kan findes i kodebasen, skal modellen selv vælge det, oplyse brugeren om valget og fortsætte.

Kortere er altså ikke altid bedre. Der er tilføjet tekst, hvor Anthropic vil ændre modellens vurdering af, hvornår et værktøj skal bruges.

Den lange prompt fik modellen til at følge værktøjsreglerne dårligere

Vi kan ikke kontrollere Anthropics påstand om, at forkortelsen ikke gav målbare forringelser i deres interne evalueringer.

Claude Code har dog en miljøvariabel, der kan tvinge systemet til at bruge enten den gamle eller den nye prompt. Det gør det muligt at sammenligne den samme model på den samme opgave i den samme kodebase.

Vi kørte Opus 5 mod sig selv på to opgaver og gentog hver kombination to gange.

Den ene opgave var snæver og havde et kendt facit. Den anden lød på at undersøge, hvordan en sidecar-tjeneste kunne gøres mere robust, uden at ændre noget i koden.

Det gav otte kørsler.

Prisen var stort set den samme: 4,62 dollar med den korte prompt og 4,58 dollar med den gamle.

Værktøjsbrugen var derimod forskellig.

Med den gamle prompt brugte modellen ikke Read én eneste gang. Den brugte Bash til alle filoperationerne.

Med den korte prompt brugte den Read 29 gange.

Den gamle prompt beskriver ellers reglen udførligt. Bash-beskrivelsen indeholder blandt andet denne instruktion:

Læs filer med Read, ikke med cat, head eller tail. Rediger filer med Edit, ikke med sed eller awk.

Afsnittet om værktøjer begynder desuden med en opfordring til at foretrække specialiserede værktøjer frem for Bash.

Den korte prompt siger det samme i en enkelt ledsætning, men fik alligevel modellen til at følge reglen oftere.

Længere nede i den gamle prompt står der også, at modellen skal "maksimere brugen af parallelle værktøjskald for at øge effektiviteten".

En Bash-kommando som denne samler flere handlinger i ét kald:

cat A && cat B && ls C

Modellen kan dermed følge instruktionen om at samle handlinger, men bryder samtidig reglen om at bruge de specialiserede værktøjer.

Den korte prompt nævner begge hensyn uden at fremhæve det ene med ord som "maksimér". Det kan forklare forskellen, men forsøget er ikke stort nok til at fastslå mekanismen.

Selve adfærden så vi i begge gentagelser.

Bedømmerne foretrak hver prompt i to af fire svarpar

Værktøjsvalget afgør ikke i sig selv, om det endelige svar er bedre.

Vi gav derfor de fire svarpar til fire bedømmere, som ikke vidste, hvilken prompt der var brugt. De blev bedt om at kontrollere svarenes påstande mod kodebasen frem for at vurdere stil og formulering.

Placeringen som "svar A" og "svar B" blev byttet mellem parrene.

Den gamle prompt vandt begge de snævre opslagsopgaver. Den korte prompt vandt begge de åbne rådgivningsopgaver. Den største forskel mellem to svar var til fordel for den korte prompt.

På tværs af de otte svar fandt bedømmerne seks påstande, der kunne afkræftes i koden, i den ene gruppe og fem i den anden.

To kørsler per opgave er for lidt til at afgøre, om fordelingen skyldes prompten eller tilfældigheder.

Der var dog tydelige forskelle i svarenes form.

Den gamle prompt inddelte fundene i "niveau 1 til 5", fulgte en fast skabelon og fremlagde næsten alle konklusioner med samme grad af sikkerhed.

Den korte prompt brugte P0, P1 og P2, indledte med at forklare, hvad den ikke kunne verificere, og sluttede med testplaner og tydelige ikke-mål.

I én af runderne gjorde markeringen af usikkerhed, at den korte prompt afgrænsede problemet korrekt, mens den gamle prompt gav afsnittet en for bred overskrift.

Forsøget viser derfor en tydelig ændring i skrivestil og i måden, modellen markerer usikkerhed på. Det viser ikke, at den ene prompt generelt giver bedre svar end den anden.

Et workflow satte 46 agenter i gang og leverede intet svar

Vi kørte også Opus 5 og Fable 5 på de samme opgaver.

I én af opgaverne skulle modellerne finde alle de steder, hvor frontend og backend kunne komme ud af trit med hinanden, og rangere dem efter risiko.

Fable 5 opdagede i sin første besked, at kodebasen allerede indeholdt en skill til den type analyse. Den kaldte derfor skillen.

Skillen fordelte arbejdet mellem 46 agenter. Undervejs slap kontoens Fable-forbrug op, og processen stoppede uden at levere et samlet svar.

Opus 5 løste den samme opgave selv på 7,7 minutter til 5,46 dollar.

Fable-kørslen varede 53 minutter og kostede 56,01 dollar. Den tog dermed næsten syv gange så lang tid og kostede omtrent ti gange så meget.

Fejlen skyldtes ikke nødvendigvis kvaliteten af de enkelte delanalyser. Processen var afhængig af, at alle dele kunne gennemføres og samles, før forbruget slap op.

Opus 5's prompttillæg indeholder netop en instruktion om ikke at bruge workflows, medmindre brugeren har bedt om det. Det havde brugeren ikke, og Opus 5 løste derfor opgaven uden at kalde workflowet.

Eksemplet viser en konkret ulempe ved at uddelegere en opgave, som modellen kunne have løst selv: Omkostningen og risikoen for fejl vokser med antallet af afhængige delopgaver.

Vi har tidligere skrevet mere om, hvornår den slags orkestrering kan betale sig.

Vores egne instruktioner fylder mere end systemprompten

Vi målte også konteksten i en ny session i en af vores egne kodebaser.

Før modellen var begyndt på opgaven, fordelte konteksten sig sådan:

Claude Codes systemprompt udgjorde kun 7,6 procent af den samlede kontekst.

Vores egen CLAUDE.md i kodebasens rodmappe fyldte 3.526 tokens. Det er omkring 1,4 gange så meget som hele Opus 5-systemprompten.

Når en session arbejder i bestemte undermapper, fylder vejledningerne i dem fire til fem gange så meget som systemprompten.

Workflow-værktøjet står alene for omkring en fjerdedel af al teksten i værktøjsbeskrivelserne.

Den største mulige besparelse ligger derfor ikke nødvendigvis i Anthropics systemprompt. Den ligger i projektets egne instruktioner, værktøjer og hukommelsesfiler.

Målingerne viser også, at en lang regel ikke nødvendigvis bliver fulgt bedre. Står den ved siden af en anden regel, der peger i en anden retning, kan flere forklaringer gøre valget mindre tydeligt.

Den type konflikter opstår let i en CLAUDE.md, der løbende er blevet udvidet, hver gang modellen har gjort noget uventet.

Fjern det, modellen kan finde i kodebasen

Claude Code har i en nyere version fået kommandoen /doctor, som blandt andet foreslår oprydning i projektets instruktioner.

Dens tommelfingerregel er at spørge om hvert afsnit:

Kunne en session, der arbejder i denne kodebase, selv finde frem til det ved at læse koden?

Følgende kan ofte fjernes:

• Mappe- og filstrukturer
• Lister over teknologier og afhængigheder
• Standardkommandoer til build og test
• Kommandoer, der allerede står i projektets manifest
• API-signaturer og typer kopieret direkte fra kildekoden
• Arkitekturbeskrivelser, der gentager en README
• Generelle råd, som modellen allerede følger
• Regler, der håndhæves af en linter eller et pre-commit-hook

Følgende bør normalt blive stående:

• Faldgruber og særlige fejlkontrakter, såsom "X ser sikkert ud, men medfører Y"
• Begrundelser for arkitektur- og designvalg
• Konventioner, der afviger fra sprogets eller værktøjets standard
• Sikkerhedsregler og forbud
• Aftaler om branches og commits
• Domænespecifikke ordlister
• Kommandoer, som ikke kan gættes
• Henvisninger til vigtig kontekst uden for kodebasen

Indhold, der kun er relevant for enkelte typer opgaver, kan flyttes til en skill, som først indlæses, når den skal bruges.

I en af vores egne vejledninger udgjorde ét afsnit om en bestemt kontrakt 58 procent af teksten. Det blev indlæst i alle sessioner, der arbejdede i mappen, også når opgaven ikke havde noget med kontrakten at gøre.

Grænsetilfælde bør blive stående. Et forbud som "gør aldrig X" skal ikke fjernes alene, fordi modellen måske kunne udlede det af koden. Konsekvensen af at bryde reglen kan være grunden til, at den er skrevet ned.

Skills og gemte prompts bør gennemgås på samme måde

De samme problemer findes ofte i skills, slash-kommandoer og prompts, der ligger gemt i kodebasen.

Fire ændringer går igen i de prompts, Anthropic har forkortet.

Vis formatet i stedet for at forklare det

Afsnittet om hukommelse gik fra 12.954 til 2.219 tegn, svarende til en reduktion på 83 procent.

Den gamle udgave forklarede hukommelsestyperne i lange <types>-blokke med eksempler.

Den nye viser filformatet med frontmatter og definerer hver af de fire typer på én linje.

Samme princip kan bruges i en skill. Et filformat, et parameterskema eller en konkret kommando er ofte tydeligere end flere afsnit, der forklarer det samme.

Find regler, der peger i hver sin retning

Gennemgå hver regel, og se efter andre instruktioner, som kan få modellen til at vælge den modsatte adfærd.

Ord som "maksimér", "altid" og "så meget som muligt" bør bruges med forsigtighed. De kan få en bred regel til at veje tungere end en mere præcis undtagelse.

Fjern gentagne kategoriske krav

Bash-beskrivelsen gik fra 35 forekomster af ordene "VIGTIGT", "ALDRIG", "SKAL" og "UNDGÅ" til én.

Mange kategoriske formuleringer i samme afsnit er ofte tegn på, at instruktionen er blevet udvidet lidt ad gangen.

Skriv i stedet den ønskede adfærd én gang. Behold direkte forbud, når et brud har alvorlige konsekvenser.

Henvis til den konkrete kilde

En skill bør især indeholde det, der er særligt for organisationen, domænet eller den valgte arbejdsgang.

Når en testsuite, en mockup eller en eksisterende funktion allerede viser det ønskede resultat, bør prompten henvise til den frem for at gengive indholdet i prosa.

Målet er ikke den kortest mulige prompt. AskUserQuestion blev længere, fordi Anthropic ønskede at præcisere, hvornår værktøjet skulle bruges.

Det afgørende er, om teksten hjælper modellen med at træffe et valg, den ikke selv kan udlede af opgaven eller kodebasen.

Konklusion

Anthropic har reduceret Claude Codes fælles instruktionskerne med 81,0 procent.

Fable 5 og Opus 5 får hver sit tillæg oven på den korte kerne. Fable 5 får især instruktioner om kommunikation og selvstændighed. Opus 5 får instruktioner om opgavens omfang, rettelser og brugen af workflows og underagenter.

I vores test førte den korte prompt til mere brug af de specialiserede værktøjer, selv om reglerne om værktøjsvalg var langt mere udførlige i den gamle prompt.

Bedømmerne foretrak den gamle prompt i de to snævre opslagsopgaver og den korte prompt i de to åbne rådgivningsopgaver. Forsøget var for lille til at sige noget sikkert om den samlede kvalitet.

Målingen af vores egen kodebase viste samtidig, at Claude Codes systemprompt kun udgjorde 7,6 procent af konteksten. Vores egne instruktioner og værktøjsbeskrivelser fyldte langt mere.

Metoden kan gentages for under en dollar: Sæt et lokalt endepunkt op, kør ét kald per model, og mål det indhold, der faktisk bliver sendt.

Vil I have overblik over, hvad jeres agenter får at vide, før de går i gang, så tag fat i os.

Ofte stillede spørgsmål