När AI:n glömmer mitt i jobbet: arbeta med kontextkomprimering

Två mekanismer, inte en

Det är lätt att slå ihop dem till "modellen glömmer", men de gör olika saker och lämnar olika spår.

Kontextredigering rensar utvalt innehåll ur historiken. Strategin clear_tool_uses_20250919 tar de äldsta tool-resultaten först och ersätter vart och ett med en platshållare som talar om för modellen att resultatet är borttaget. Standardtröskeln är 100 000 indatatokens, och de tre senaste paren av verktygsanrop och resultat behålls. Den viktiga detaljen står i clear_tool_inputs, som är false som standard: bara resultatet rensas, medan modellens ursprungliga verktygsanrop står kvar synligt. Det finns en motsvarande strategi för tankeblock, clear_thinking_20251015, och två ventiler — exclude_tools för verktyg som aldrig får rensas och clear_at_least för att slippa mikrorensningar.

Komprimering gör tvärtom: den ber modellen sammanfatta historiken och ersätter den med summeringen. Standardtröskeln är 150 000 indatatokens och lägsta tillåtna 50 000. Dokumentationen ställer själv de två mot varandra: till skillnad från kontextredigering, som rensar innehåll, instruerar komprimeringen modellen att sammanfatta konversationen och byter sedan ut hela historiken mot den sammanfattningen.

# Två skilda betaflaggor, två skilda strategityper — blanda inte ihop dem.
betas=["compact-2026-01-12"]
context_management={"edits": [{"type": "compact_20260112",
                               "trigger": {"type": "input_tokens", "value": 150000}}]}

betas=["context-management-2025-06-27"]
context_management={"edits": [{"type": "clear_tool_uses_20250919",
                               "keep": {"type": "tool_uses", "value": 3},
                               "clear_tool_inputs": False}]}

Skillnaden syns också i vilka modeller som omfattas. Kontextredigering anges gälla samtliga modeller som stöds. Komprimering är listad per modell — vid kontrolldatumet Fable 5, Opus 5, Opus 4.8, 4.7 och 4.6 samt Sonnet 5 och Sonnet 4.6. Bygger du mot en äldre eller mindre modell finns alltså rensningen men inte summeringen, och då är det inte samma sak som händer i din session.

Vad summeringen behåller och vad den släpper

I en agentsession körs båda mekanismerna, i en bestämd ordning. Claude Codes dokumentation beskriver den rakt ut: äldre tool-utdata rensas först, och därefter sammanfattas konversationen om det behövs. Samma stycke säger vad som blir kvar: dina förfrågningar och viktiga kodsnuttar bevaras, medan detaljerade instruktioner från tidigt i samtalet kan gå förlorade. Det är den meningen som förklarar varför ett avfärdat förslag kan komma tillbaka: koden överlevde, motiveringen gjorde det inte.

För allt som du själv har konfigurerat finns en publicerad tabell över vad som händer vid en komprimering. Den är värd att läsa som en ägarkarta över din egen setup.

Kriteriet för vad som måste ligga i en fil är alltså inte hur viktigt det känns. Det är om det återinjiceras från disk.

Symtomen och vad de pekar på

Det som gör komprimering svår att upptäcka är att den inte ser ut som ett fel. Sessionen fortsätter, tonen är densamma, och modellen är lika säker som förut. Tre symtom är däremot diagnostiska, för de pekar på olika mekanismer.

Gissa inte vilken av dem det är — kontrollera. Terminalen skriver en rad om att konversationen komprimerats när det sker, och /context ger en löpande uppdelning av vad som ligger i fönstret just nu, inklusive vilka CLAUDE.md- och minnesfiler som är laddade. Det avgörande provet tar tio sekunder: be uttryckligen agenten att använda läsverktyget på filen, svara med första raden och antalet rader, och kontrollera att ett nytt läsanrop faktiskt sker. Om inget anrop syns har du inte verifierat filens aktuella innehåll; starta om provet med ett uttryckligt verktygskrav. Ett uteblivet anrop visar inte ensamt om orsaken är rensning, summering eller att uppgiften redan fanns kvar i kontexten.

