Redukcja kosztów tokenów agenta: buforowanie, kierowanie i utrzymanie czystości kontekstu.

Pierwszy agent zazwyczaj rozpoczyna pracę z promptem systemowym składającym się z 500 tokenów oraz dwoma narzędziami, przy czym obie te liczby szybko rosną. Podobno wyciekły prompt systemowy Claude miał długość około 24 000 tokenów. Użytkownicy OpenClaw donoszą, że już przy pierwszej próbie Gemini 3.1 Pro otrzymało ponad 150 000 tokenów wejściowych w zamian za odpowiedź składającą się z 29 tokenów. Jeśli agent nie zostanie optymalizowany, obsługa 100 wiadomości dziennie, przy 166 tys. tokenów wejściowych na każdą, kosztuje około 996 dolarów miesięcznie w przypadku Gemini 3.1 Pro oraz około 2 490 dolarów w przypadku Claude Opus 4.6. Kilka odpowiednich decyzji projektowych może obniżyć ten koszt do poziomu około 50–100 dolarów miesięcznie.

Idee omówione tutaj to buforowanie promptów, buferowanie semantyczne, narzędzia do ładowania opóźnionego oraz serwery MCP, routowanie i łączenie modeli, delegowanie zadań podagentom oraz utrzymywanie czystego kontekstu pracy. Każda z tych metod pozwala zaoszczędzić pieniądze w inny sposób, ale każda wiąże się z określoną ceną w postaci złożoności lub jakości. Żadna z nich nie jest bezpłatna.

Materiał dzieli się na cztery grupy. Pierwsza dotyczy ponownego wykorzystywania tokenów, gdy to możliwe, poprzez buforowanie promptów i semantyczne. Druga polega na redukcji tokenów, które są zawsze obecne, takich jak dane pamięciowe i definicje narzędzi. Trzecia obejmuje przekierowywanie zadań do mniejszych modeli lub przechodzenie na większe, przy jednoczesnym ocenie ryzyka dla jakości w stosunku do oszczędności. Ostatnia grupa dotyczy utrzymywania czystego kontekstu, zarówno ze względu na wydajność, jak i koszty, z krótkim omówieniem metody kompresji.

Przestań płacić dwa razy za te same tokeny

Koszty modeli nie wynikają tylko z zbyt częstego wywoływania modelu. Pochodzą również z konieczności wielokrotnego płacenia za przetwarzanie identycznego tekstu. Pomagają w tym dwa zupełnie różne mechanizmy. Cache K/V stanowi element systemu cache promptów, natomiast cache semantyczny to odrębna koncepcja. W przypadku długich zapytań systemowych cache promptów zapewnia łatwe oszczędności; cache semantyczny wymaga większego wysiłku i niesie ze sobą większe ryzyko.

Jak działa cache K/V

Zanim model cokolwiek wygeneruje, musi przetworzyć zapytanie, a to wymaga obliczeń, co oznacza opóźnienia i koszty. Ma sens nie przetwarzać ponownie tego samego treści wielokrotnie.

Gdy model językowy otrzymuje zapytanie, tekst jest tokenizowany, tokeny przekształcane w wektory, a w każdej warstwie uwagi te wektory są projektowane na tensory K/V.

Kasowanie to przechowywanie tych tensorów, aby nie trzeba było ich ponownie obliczać. Silnik inferencji już przechowuje tensory typu K/V podczas generowania, ponieważ w przeciwnym razie obliczenia nie przebiegałyby z przyjętą prędkością. Kolejnym krokiem jest zachowanie tej pamięci po zakończeniu odpowiedzi i jej nie usuwanie.

Prywatnie kolejnej prośbie system sprawdza, czy początek zapytania odpowiada czemuś, dla czego już posiada tensory. Jeśli tak, ładuje je i pomija procesowanie.

