## Okno kontekstowe i agent

*Jak model pisze i ile to kosztuje*

*Ostatnia zmiana: 28 września 2026*

Model niczego nie pamięta między requestami, wie tylko to, co dostał w bieżącym. Context window to wspólny limit tokenów wejścia i wyjścia jednego requestu. Agent w każdej turze wysyła całą rosnącą historię, więc płaci za nią wielokrotnie, a jakość odpowiedzi spada wraz z jej długością.

**Po ludzku:** Model to konsultant z amnezją. Przed każdą rozmową dostaje teczkę i wie tylko to, co w niej jest. Teczka ma ograniczoną grubość, a agent przy każdym kroku dokłada do niej kartki.

*Interaktywny widżet na stronie: Przesuń suwak tur agenta. Zobacz, co zapełnia okno i jak szybko rośnie łączny koszt wejścia.*

### Co liczy się do limitu

- Wszystko w requeście: system prompt, definicje narzędzi (także z serwerów MCP), cała historia z wynikami narzędzi, obrazy i PDF-y, a do tego wszystko, co model wygeneruje w tej turze, łącznie z myśleniem. Liczy się w tokenach tokenizera danego modelu, więc ten sam tekst u różnych dostawców daje różne liczby (temat „Tokeny”). Przed wysłaniem policzysz je endpointem do liczenia tokenów.
- Część narzutu jest stała i płacona w każdej turze: definicje kilkudziesięciu narzędzi to łatwo kilkadziesiąt tysięcy tokenów, zanim agent cokolwiek zrobi (temat „Narzędzia (function calling)”).

### Limit wejścia i limit wyjścia

- Okno obejmuje wejście i wyjście razem. Osobno działa limit wyjścia jednego requestu (`max_tokens`), dużo mniejszy: we wrześniu 2026 modele Claude z oknem 1 mln tokenów generują najwyżej 128 tys. na request, a modele GPT-6 w OpenAI mają okno 1,05 mln, z czego najwyżej 922 tys. na wejście, i 128 tys. wyjścia.
- API zwykle odrzuca za długie wejście, zwracając błąd. Ucięcie historii od najstarszych wiadomości to decyzja twojej aplikacji albo frameworka, często podejmowana po cichu.
- Gdy wyjście dojdzie do limitu, generacja staje w pół zdania: `stop_reason: "max_tokens"` w Anthropic (w Claude 4.5+ także `"model_context_window_exceeded"`, gdy wejście z wyjściem zapełnią okno), `finish_reason: "length"` w Chat Completions. JSON jest wtedy niepełny, a model rozumujący może nie dojść do odpowiedzi. Sprawdzaj powód zatrzymania w kodzie.
- Długi kontekst bywa droższy za token: Gemini 3.1 Pro powyżej 200 tys. tokenów wejścia i modele GPT-6 powyżej 272 tys. liczą cały request 2 razy drożej za wejście i cache oraz 1,5 razy drożej za wyjście. Modele Claude z oknem 1 mln mają stałą stawkę (wrzesień 2026).

### Koszt rośnie z każdą turą

- W pętli agenta (temat „Pętla agenta”) tura *t* wysyła wszystko z wcześniejszych tur plus nowy wynik. Przy stałym przyroście na turę łączna liczba tokenów wejściowych rośnie z kwadratem liczby tur. W widżecie 24 tury to już ok. 2,2 mln tokenów wejściowych, choć każdy request mieści się w oknie 200 tys.
- W agentach wejście dominuje: Manus podaje średni stosunek tokenów wejściowych do wyjściowych ok. 100:1. Rachunek obniża więc przede wszystkim prompt caching. Dzięki masce przyczynowej K i V starych tokenów się nie zmieniają, więc dopóki historię się tylko dopisuje, każda tura czyta z cache’u wszystko poza najnowszą częścią (temat „Prompt caching”). Odczyt kosztuje ok. 10% ceny, ale krzywa zostaje kwadratowa.
- Rośnie też opóźnienie. Prefill części spoza cache’u wydłuża czas do pierwszego tokena, a każdy krok decode czyta cały KV cache, więc długi kontekst spowalnia także pisanie (temat „Pętla generowania i KV cache”).
- Gdy narzędzie pracuje, model nic nie liczy, a KV cache rozmowy dalej zajmuje pamięć GPU. Obciążony serwer może zrzucić cache do RAM-u albo na SSD i wczytać go z powrotem, gdy przyjdzie wynik: szybciej, niż liczyłby długą historię od nowa, ale nie bez kosztu dla czasu do pierwszego tokena (Glenn Lockwood, wrzesień 2026). Przez API widać tylko czas życia wpisu w cache’u, a u Anthropic liczy się on od startu requestu: generacja i wolne testy mogą trwać dłużej, niż żyje 5-minutowy wpis, a następna tura zapłaci za zapis i pełny prefill całej historii. Przy narzędziach działających minutami opłaca się wpis godzinny.