Kedjan du själv måste hålla ihop

Kör du mot API:t i egen kod är ansvaret omvänt mellan mekanismerna, och det är där kedjan brukar brista. Kontextredigering sker serverside innan prompten når modellen, och din klient behåller hela den oförändrade historiken — du behöver inte synka något. Komprimering däremot lägger ett compaction-block i svaret, och nästa anrop förutsätter att blocket följer med: API:t släpper allt innehåll som ligger före det och fortsätter från summeringen.

svar = client.beta.messages.create(
    model="claude-opus-5", max_tokens=16000,
    betas=["compact-2026-01-12"],
    context_management={"edits": [{"type": "compact_20260112"}]},
    tools=VERKTYG, messages=meddelanden,
)

# FEL: bara texten. Compaction-blocket faller bort ur historiken och
# nästa anrop skickar in hela den gamla historiken igen — obemärkt.
meddelanden.append({"role": "assistant", "content": text_ur(svar)})

# RÄTT: hela innehållet, block för block.
meddelanden.append({"role": "assistant", "content": svar.content})

# Gör mekaniken mätbar i stället för anekdotisk.
for edit in (svar.context_management.applied_edits if svar.context_management else []):
    logg.info("kontextredigering", typ=edit.type, tokens=edit.cleared_input_tokens)
if any(block.type == "compaction" for block in svar.content):
    logg.info("komprimering", turer=len(meddelanden))

Den övre varianten är den vanligaste buggen i egen agentkod, och den är tyst: allt fungerar, kostnaden stiger, och det enda som avslöjar den är att indatatokens fortsätter växa efter en komprimering i stället för att falla. Loggar du de två raderna längst ned får du dessutom något som är svårt att få på annat sätt — en tidsstämpel att lägga bredvid en misslyckad körning när du felsöker en vecka senare.

Vad som måste flyttas ut ur samtalet

Slutsatsen av tabellen längre upp är obekvämt konkret: allt du bestämmer i chatten är temporärt tills du skriver ned det i en fil som återinjiceras. Två sorters innehåll hör alltid dit.

Det som alltid ska gälla hör hemma i projektrotens kontextfil — körkommandon, konventioner, gränser. Vad som ska stå där och hur kort den ska vara behandlas i Skriv en bra kontextfil, och det som står där upprepas inte här. Den mekaniska tilläggsregeln från den här artikeln är däremot ny: lägg aldrig en regel som måste hålla överallt bakom ett paths:-villkor, och sätt det viktigaste först i en skill-fil, eftersom kapningen behåller början.

Det som är bestämt och varför hör hemma i en beslutslogg i repot. Motiveringen är den kategori som försvinner först i en summering, och därmed den som kostar mest att förlora. Beslutsloggen går igenom varför den behövs och hur en post ser ut; den här artikeln tillför bara orsaken till att den inte kan ersättas av ett långt samtal.

Sedan finns tre inställningar som gör komprimeringen förutsägbar i stället för överraskande. Kör /compact med ett fokus — exempelvis fokusera på autentiseringsfixen — innan du börjar på något nytt, så bestämmer du vad summeringen behåller i stället för att gissa. Sätt fönstret med /autocompact och ett värde mellan 100K och 1M token, eller CLAUDE_CODE_AUTO_COMPACT_WINDOW i skript och CI, så att komprimeringen inträffar när du väljer och inte mitt i en refaktorering; utan eget värde sker den vid modellens kontextgräns. Och flytta stora läsningar till subagenter, som håller filinnehållet utanför ditt fönster.

Provet på att du har landat rätt är enkelt att göra i morgon bitti: starta en ny session och be agenten sammanfatta vad den vet om projektet innan du skrivit något själv. Det den kan då är det som faktiskt ligger i filer. Resten var samtal. Ska prototypen dessutom lämnas över till någon annan är samma frågeställning en del av utvecklarens övertagningsgrind.