Ekonomiczny efekt jest łatwy do zobaczenia przy zaokrąglonych liczbach. Załóżmy, że przetworzenie 2000 tokenów zajmuje jedną sekundę, a prompt systemu składa się z 10 000 tokenów. Pominięcie ponownego obliczania oszczędza 5 sekund przy każdym wezwaniu, chociaż rzeczywista wydajność prefillu znacznie się różni w zależności od ustawień.

Match z zapisaną pamięcią cache musi być dokładny. Jeśli jakikolwiek token się zmieni, tensory odpowiadające tej części promptu przestają być stosowane i trzeba ją przetworzyć ponownie. Ludzie ciągle na to wpadają: dodatkowy przestrzeń, zmieniona kolejność definicji narzędzia lub data i godzina w niewłaściwym miejscu psują dopasowanie.

Dlatego zapisana pamięć cache przyspiesza żądania, a co za tym idzie, sprawia, że są one tańsze. Ich przechowywanie nie jest jednak bezpłatne. Zapisane dane typu K/V zajmują pamięć po stronie serwera, dlatego wielu dostawców wygasza wpisy po około 5 do 10 minutach.

Nikt nie musi budować tego od zera, ponieważ frameworki i dostawcy API zajmują się tym, każdy według własnych zasad. Zespoły hostujące model otwartego oprogramowania zazwyczaj używają frameworków serwisowych takich jak vLLM, które mają wbudowaną warstwę cache’owania. Użytkownicy API natomiast kierują się zasadami danego dostawcy.

Caching prefiksów w vLLM

Kwarterowanie w vLLM dzieli prompt na bloki, oblicza hash każdego bloku na podstawie jego własnych tokenów oraz tokenów poprzedzających je, a następnie przechowuje tensory K/V pod tymi hashami. Podobnie jak w większości rozwiązań, część statyczna, która ma być zapisywana w pamięci cache, znajduje się na początku promptu.

Istotne są trzy flagi:

• --enable-prefix-caching włącza tę funkcję.
• --block-size określa liczbę tokenów w każdym bloku. Przy rozmiarze bloku 16 silnik kończy przetwarzanie po 16 tokenach i rozpoczyna nowy blok.
• --kv-cache-memory-bytes wyraźnie ustala rozmiar pamięci cache dla K/V na każdym GPU. Więcej pamięci pozwala blokom zapisanym w cache przetrwać dłużej, ale wiele różnych długich zapytań jednocześnie szybciej ją wypełnia, co powoduje wcześniejsze usuwanie starych bloków.

Istnieją inne opcje, w tym SGLang z RadixAttention do przechowywania w pamięci cache prefiksów oraz LMCache, przeznaczony do integracji z silnikami serwowania. Mechanizmy działania są takie same jak opisane powyżej.

Przechowywanie w cache za pośrednictwem dostawców API

Większość zespołów korzysta z dostawców API, a każdy z nich ma określone zasady, których należy przestrzegać, aby zapytania trafiały do cache. Zapytanie musi być odpowiednio skonstruowane. OpenAI jest jasnym przykładem: aby zapisać w cache część zapytania, konieczne jest dokładne dopasowanie prefiksu, co oznacza tę samą statyczną część na początku. Dlatego najpierw wysyłane są stałe instrukcje, przykłady i narzędzia, a treść zmienna później.

Wysłanie prompt-cache-key pozwala grupować podobne żądania i zwiększać wskaźnik trafień do cache. Przechowywanie w cache włącza się automatycznie dla zapytań składających się z 1 024 tokenów lub więcej, ale pierwsze 256 tokenów służy do kierowania żądań z powrotem do tego samego cache, więc statyczna część musi mieć dłuższą długość niż 256 tokenów.

Anthropic działa inaczej: cache musi być włączony za pomocą parametru cache-control. Usunięcie danych z pamięci cache zazwyczaj następuje po 5 do 10 minutach bezczynności u obu dostawców i można to przedłużyć. Anthropic pozwala to przedłużyć do godziny, ale za dwukrotną cenę.

