Anthropic har lagt till två närbesläktade betafunktioner till Claude Messages API: konversationskomprimering på begäran och kontextredigering. Båda är inriktade på ett välbekant problem för utvecklare som bygger assistenter och agenter: användbara konversationer tar ofta längre tid än en modells praktiska kontextbudget, särskilt när verktygsanrop, hämtade dokument och instruktioner för flera varv samlas.
Den viktiga förändringen är att Anthropic inte bara säger åt utvecklare att själva sammanfatta gamla meddelanden. Dess plattformsreleasenoteringar den 14 september beskriver en komprimeringsväg på API-nivå, aktiverad genom betahuvudet compact-2026-09-04, som returnerar ett signerat komprimeringsblock. Det blocket kan ersätta tidigare konversationshistorik i en senare begäran medan de senaste svängarna förblir intakta. Anthropic introducerade också kontextredigering i beta, inledningsvis fokuserad på att automatiskt rensa äldre verktygsresultat och verktygsanrop när en konversation närmar sig token-gränser.
För applikationsteam är detta en användbarhetsfunktion. För gatewayoperatörer, observerbarhetsleverantörer och företag som normaliserar trafik mellan leverantörer är det en protokolländring. Ett komprimerat Claude-samtal är inte längre bara en kortare uppmaning. Den innehåller en leverantörsskapad, signerad representation av tidigare sammanhang som bör bevaras som sådan.
Vad ändrades i Claude Messages API
I en konventionell långvarig chattintegrering har utvecklare vanligtvis tre ofullkomliga alternativ när kontextfönstret fylls upp. De kan släppa gamla svängar, generera sin egen sammanfattning eller be användaren att starta om. Varje val kan skada kontinuiteten, dölja viktiga instruktioner eller göra felsökningen svårare.
Anthropics nya kompakteringsbeta flyttar en del av det arbetet till API:et. API:et kan producera ett signerat komprimeringsblock för tidigare konversationsinnehåll. En senare begäran kan sedan skicka det blocket i stället för de äldre meddelandena, samtidigt som nyare konversation bevaras ordagrant. Designen är viktig eftersom den skiljer komprimerad historia från vanlig assistentförfattad sammanfattningstext. En gateway som plattar ut blocket till en sträng, tar bort okända fält eller behandlar det som ett normalt användarmeddelande kan bryta den avsedda semantiken.
Kontextredigering attackerar en relaterad källa till tokentillväxt: verktygstrafik. Agentapplikationer kan ackumulera stora verktygsutgångar, mellanliggande anrop och inaktuella observationer. Anthropic säger att betaversionen initialt stöder automatisk rensning av äldre verktygsresultat och samtal när konversationen närmar sig tokengränser. Det är vettigt för många arbetsflöden, men det betyder också att ett senare modellsvar kan bero på en konversationstillstånd som medvetet har beskärs av regler på leverantörssidan.
Detta är särskilt relevant för team som bygger ett AI-styrning-lager ovanför flera modellleverantörer. Styrningssystemet behöver inte bara veta vilken prompt som skickades, utan också vilka delar av det tidigare sammanhanget som behölls, komprimerades eller togs bort.
Varför gateways inte kan behandla detta som generisk sammanfattning
Den omedelbara implementeringsrisken är kompatibilitet. Många API-gateways och SDK-omslag validerar nyttolaster för begäran mot kända scheman. Okända parametrar på toppnivå kan tas bort. Okända innehållsblockeringar kan tvingas till text. Loggningspipelines kan redigera eller transformera fält som de inte känner igen. Det är rimliga standardinställningar för vanlig metadata, men de är farliga när det okända objektet är en del av modellleverantörens kontexthanteringskontrakt.
En Claude-medveten gateway bör bevara den nya komprimeringsparametern och signerade block utan att skriva om dem. Den bör också göra en tydlig åtskillnad i spår mellan originalmeddelanden, komprimerad kontext och nyligen omodifierade svängar. Den distinktionen är inte akademisk. När en kund frågar varför en agent fattade ett beslut, bör revisionsspåret visa om modellen hade tillgång till det ursprungliga verktygsresultatet, en komprimerad representation eller ingetdera.
OpenAI-kompatibla gatewayprodukter står inför ett ytterligare designproblem. Chatt- och svars-ekosystemet i OpenAI-stil har sina egna kontexthanteringsmönster, inklusive värd-agenttillstånd och leverantörsspecifik sessionshantering. Anthropics signerade komprimeringsblock är ett annat semantiskt objekt. Ett enda generiskt fält som kallas "sammanfattning" eller "minne" kommer inte att räcka om systemet behöver bevara leverantörsgarantier och uppspelningsbeteende.
Modell Gate-liknande plattformar som stöder både OpenAI-kompatibel routing och antropisk stil API kan därför behöva leverantörsspecifika kontextadaptrar. Det betyder inte att alla kunder ser komplexiteten.Det betyder att gatewayen bör avslöja en stabil extern upplevelse samtidigt som Anthropics komprimeringssemantik behålls internt.
Analytik, fakturering och revisionsspår blir mer komplicerade
Releasenoterna säger inte om signerade komprimeringsblock faktureras annorlunda än vanlig meddelandetext. Den olösta punkten spelar roll. Om ett komprimerat block räknas som vilken annan indata som helst, kan faktureringssystem behandla det som en annan tokenbärande begärankomponent. Om Anthropic tillämpar olika redovisningar måste gateways representera den skillnaden tydligt i kundfakturor och användningsexport.
Även utan specialprissättning ändrar komprimering hur analyser ska förklaras. En konversation kan verka kortare på meddelandenivå samtidigt som den har effekten av ett mycket längre tidigare utbyte. Grundläggande tokengrafer svarar inte på frågor som: hur mycket ursprungligt sammanhang som komprimerades, hur mycket nyligen kontext förblev ordagrant, hur ofta komprimering anropades och om fel korrelerar med automatiskt rensade verktygsutdata.
Det finns också en efterlevnadsvinkel. Om en reglerad kund frågar vilken information som var tillgänglig för en assistent vid en viss tidpunkt, kan en operatör inte svara enbart från den slutliga förfrågan om den inte förstår packningskedjan. Signerade block kan hjälpa till att bevara integriteten, men de tar inte bort behovet av noggranna lagringsregler, kundsynliga spår och interna felsökningsverktyg.
Vem bör agera nu
Utvecklare som använder Claude direkt bör granska om deras SDK, proxy eller loggningsmellanprogram passerar betahuvuden, blockeringsparametern på toppnivån oförändrad komprimering och returnerad komprimering. De bör också testa felbeteende när komprimeringsblock spelas om över distributioner, regioner eller begär transformationer.
Gateway-team bör lägga till schematäckning innan kunder stöter på tyst försämring. Det minsta praktiska arbetet är att sluta släppa eller skriva om de nya fälten. Den bättre versionen är att märka komprimerad kontext separat i loggar, spår och användningsposter. För team som redan tillhandahåller unified AI API-fakturering, bör komprimeringshändelser vara tillräckligt synliga för att supportteamen kan stämma av tokenanvändning och förklara beteenden under långa sessioner.
Företag som driver supportagenter, kodningsassistenter, forskningsverktyg eller säljcopiloter bör hantera denna konsekvens som en reliabilitetsfunktion. Komprimering kan göra långa konversationer mer hållbara, men det introducerar också ytterligare ett dolt lager mellan det synliga chattranskriptet och modellens faktiska inmatningstillstånd.
De öppna frågorna är fortfarande viktiga. Anthropic har inte sagt om packningsblock ändrar fakturerad token-redovisning. Den långsiktiga stabiliteten hos betahuvudet är inte heller garanterad. Och eftersom kontextredigering initialt fokuserar på äldre verktygsanrop och resultat, kommer utvecklare att behöva verifiera hur väl standardinställningarna passar arbetsflöden där gamla verktygsbevis fortfarande är juridiskt eller operativt viktiga.
Den större riktningen är dock tydlig. Långkontexthantering går från applikationslimkod till leverantörs-API:er. Gateways som vill sitta pålitligt mellan kunder och modellleverantörer måste nu stödja den rörelsen på protokollnivå, inte bara genom att vidarebefordra kortare uppmaningar.