Az Anthropic két, egymással szorosan összefüggő bétafunkcióval bővítette a Claude Messages API-t: az igény szerinti beszélgetések tömörítését és a kontextusszerkesztést. Mindkettő a fejlesztők számára ismerős problémát céloz meg az asszisztensek és ügynökök kiépítésében: a hasznos beszélgetések gyakran tovább tartanak, mint a modell gyakorlati kontextusának költségvetése, különösen akkor, ha az eszközhívások, a letöltött dokumentumok és a többszörös fordulatú utasítások összegyűlnek.
A fontos változás az, hogy az Anthropic nemcsak azt mondja a fejlesztőknek, hogy maguk foglalják össze a régi üzeneteket. A szeptember 14-i platform kiadási megjegyzései API-szintű tömörítési útvonalat írnak le, amely a compact-2026-09-04 bétafejlécen keresztül engedélyezett, és amely aláírt tömörítési blokkot ad vissza. Ez a blokk helyettesítheti a korábbi beszélgetési előzményeket egy későbbi kérésben, miközben a legutóbbi fordulatok érintetlenek maradnak. Az Anthropic a kontextusszerkesztést is bevezette a béta verzióban, amely kezdetben a régebbi eszközök eredményeinek és eszközhívásainak automatikus törlésére összpontosított, amint a beszélgetés közeledik a token korlátokhoz.
Az alkalmazáscsapatok számára ez egy használhatósági funkció. Az átjáró-üzemeltetők, a megfigyelhetőséget biztosító szállítók és a szolgáltatók közötti forgalmat normalizáló vállalatok számára ez protokollmódosítás. A tömörített Claude-beszélgetés már nem csak egy rövidebb felszólítás. Tartalmazza a szolgáltató által létrehozott, aláírt korábbi kontextus reprezentációját, amelyet meg kell őrizni.
Mi változott a Claude Messages API-ban
A hagyományos, hosszú távú csevegési integrációban a fejlesztőknek általában három tökéletlen lehetőségük van, amikor megtelik a kontextusablak. Eldobhatják a régi fordulókat, elkészíthetik saját összefoglalójukat, vagy újraindításra kérhetik a felhasználót. Mindegyik választás sértheti a folytonosságot, elrejtheti a fontos utasításokat, vagy megnehezítheti a hibakeresést.
Az Anthropic új tömörítési bétaverziója áthelyezi e munka egy részét az API-ba. Az API aláírt tömörítési blokkot tud előállítani a korábbi beszélgetési tartalmakhoz. Egy későbbi kérés ezután elküldheti ezt a blokkot a régebbi üzenetek helyére, miközben az újabb beszélgetések megőrzése szó szerint változik. A dizájn azért fontos, mert megkülönbözteti a tömörített történelmet a szokásos asszisztens által készített összefoglaló szövegtől. Egy átjáró, amely a blokkot sztringgé simítja, ismeretlen mezőket eltávolít, vagy normál felhasználói üzenetként kezeli, megtörheti a szándékolt szemantikát.
A kontextus szerkesztése a token növekedésének kapcsolódó forrását támadja: az eszközforgalmat. Az ügynöki alkalmazások nagy szerszámkimeneteket, közbenső hívásokat és elavult megfigyeléseket halmozhatnak fel. Az Anthropic szerint a béta kezdetben támogatja a régebbi eszközeredmények automatikus törlését, és a beszélgetések token határához közeledő hívásokat. Ez sok munkafolyamat esetében logikus, de azt is jelenti, hogy egy későbbi modellre adott válasz függhet a beszélgetés állapotától, amelyet a szolgáltatóoldali szabályok szándékosan csökkentettek.
Ez különösen fontos azoknál a csapatoknál, amelyek több modellszolgáltató felett egy AI irányítási réteget építenek fel. Az irányítási rendszernek nemcsak azt kell tudnia, hogy milyen promptot küldtek, hanem azt is, hogy a korábbi kontextus mely részeit őrizték meg, tömörítették vagy távolították el.
Miért nem kezelhetik az átjárók ezt általános összegzésként?
Az azonnali megvalósítási kockázat a kompatibilitás. Sok API-átjáró és SDK-burkoló érvényesíti a kérések hasznos terheit az ismert sémák alapján. Az ismeretlen legfelső szintű paraméterek elvehetők. Ismeretlen tartalomblokkokat kényszeríthetnek a szövegbe. A naplózó folyamatok szerkeszthetik vagy átalakíthatják azokat a mezőket, amelyeket nem ismernek fel. Ezek ésszerű alapértelmezések a közönséges metaadatokhoz, de veszélyesek, ha az ismeretlen objektum a modellszolgáltató környezetkezelési szerződésének része.
A Claude-tudatos átjárónak meg kell őriznie az új tömörítési paramétert és az aláírt blokkokat anélkül, hogy átírná azokat. A nyomokban is világos különbséget kell tennie az eredeti üzenetek, a tömörített kontextus és a legutóbbi, nem módosított fordulatok között. Ez a megkülönböztetés nem akadémikus. Amikor az ügyfél megkérdezi, miért döntött az ügynök, az ellenőrzési nyomvonalnak meg kell mutatnia, hogy a modell hozzáfért-e az eredeti eszközeredményhez, egy tömörített reprezentációhoz, vagy egyikhez sem.
Az OpenAI-kompatibilis átjárótermékek további tervezési problémával szembesülnek. Az OpenAI-stílusú csevegési és válaszok ökoszisztémája saját környezetkezelési mintákkal rendelkezik, beleértve a hosztolt ügynök állapotát és a szolgáltató-specifikus munkamenet-kezelést. Az Anthropic előjeles tömörítési blokkja egy másik szemantikai objektum. Egyetlen általános, „összefoglaló” vagy „memória” nevű mező nem lesz elegendő, ha a rendszernek meg kell őriznie a szolgáltatói garanciákat és az újrajátszási viselkedést.
Az OpenAI-kompatibilis útválasztást és az antropikus stílusú API-kat egyaránt támogató modellkapu-stílusú platformokhoz ezért szolgáltató-specifikus környezetadapterekre lehet szükség. Ez nem jelenti azt, hogy minden ügyfél látja a bonyolultságot.Ez azt jelenti, hogy az átjárónak stabil külső élményt kell kitennie, miközben az Anthropic tömörítési szemantikáját belsőleg érintetlenül hagyja.
Az elemzések, a számlázás és az ellenőrzési nyomvonalak egyre bonyolultabbak
A kiadási megjegyzések nem mondják, hogy az aláírt tömörítési blokkok számlázása eltér-e a normál üzenetszövegtől. Ez a megoldatlan pont számít. Ha egy tömörített blokkot úgy számítanak, mint bármely más bemenetet, a számlázási rendszerek egy másik token-hordozó kéréskomponensként kezelhetik. Ha az Anthropic eltérő elszámolást alkalmaz, az átjáróknak egyértelműen tükrözniük kell ezt a különbséget az ügyfelek számláiban és a felhasználási exportban.
Még speciális árképzés nélkül is, a tömörítés megváltoztatja az elemzés magyarázatát. Egy beszélgetés rövidebbnek tűnhet az üzenet szintjén, miközben továbbra is magában hordozza egy sokkal hosszabb előzetes üzenetváltás hatását. Az alapvető jogkivonat-grafikonok nem adnak választ az olyan kérdésekre, mint például: mennyi eredeti kontextus tömörült, mennyi a legutóbbi kontextus szó szerint, milyen gyakran fordult elő tömörítés, és hogy a hibák korrelálnak-e az automatikusan törölt eszközkimenetekkel.
Van egy megfelelőségi szög is. Ha egy szabályozott ügyfél megkérdezi, hogy egy adott időpontban milyen információk álltak az asszisztens rendelkezésére, az üzemeltető nem válaszolhat kizárólag a végső megkereső szervtől, hacsak nem érti a tömörítési láncot. Az aláírt blokkok segíthetnek megőrizni az integritást, de nem szüntetik meg a gondos megőrzési szabályok, az ügyfelek által látható nyomkövetések és a belső hibakereső eszközök szükségességét.
Ki tegyen most?
A Claude-ot közvetlenül használó fejlesztőknek meg kell vizsgálniuk, hogy SDK-juk, proxyjuk vagy naplózási köztes szoftverük átadja-e a béta fejlécet, a legfelső szintű tömörítési blokk módosítatlan paraméterét és a visszaadott tömörítési paramétert. Tesztelniük kell a hibaviselkedést is, amikor a tömörítési blokkok újrajátszásra kerülnek telepítések, régiók között vagy átalakításokat kérnek.
Az átjárócsapatoknak hozzá kell adniuk a séma lefedettségét, mielőtt az ügyfelek csendes leromlással szembesülnének. A minimális gyakorlati munka az új mezők kihagyásának vagy átírásának abbahagyása. A jobb verzió a tömörített kontextus külön címkézése a naplókban, a nyomkövetésekben és a használati rekordokban. Azoknál a csapatoknál, amelyek már biztosítanak egységes AI API számlázást, a tömörítési eseményeknek elég jól láthatónak kell lenniük ahhoz, hogy a támogató csapatok össze tudják egyeztetni a tokenhasználatot, és elmagyarázzák a hosszú munkamenetek viselkedését.
A támogatási ügynököket, kódolási asszisztenseket, kutatási eszközöket vagy értékesítési eszközöket irányítási másodlagosként kezelő vállalkozásoknak kell kezelniük. A tömörítés tartósabbá teheti a hosszú beszélgetéseket, de egy másik rejtett réteget is bevezet a látható csevegési átirat és a modell tényleges beviteli állapota közé.
A nyitott kérdések továbbra is lényegesek. Az Anthropic nem közölte, hogy a tömörítési blokkok megváltoztatják-e a számlázott token elszámolását. A béta fejléc hosszú távú stabilitása sem garantált. És mivel a kontextusszerkesztés kezdetben a régebbi eszközhívásokra és eredményekre összpontosít, a fejlesztőknek ellenőrizniük kell, hogy az alapértelmezett értékek mennyire illeszkednek azokhoz a munkafolyamatokhoz, ahol a régi eszközök bizonyítékai jogilag vagy működési szempontból fontosak maradnak.
A nagyobb irány azonban egyértelmű. A hosszú kontextusú menedzsment az alkalmazásragasztó kódról a szolgáltatói API-kba költözik. Azoknak az átjáróknak, amelyek megbízhatóan szeretnének elhelyezkedni az ügyfelek és a modellszolgáltatók között, most már protokollszinten is támogatniuk kell ezt a mozgást, nem csak rövidebb felszólítások továbbításával.