Przy samodzielnym hostowaniu zaoszczędzony czas to również zaoszczędzone pieniądze. U dostawców API korzyść polega na tańszych tokenach wejściowych z pamięci cache. OpenAI obniża cenę tokenów wejściowych z pamięci cache o nawet 90% w stosunku do normalnej ceny. Anthropic oferuje taką samą zniżkę na dane z pamięci cache, ale nalicza również opłatę za utrzymywanie tej pamięci, więc niewłaściwe użycie może ostatecznie kosztować więcej niż brak cache’owania.

Gdy 90% treści promptu jest statyczne, a cache jest używany prawidłowo, koszt znacznie spada, jak pokazuje wykres.

Dla tej porównania stworzono interaktywny kalkulator, dzięki któremu można dostosowywać liczby. Ogólnie rzecz biorąc, szybkie przechowywanie promptów to istotna zaleta dla wszystkich, którzy używają długich, niezmienianych promptów systemowych.

Przechowywanie semantyczne

Przechowywanie semantyczne to zupełnie inna kwestia. Odbywa się ono na podstawie znaczenia: jeśli nowy żądanie jest wystarczająco podobne do poprzedniego, zwracana jest przechowywana odpowiedź. Brzmi to prosto, ale istnieją wyraźne pułapki.

Porównywanie tekstu pod kątem znaczenia wykorzystuje embeddingi, które są wektorami porównywanymi za pomocą podobieństwa kosinowego. Wysokie podobieństwo powinno oznaczać podobne znaczenie, chociaż zależy to od modelu embeddingu.

Propozycja polega na łączeniu podobnych zapytań z już istniejącymi odpowiedziami. Pytanie takie jak „Jaka jest stolica Francji?” oraz pośpieszne „Szybko, podaj mi stolicę Francji” powinny trafić do tej samej przechowywanej odpowiedzi, bez konieczności ponownego wywołania modelu językowego w celu jej utworzenia. To rozwiązanie dobrze funkcjonuje, gdy wiele osób zadaje niemal identyczne, ogólne pytania, a dane w tle powoli stają się przestarzałe.

Dlaczego więc nie stosować tego wszędzie? Ponieważ może się wiele nie udać. Projekt musi rozstrzygnąć kilka kwestii:

• Jaki próg podobieństwa uznaje się za dopasowanie.
• Jak długo odpowiedź pozostaje ważna.
• Jak radzić sobie z rozmowami wieloetapowymi.
• Co faktycznie jest przechowywane.
• Czy powinien istnieć router na wstępie.
• Jak oddzielać użytkowników.
• Co się dzieje, jeśli błędna odpowiedź trafi do pamięci podręcznej.

Czas życia danych wymaga szczególnej uwagi, ponieważ informacje tracą aktualność w różnym tempie w zależności od pytania. Zasady działania są proste, ale do użycia w praktyce potrzebne są filtry metadanych oraz tagi, takie jak użytkownik, przestrzeń robocza, wersja korpusu, persona, zakres sesji, inteligentny TTL oraz reguły określające, czy zwrócone wyniki są wystarczająco dobre. To sprawia, że staje się to niewielkim projektem.

Skuteczny projekt wykorzystuje indeks semantyczny do znajdowania wcześniejszych pytań i pozwala różnym pytaniom odnosić się do tej samej przechowywanej odpowiedzi, co ogranicza wzrost ilości danych przechowywanych. TTL może być dostosowany do sposobu używania: dane często wykorzystywane powinny być przechowywane dłużej, a pozostałe usunięte. Rozsądnie jest również opracować to rozwiązanie po tym, jak logi pokażą powtarzalność zapytań, a nie od samego początku, ponieważ niektóre przypadki użycia po prostu do tego nie nadają się.