### Context rot: jakość spada z długością kontekstu

- Modele działają gorzej na długim wejściu, zanim okno się skończy. Test needle-in-a-haystack, czyli znalezienie jednego zdania pasującego dosłownie do pytania, wychodzi prawie idealnie i niewiele mówi. W RULER (2024) z 17 modeli deklarujących co najmniej 32 tys. tokenów tylko połowa trzymała zadowalający wynik przy 32 tys.
- Spadek jest większy, gdy pytanie i odpowiedź nie mają wspólnych słów: w NoLiMa (2025) 11 z 13 modeli przy 32 tys. tokenów spadło poniżej połowy swojego wyniku z krótkiego kontekstu. Chroma (2025, 18 modeli) pokazała spadek wynikający z samej długości, nawet w prostych zadaniach, silniejszy przy podobnych, ale nieistotnych fragmentach.
- Położenie też ma znaczenie. W badaniu Lost in the Middle (2023) modele najlepiej korzystały z informacji na początku i na końcu kontekstu, a wyraźnie gorzej ze środka. Ważną instrukcję i pytanie stawia się więc na końcu, za długim materiałem.
- Pojemność okna to nie budżet do wypełnienia. Testuj swój przypadek na długościach, które naprawdę wysyłasz, a kontekst utrzymuj krótki i trafny. Jak to robić (przycinanie wyników narzędzi, kompakcja, subagenci, pamięć poza oknem), opisuje temat „Context engineering i pamięć”.

### Sprawdź się

**Pytanie:** Co liczy się do context window i czemu długa sesja agenta jest droga i coraz słabsza?

**Krótka odpowiedź:** Model jest bezstanowy i widzi tylko bieżący request. Okno to limit tokenów na request, wspólny dla system promptu, definicji narzędzi, historii z wynikami narzędzi i tego, co model wygeneruje, łącznie z myśleniem. Limit samego wyjścia jest osobny i dużo mniejszy. Agent w każdej turze wysyła całą historię, więc łączna liczba tokenów wejściowych rośnie z kwadratem liczby tur. Prompt caching obniża cenę, ale nie kształt krzywej. Jakość spada z długością na długo przed końcem okna, więc kontekst warto trzymać krótki i testować na realnych długościach.

### Pytania pogłębiające

- **Co to context rot?** Spadek jakości z długością wejścia, zanim okno się skończy. Jest silniejszy, gdy w kontekście leżą podobne, ale nieistotne fragmenty, i gdy odpowiedź nie powtarza słów z pytania, więc test needle-in-a-haystack go nie pokazuje.
- **Model ma okno 1 mln tokenów. Czemu nie wrzucić całej bazy wiedzy do promptu?** Bo każdy request płaci za cały milion, u części dostawców drożej powyżej progu, czas do pierwszego tokena rośnie, a jakość spada z długością. Przy małym, stałym zbiorze z prompt cachingiem to rozsądne, przy dużym albo zmiennym wygrywa wyszukiwanie (temat „RAG”).
- **Agent przepełnia okno po 40 turach. Co robisz?** Najpierw zmierz, co zajmuje okno, zwykle stare wyniki narzędzi i definicje narzędzi. Potem przytnij wyniki u źródła, wyczyść stare, przenieś poboczne zadania do subagentów, a dopiero na końcu skompaktuj historię (temat „Context engineering i pamięć”).
- **Czy API trzymające historię po stronie serwera obniża koszt?** Nie. Funkcje takie jak previous_response_id w Responses API OpenAI oszczędzają ci przesyłania, ale cała historia i tak trafia do modelu i jest liczona jako wejście. Koszt obniża dopiero prompt caching albo krótszy kontekst.

### Źródła

- [Dokumentacja Claude: context windows](https://platform.claude.com/docs/en/build-with-claude/context-windows)
- [RULER: What’s the Real Context Size of Your Long-Context Language Models? (arXiv)](https://arxiv.org/abs/2404.06654)
- [NoLiMa: Long-Context Evaluation Beyond Literal Matching (arXiv)](https://arxiv.org/abs/2502.05167)
- [Lost in the Middle: How Language Models Use Long Contexts (arXiv)](https://arxiv.org/abs/2307.03172)
- [Glenn Lockwood: What are KV caches really? (wrzesień 2026)](https://blog.glennklockwood.com/2026/09/what-are-kv-caches-really.html)

Strona interaktywna: https://howaiworks.dev/pl/context/