Oszczędności mogą być rzeczywiste. Redis twierdzi, że umożliwia aż o 68,8% mniej wywołań API oraz poprawę opóźnienia o 40 do 50%, chociaż ta liczba ma charakter częściowo marketingowy, ponieważ pochodzi z prostego scenariusza pytań i odpowiedzi. Wyniki zależą w pełni od ustawień. Bot do pytań i odpowiedzi z licznymi zbędnymi wywołaniami oszczędza więcej, natomiast agent do programowania, którego wywołania są wszystkie unikalne, oszczędza mniej.

Kasowanie promptów jest przydatne, gdy zmieniające się pytanie znajduje się w dużym, statycznym promptzie, natomiast kasowanie semantyczne sprawdza się wtedy, gdy ludzie ciągle przefrasowują to samo pytanie. 15% wskaźnika dopasowania semantycznego przynosi jedynie niewielkie oszczędności, ale wskaźnik powyżej 45 do 50% zaczyna wydawać się opłacalny.

Oba podejścia różnią się również tym, co może pójść nie tak. Brak danych w pamięci promptów kosztuje jedynie zwykłą cenę, więc taka awaria jest niska kosztowo i łatwa do zauważenia. Brak danych w pamięci semantycznej również nie jest szkodliwy, ale fałszywy hit tak – użytkownik otrzymuje odpowiedź napisaną do innej pytania, w pełni przekonany o jej poprawności, a nic w dziennikach nie zwraca na to uwagi. To właśnie ta asymetria sprawia, że pamięć semantyczna wymaga konserwatywnych progów podobieństwa, określenia zakresu użytkowników oraz sposobu na sprawdzanie hitów, podczas gdy pamięć promptów wymaga przede wszystkim uporządkowanej struktury zapytań.

Należy również wspomnieć o zwykłej pamięci podręcznej. Drogie, deterministyczne operacje, takie jak wyniki zapytań SQL, wyjścia narzędzi oraz rezultaty wyszukiwania, powinny być przechowywane w pamięci podręcznej, aby nie były wykonywane częściej niż to konieczne. Przykładem może być narzędzie, które zbiera dane słów kluczowych do tworzenia streszczeń, przechowuje je w pamięci podręcznej aż staną się przestarzałe i ponownie je uruchamia tylko wtedy, gdy zostanie ponownie wybrana ta ścieżka.

Kasowanie semantyczne to ciekawy koncept, który pozwala oszczędzać tokeny w określonych przypadkach użycia, ale jego prawidłowe wdrożenie wymaga umiejętności inżynierskich.

Nie wczytuj z góry nieruchomych tokenów

Wiadomość systemowa może się powiększać z powodu rozbudowanych definicji narzędzi lub rosącej ilości pamięci. Małe agenty tego nie odczuwają, ale specyfikacje agentów, które stale się powiększają, można uprościć poprzez pobieranie informacji na żądanie lub przynajmniej próbę tego zrobienia.

Zachowuj małą wielkość warstwy zawsze ładowanej

Gdy wiadomość agenta przekracza określoną wielkość, warstwa zawsze ładowana powinna pozostać mała i stabilna, a rosnące szczegóły powinny być przechowywane oddzielnie. Ładowanie kilkuset narzędzi lub wysyłanie pełnych opisów serwera MCP, które ciągle się zmieniają, powoduje chaos.

Problem dotyczy zarówno wydajności, jak i kosztów. Gdy każda warstwa ciągle się zmienia, cacheowanie promptów staje się znacznie trudniejsze do wykorzystania. Górna warstwa powinna być zwięzła i stabilna, wystarczająca, by poinformować model, gdzie się znajduje i dokąd ma iść dalej, bez konieczności przenoszenia całej informacji od razu.

Podobno Claude Code stosuje taki model zarządzania pamięcią. Zawsze ładowany jest plik indeksowy, który nie powinien przekroczyć 200 wierszy, natomiast szczegółowe pliki tematyczne znajdują się w innych miejscach. To, jak agent zachowuje się w praktyce w porównaniu z tym, co zamierza system, to odrębne pytanie. Podobne podejście występuje w zaawansowanej konfiguracji narzędzi Claude’a, w warstwowym projekcie Claude Skills oraz w próbach ładowania narzędzi MCP w trybie opóźnionym, zamiast umieszczania wszystkich definicji serwerów od razu w promptzie.

Czy to działa?

Zasada pozostaje ta sama: gdy kontekst staje się duży, model ma większe trudności z wyborem właściwej akcji. Ten obszar jest jeszcze w początkowej fazie rozwoju, więc jeden konkretny narzędzie pokazuje, jak może on funkcjonować.

Kilka miesięcy temu Anthropic wprowadził zaawansowaną funkcję wyszukiwania narzędzi, której celem jest zmniejszenie objętości kontekstu, nawet gdy model może korzystać z setek narzędzi. Firma donosi, że przed optymalizacją obserwowano od 55K do 134K tokenów definicji narzędzi, a wybór niewłaściwego narzędzia jest częstym błędem, gdy kontekst osiąga taką wielkość.

Narzędzie wyszukiwania optymalizuje kontekst, umożliwiając modelowi szukanie narzędzi zamiast definiowania ich wszystkich z góry. Konfiguracja wygląda w ten sposób:

tools=[
        {
            "type": "tool_search_tool_bm25_20251119",
            "name": "tool_search"
        },
        {
            "name": "search_contacts",
            "description": "Find a contact by name or email.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"}
                },
                "required": ["query"]
            }
        },
        {
            "name": "send_email",
            "description": "Send an email to one or more recipients.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "to": {"type": "string"},
                    "subject": {"type": "string"},
                    "body": {"type": "string"}
                },
                "required": ["to", "subject", "body"]
            },
            "defer_loading": True
        }
    ]

Zdefiniowano jeden narzędzie o nazwie tool_search, wykorzystując gotową opcję – BM25 lub Regex, albo własną. Następnie w celu ilustracji jedno narzędzie zostało oznaczone jako odroczone. Ma to sens tylko przy 10 lub więcej narzędziach. Anthropic przeprowadza wyszukiwanie, więc sposób włączania schematu narzędzia do promptu systemowego oraz same wyszukiwanie pozostają niewidoczne. Gdy narzędzie znajdzie pasujący wynik, jego definicja jest dodawana bezpośrednio do rozmowy jako blok tool_reference.

Pomysł jest ciekawy, ponieważ zapewnia mniejszy kontekst startowy za cenę jednego dodatkowego kroku wyszukiwania. Testy na 4000 narzędziach dały dość słabe wyniki, więc istnieje potrzeba dalszych badań. Narzędzia muszą być również wystarczająco dobrze opisane, aby można je było znaleźć, a debugowanie staje się trudniejsze, gdy krok pośredni jest niewidoczny.

To podejście występuje również w innych miejscach pod prostym nazwaniem dobrego projektowania sztucznej inteligencji. Nie wystawiaj agenta na ogromny, chaotyczny kontekst – daj mu sposób na ograniczenie zakresu działań i pozwól mu sprawdzać lub ładować narzędzia tylko wtedy, gdy jest to konieczne.

Zyski wynikające z tego zależą od liczby tokenów wysyłanych na początku. Drugi kalkulator porównuje wyszukiwanie narzędzi z buforowaniem zapytań.

Powyższy przykład pokazuje szacunkowe oszczędności uzyskiwane dzięki buforowaniu zapytań w połączeniu z narzędziami ładowanymi opóźnionie. Obie metody przynoszą oszczędności, ale ich połączenie nie stanowi dużej zmiany w porównaniu z każdą z nich osobno. Wyszukiwanie narzędzi dotyczy nie tylko kosztów – pomaga również utrzymać czysty kontekst dla lepszej wydajności. Jeśli chodzi wyłącznie o oszczędności, przyjęcie przynajmniej jednej z tych metod daje największy efekt.

Używaj tanich modeli do taniych zadań

W tym rozdziale omawiane jest kierowanie zapytań do różnych modeli oraz wykorzystywanie tańszych podagentów do określonych zadań. Oba podejścia mogą obniżyć koszty tokenów, ale jednocześnie narażać jakość na ryzyko. Wielu uważa, że 60% lub więcej przychodzących pytań jest prostych i nie wymaga najpotężniejszego modelu, a tym bardziej takiego, który potrafi rozumować.

Produkty komercyjne już teraz realizują część tych rozwiązań. Podobno ChatGPT kieruje zapytania na podstawie takich czynników jak typ rozmowy, stopień złożoności, potrzeby dotyczące narzędzi oraz wyraźne intencje, takie jak „myśl dokładnie”, natomiast Claude polega na delegowaniu zadań opartym na opisach oraz wbudowanych podagentach, takich jak Explore. Koncepcja jest prosta do zrozumienia; trudniejsze jest jej zastosowanie bez pogorszenia jakości. Dalej omówione zostaną metody predykcyjnego kierowania zapytań oraz podejścia z weryfikacją wyników, takie jak kaskady i podagenci, a trzeci rozdział przedstawi oszczędności wynikające z tych rozwiązań.

Kierowanie według trudności

Ścieżkowanie na poziomie żądania ocenia trudność i intencję przed wygenerowaniem jakiegokolwiek wyniku. Zalety są duże, ale jedna zła decyzja może zepsuć całą sesję, więc jakość stanowi poważny problem. Jakiś model routera musi zdecydować, dokąd trafi każde żądanie.

Sygnały ścieżkowania używane przez OpenAI nie są publiczne, a użytkownicy często mają wrażenie, że w irytującym momencie zostali przeniesieni do słabszego modelu. Świat oprogramowania otwartego oferuje więcej opcji do przeanalizowania. RouteLLM od LMSYS, zespołu z Berkeley odpowiedzialnego za Chatbot Arena, uczy się na podstawie rzeczywistych danych dotyczących preferencji zebranych w Arenie. łączy standardowe embeddingi z małym modułem routera, co powinno utrzymać niskie koszty hostingu, a jego twórcy donoszą o znacznym obniżeniu kosztów przy zachowaniu większości osiągów GPT-4. Twierdzenie to nie zostało tutaj niezależnie sprawdzone.

W artykule LLMRouterBench znajduje się ostrzegawczy komentarz: wiele uczonech routerów ledwo przewyższa proste metody bazowe, takie jak routowanie oparte na słowach kluczowych lub heurystykach, czy też routowanie w stylu najbliższego sąsiada i kNN.

Routerzy zaawansowane mogą nie przynosić większych korzyści w porównaniu z prostymi rozwiązaniami. Ludzie nadal eksperymentują, choć routowanie nie zostało porzucone, ale oszczędności nie są gwarantowane, gdy jakość odpowiedzi nie nadąża za oczekiwaniami. Istnieją również opcje hostowane, takie jak OpenRouter Auto i Switchpoint, choć żaden publiczny materiał nie opisuje ich wewnętrznego mechanizmu routowania ani dokładności. Kalkulator porównuje LLMRouter, heurystyki, samodzielnie hostowany klasyfikator, LLM-as-router, RouteLLM oraz OpenRouter Auto. Aby ocenić jakość w rzeczywistych warunkach, konieczne są odpowiednie testy z jasno określonymi wynikami, czego ten obszar na pewno wymaga.

Zacznij tanio, przejdź na bardziej zaawansowane rozwiązania przy niskiej pewności

Unikając prób przewidywania trudności zapytania na podstawie jego treści, tani model może najpierw udzielić odpowiedzi, a dopiero później mechanizm weryfikacyjny zdecyduje, czy ją zachować, czy przenieść sprawę do modelu zaawansowanego. Artykuł Google’a „Speculative Cascades” opisuje ten kompromis: małe modele są używane najpierw ze względu na koszt i szybkość, a większe – tylko w razie potrzeby.

Tani model generuje odpowiedź, a następnie lżejszy mechanizm weryfikacyjny analizuje takie wskaźniki jak logprobs, entropia lub niepewność typu margin, a także stopień spójności semantycznej.

To podejście jest atrakcyjne, ponieważ trudność zapytania jest trudna do przewidzenia, a większość mechanizmów routingu nie jest doskonała; natomiast jakość odpowiedzi łatwiej ocenić, gdy już istnieje. Ma sens tylko wtedy, gdy większość pytań może zostać rozwiązana przez prostszy model, ponieważ przypadki przekazywane do modelu zaawansowanego wiążą się z dwoma wywołaniami. Zespoły je używające twierdzą, że opóźnienie w walidacji pomiędzy wywołaniami może wynosić mniej niż 20 ms.

Implementacja o otwartym kodzie źródłowym o nazwie CascadeFlow obiecuje 69% oszczędności przy jednoczesnym zachowaniu 96% jakości w porównaniu z GPT-5. Pytania, na których była testowana, miały sprawdzalne rozwiązania, takie jak odpowiedzi matematyczne czy pytania wielokrotnego wyboru. Głównym problemem jest to, że małe modele często błędzą w sposób pewny, więc rozsądne może być zastosowanie konserwatywnych progów i częstszego ich podwyższania, co zwiększa koszty. Dodanie taniego mechanizmu kaskadowego do kalkulatora sugeruje oszczędności na poziomie około 50%, pod warunkiem że dla niektórych zapytań w ogóle potrzebne są większe modele.

Delegowanie zadań podagentom

Podagenci delegują prace izolowanym agentom, które czasami używają mniejszych modeli, więc jest to również forma routingu. Oszczędności w tym przypadku są mniejsze. Zaletą jest również utrzymanie czystego kontekstu, dzięki czemu każdy agent może w pełni skupić się na swoim zadaniu.

Claude Code posiada wbudowane subagenty. Subagent Explore jest wyraźnie pracownikiem typu Haiku przeznaczonym do przeglądania i wyszukiwania w bazie kodu, co realizuje koncepcję stosowania tańszych modeli do prostszych zadań. Główna sesja również deleguje zadania poprzez dopasowywanie opisów w sposób niewidoczny dla użytkownika, który widzi jedynie niższą łączną kwotę rachunku. Ponieważ orkiestrator zazwyczaj uczestniczy w planowaniu, syntezie i próbach ponownych, oszczędności są mniejsze niż te uzyskiwane dzięki routingu.

Zgodnie z danymi kalkulatora, subagenty przyniosą oszczędności na poziomie około 11% w porównaniu z opcją bez routingu, więc same w sobie nie stanowią głównego narzędzia do obniżania kosztów.

Zachowaj czystość kontekstu

Dobre projektowanie kontekstu to przede wszystkim kwestia wydajności, ale może również wpływać na koszty. Z biegiem czasu agenci gromadzą zbędne dane: przestarzałe próby, stare plany, duplikowane stany, logi, powtarzające się obserwacje oraz surowe wyniki narzędzi. Osoby tworzące agenty po raz pierwszy są szczególnie narażone na to, ponieważ ciągle wprowadzają wyniki do głównego stanu roboczego agenta.

Dzieje się to wszędzie. Użytkownicy OpenClaw skarżą się na gromadzenie się kontekstu, podobnie jak użytkownicy Claude Code, ponieważ dodawanie danych jest łatwiejsze niż ich usuwanie.

Trudna część to pipeline stanów

To problem dwuetapowy. Nie chodzi tu tylko o kompresję rozmowy – nowe dane muszą również pozostać czyste po wejściu do stanu roboczego, a to wymaga skomplikowanego projektowania. Zły wzorzec wygląda tak, gdy agent ciągle wprowadza surowe wyniki do kontekstu:

bad state:
agent does work
→ dumps tool output into context
→ reads files
→ dumps files into context
→ runs tests
→ dumps logs into context
→ retries
→ keeps everything

Prawdziwym zadaniem jest zachowanie właściwego stanu podczas usuwania niepotrzebnego materiału po drodze. Surowy wynik może trafić do archiwum, a w aktywnym kontekście powinno znajdować się tylko to, co jest konieczne. Wrogiem jest zazwyczaj nadmierna objętość wyjściowa narzędzi, dlatego zmniejszenie ich hałasu jako standardu stanowi część tej pracy. Zdrowszy aktywny kontekst wygląda w ten sposób:

Good active context

[system rules]
[project rules]
[user task]
[current working state]

Keep:
+ auth flow lives in auth.ts + session.ts
+ bug only happens on refresh path
+ failing test: session_refresh_keeps_user
+ likely overwrite during refresh
+ files in scope: auth.ts, session.ts, auth.test.ts

Drop:
- raw grep results
- full test logs
- duplicate file dumps
- dead-end retries

Pewne elementy kontekstu mogą również mieć określony cykl życia lub datę wygaśnięcia. Gdy kompresja staje się konieczna, łatwiej jest określić, czego faktycznie potrzebuje model LLM.

Notatki Anthropic na temat zadań długoterminowych wskazują, że kompresja powinna zachować decyzje architektoniczne, nierozwiązane błędy oraz szczegóły implementacji. Autonomiczna kompresja LangChain pozwala agentowi decydować, kiedy przeprowadzić kompresję, i nie czeka, aż kontekst już się rozrośnie – co wydaje się być podejściem Anthropic. Zespoły zaczynają traktować kompresję jako problem systemowy, wykorzystując odpowiednie wskaźniki i polityki specyficzne dla agentów, a nie już jako zwykły trik sumaryzacji.

Niedawny artykuł autorstwa Jia i innych pokazuje, że przy 6-krotnym skurczeniu rozmiaru danych udało się osiągnąć redukcję budżetu tokenów o 51,8 do 71,3%, a także poprawę efektywności rozwiązywania problemów o 5,0 do 9,2% w testach SWE-bench Verified. Zatem chodzi tu nie tylko o koszty – kompresja poprawia ogólnie wydajność.

Usunięcie niepotrzebnego tekstu może skutecznie oczyścić od 30 do 70% kontekstu, co przynosi podobne oszczędności w pieniądzach. W przypadku okna kontekstowego o wielkości 10 tysięcy tokenów, oczyszczenie go o 30 do 50% podczas 100 tysięcy wywołań może zaoszczędzić nawet 1 500 dolarów, a przy 40 tysiącach ten wynik wzrasta do 6 000 dolarów. Agenty kompresujące, które już wykorzystują bardzo małe, tanie modele, mogą kosztować więcej, niż przyniosą oszczędności. Mimo to czysty kontekst nie pogarsza jakości w taki sposób jak cacheowanie semantyczne czy routowanie, więc przy prawidłowym zastosowaniu stanowi wyraźną korzyść. Problemem jest natomiast wysiłek potrzebny do jego realizacji.

Wybór spośród nich

Istnieją cztery sposoby na obniżenie kosztów tokenów, a odpowiednia kombinacja zależy od przypadku użycia:

• Wykorzystaj cacheowanie promptów z dużymi promptami systemowymi, które pozostają niezmienione podczas wielokrotnych wywołań LLM.
• Zastosuj cacheowanie semantyczne dla ogólnego bota Q&A, który musi pozostać tani.
• Przetestuj routowanie, gdy agent musi radzić sobie zarówno z łatwymi, jak i trudnymi pytaniami.

Zachowaj kontekst tak czysty, jak to możliwe, aby uniknąć wysyłania niepotrzebnych tokenów.