DR
Cennik wejścia z pamięci podręcznej może znacząco obniżyć koszt obciążeń, które ponownie wysyłają duży, niezmieniony prefiks promptu, ale oszczędności zależą od specyficznych dla modelu zasad odczytu, zapisu, przechowywania, routingu i retencji. Ogólna etykieta „caching supported” nie wystarcza do oszacowania kosztu; używaj aktualnej ceny opublikowanej dla dokładnego modelu i trasy.
TL;DR
- GPT-5.6 Terra ma jawnie podane ceny odczytu i zapisu do pamięci podręcznej od OpenAI, CometAPI i OpenRouter, chociaż trasy bramki i poziomy długiego kontekstu mogą zmieniać wysokość stawek.
- Google publikuje stawkę $0.15 na 1M tokenów dla Standard context-caching w Gemini 3.6 Flash oraz opłatę za przechowywanie; CometAPI obecnie podaje standardowe ceny wejścia i wyjścia modelu bez osobnej pozycji dla zbuforowanego wejścia.
- Istotne porównanie to nie tylko standardowe wejście versus odczyt z pamięci podręcznej. Obejmuje także pierwszy zapis do pamięci podręcznej, każdą opłatę za przechowywanie, czas życia pamięci, spójność trasy oraz liczbę późniejszych trafień.
Key messages
- Sprawdzaj ceny na poziomie modelu i poziomu usługi, zamiast stosować mnożnik dla całej bramki.
- Oddziel odczyt z pamięci podręcznej, zapis, przechowywanie i buforowanie odpowiedzi w kalkulacjach kosztów.
- Zweryfikuj rzeczywiste użycie pamięci podręcznej w metadanych odpowiedzi API, zanim zaczniesz prognozować oszczędności na podstawie opublikowanej stawki.
Żądanie, które powtarza duży, niezmieniony prefiks — systemowy prompt, zestaw schematów narzędzi, długi dokument referencyjny — nie musi być rozliczane po pełnej stawce wejścia przy każdym wywołaniu. Większość modeli najnowszej generacji wspiera pewną formę cen dla zbuforowanego wejścia: obniżoną stawkę dla części promptu, którą dostawca rozpoznaje jako już przetworzoną. Mechanizm, rozmiar zniżki i stopień przejrzystości publikacji różnią się w zależności od dostawcy i bramki, i warto być w tym konkretnym, zamiast traktować „caching is supported” jako jedną, jednolitą funkcję.
What cached input pricing is, and isn't
Ceny dla zbuforowanego wejścia obniżają koszt tokenów wejściowych w żądaniu, które odpowiadają wcześniej wysłanemu prefiksowi. Nie obniżają kosztu tokenów wyjściowych i nie są tym samym co deduplikacja przez bramkę dwóch w pełni identycznych żądań i zwrócenie jednej odpowiedzi za darmo — to inny mechanizm, który niektóre bramki oferują osobno. Ceny dla zbuforowanego wejścia dotyczą konkretnie płacenia mniej za część promptu, którą dostawca modelu widział niedawno, a nie pomijania generowania w całości.
Nie jest też darmowe utworzenie tej pamięci. Uwagi cenowe dotyczące GPT-5.6 od OpenAI stwierdzają, że zapisy do pamięci podręcznej są rozliczane po 1.25 razy stawce niebuforowanego wejścia, podczas gdy odczyty z pamięci podręcznej otrzymują 90% zniżki. Ten wyższy koszt pierwszego zapisu wpływa na próg rentowności i łatwo go pominąć, jeśli porównanie pokazuje tylko obniżoną stawkę odczytu. Inni dostawcy mogą stosować opłaty oparte na przechowywaniu zamiast takiego modelu zapisu, więc koszty zapisu i przechowywania należy sprawdzać osobno.
W praktyce rozliczaną jednostką pamięci podręcznej jest zwykle wielokrotnie używalny prefiks promptu, a nie dowolny zbiór powtórzonych zdań. Dostawcy tokenizują i dopasowują treść w kolejności, więc materiał przeznaczony do ponownego użycia musi pojawić się przed specyficznym dla żądania ogonem. Stabilne instrukcje systemowe, definicje narzędzi, polityki i materiały referencyjne powinny znaleźć się na początku; zmieniająca się wiadomość użytkownika, znacznik czasu, identyfikator żądania lub pozyskany fragment — później. Nawet semantycznie niegroźna zmiana na początku może przesunąć tokenizację lub przerwać dopasowanie wszystkiego, co następuje dalej.
Zasady kwalifikowalności są również specyficzne dla modelu. Dostawca może wymagać minimalnej długości promptu, rozpoznawać tylko udokumentowane punkty podziału lub udostępniać jawne pole sterujące pamięcią podręczną. Wpis pamięci podręcznej może wygasnąć między wywołaniami, a bramka może potrzebować utrzymać pokrewne żądania na kompatybilnej trasie do dostawcy. Oznacza to, że wdrożenie powinno traktować trafienie w pamięci jako zaobserwowany wynik, a nie założenie oparte na podobieństwie promptu. Dobrze zbudowany prompt zwiększa prawdopodobieństwo ponownego użycia, ale metadane odpowiedzi i faktura decydują, czy zniżka faktycznie została zastosowana.
What's actually published, by model and by gateway
Poniższa tabela to migawka cen sprawdzona 29 lipca 2026. Ceny są w dolarach amerykańskich na 1 milion tokenów, chyba że podano inną jednostkę. Wiersze porównują aktualne publiczne informacje dla GPT-5.6 Terra i Gemini 3.6 Flash przez dostawcę modelu, CometAPI i OpenRouter; nie należy traktować ich jako stałej taryfy.
| Model | Bramka | Standardowe wejście | Wejście z pamięci podręcznej (odczyt) | Zapis do pamięci podręcznej | Czy zniżka ujawniona? |
|---|---|---|---|---|---|
| GPT-5.6 Terra | Official OpenAI rate | $2.50 / 1M | $0.25 / 1M | $3.13 / 1M | Tak — 90% zniżki, podane wprost |
| GPT-5.6 Terra | CometAPI | $2.00 / 1M | $0.20 / 1M | $2.50 / 1M | Tak — wymienione na stronie cen CometAPI |
| GPT-5.6 Terra | OpenRouter | $2.50 / 1M | Brak wyszczególnionej stawki | Brak | Nie — opisane jedynie jako „60–80% taniej” w ujęciu zbiorczym, bez stawki per model |
| Gemini 3.6 Flash | Official Google rate | $1.50 / 1M | $0.15 / 1M (zgodnie z ogłoszeniem Google) | Nieujawnione | Tak, na starcie — w dokumentacji modelu Google |
| Gemini 3.6 Flash | CometAPI | $1.20 / 1M | Brak wyszczególnionej stawki | Nieujawnione | Nie — strona CometAPI oznacza „Caching” jako wspieraną funkcję, ale nie publikuje obniżonej stawki zbuforowanego wejścia dla tego modelu na chwilę obecną |
| Gemini 3.6 Flash | OpenRouter | $1.50 / 1M | Brak wyszczególnionej stawki | Nieujawnione | Nie — dokumentacja OpenRouter opisuje mnożnik cache Google ogólnie (0.25x stawki wejścia) zamiast potwierdzać konkretną stawkę tego modelu |
Traktuj tabelę jako migawkę cen specyficzną dla modelu i trasy. Strona modelu CometAPI GPT-5.6 wyszczególnia GPT-5.6 Terra: $2.00 standardowe wejście, $0.20 zbuforowane wejście i $2.50 zapis do pamięci podręcznej na 1 milion tokenów. Strona Gemini 3.6 Flash w CometAPI obecnie publikuje $1.20 wejście i $6.00 wyjście, ale nie pokazuje osobnej ceny dla zbuforowanego wejścia ani przechowywania. Cennik Gemini Developer API Google podaje poziom Standard: $1.50 wejście, $0.15 context caching oraz $1.00 na 1 milion tokenów na godzinę za przechowywanie. OpenRouter udostępnia obecnie pola cache specyficzne dla modelu poprzez Models API: domyślna trasa GPT-5.6 Terra obejmuje niższą cenę promocyjną i osobny wyższy poziom długiego kontekstu, podczas gdy wpis dla Gemini 3.6 Flash pokazuje różne wartości dla Standard, Flex i Priority. Jest to bardziej precyzyjne niż stosowanie jednego ogólnego mnożnika cache do każdego modelu.
Why gateway and provider prices can diverge
Cena w bramce niekoniecznie jest narzutem na jedną, niezmienną cenę upstream. Może odzwierciedlać wynegocjowaną przepustowość, tymczasową promocję, inny poziom usługi lub komercyjne uzgodnienia specyficzne dla trasy. Nazwa modelu może też mapować do wielu wariantów upstream, których ceny zmieniają się wraz z długością kontekstu lub gwarancjami opóźnień. Na przykład wpis GPT-5.6 Terra w OpenRouter publikuje domyślną trasę i droższe zastąpienie po przekroczeniu progu długiego kontekstu dla wejścia. Google rozdziela ceny Standard, Batch, Flex i Priority dla Gemini 3.6 Flash. Pojedynczy wiersz porównania zatem potrzebuje daty, trasy, poziomu i założeń o kontekście, aby pozostać sensowny.
Ważny jest też odwrotny przypadek: jeśli strona bramki nie publikuje osobnej pozycji dla odczytu z pamięci podręcznej, tej nieobecności nie należy przekształcać ani w „buforowanie jest niedostępne”, ani w „bezpośrednia zniżka dostawcy automatycznie obowiązuje”. Bramka może przekazywać funkcję upstream bez jej wyszczególniania, udostępniać ją tylko na niektórych trasach lub rozliczać żądanie według normalnej stawki wejścia. Obronne podejście polega na użyciu aktualnej strony modelu w bramce do planowania, a następnie potwierdzeniu rzeczywistej stawki na podstawie zapisów użycia lub danych rozliczeniowych. Dokumentacja dostawcy pozostaje użyteczna do zrozumienia mechanizmu, ale sama nie ustanawia warunków komercyjnych pośrednika.
Where the discount actually matters
Scenariusz, w którym ma to realny wpływ na koszt, to duży, statyczny prefiks sparowany z małym, zmiennym żądaniem — systemowy prompt lub zestaw schematów narzędzi wysyłany przy każdym wywołaniu w pętli agenta, długi dokument referencyjny wielokrotnie odpytywany różnymi pytaniami, albo historia rozmowy odtwarzana przy każdym kroku chatbota. Dla takiego obciążenia różnica między płaceniem pełnej stawki wejścia za cały prefiks za każdym razem a zapłaceniem premii za zapis tylko raz i obniżonej stawki odczytu później kumuluje się wraz z wolumenem wywołań. Nie daje nic dla obciążeń, które nie powtarzają prefiksu — pojedyncze żądanie nie ma żadnej zbuforowanej treści do objęcia zniżką.
Praktyczna kalkulacja progu opłacalności porównuje niebuforowany koszt powtarzanego prefiksu w wszystkich wywołaniach z kosztem zapisu lub przechowywania oraz obniżonymi odczytami z pamięci w późniejszych wywołaniach. Wynik zależy od rozmiaru prefiksu, liczby udanych trafień w pamięci, wygaśnięcia cache i tego, czy bramka utrzymuje żądania na kompatybilnej trasie dostawcy. Jeśli te warunki są niestabilne, zniżka „z nagłówka” może zawyżać oszczędności osiągane w produkcji.
A simple cost model for a repeated prefix
Niech P będzie liczbą tokenów w stabilnym prefiksie, a N liczbą wywołań, które go ponownie używają. Jeśli U to niebuforowana stawka wejścia na token, prefiks kosztuje N × P × U bez buforowania. Uproszczone oszacowanie z buforowaniem to P × W + (N − 1) × P × R + S, gdzie W to cena zapisu do pamięci podręcznej, R to cena odczytu z pamięci, a S to każda opłata za przechowywanie w danym okresie. Formuła zakłada, że pierwsze wywołanie tworzy pamięć, a każde późniejsze jest udanym trafieniem. Pomija zmienny ogon każdego żądania, tokeny wyjściowe, ponowne próby i każdą zmianę trasy powodującą chybienie.
Rozważ ilustracyjny prefiks 100 000 tokenów użyty ponownie w 20 wywołaniach przy oficjalnej stawce GPT-5.6 Terra. Przy $2.50 na 1 milion niebuforowanych tokenów wejściowych, wielokrotne przetwarzanie tego prefiksu kosztowałoby $5.00. Korzystając z opublikowanej stawki zapisu 1.25 razy i 90%-zniżkowej stawki odczytu, jeden zapis 100 000 tokenów kosztowałby około $0.3125, a dziewiętnaście odczytów około $0.475, co daje łączny koszt prefiksu rzędu $0.7875. Różnica wynosi około $4.21 przed zmiennym wejściem i wyjściem. To ilustracja, nie oferta: obowiązuje tylko, jeśli wszystkie dziewiętnaście późniejszych wywołań trafia w tę samą ważną pamięć podręczną i nie mają zastosowania żadne dodatkowe opłaty za przechowywanie lub routing.
Punkt opłacalności wynika bezpośrednio z tego samego modelu. Premia za zapis jest uzasadniona tylko wtedy, gdy nastąpi wystarczająca liczba odczytów z pamięci po zniżce przed wygaśnięciem. W obciążeniach z krótkimi sesjami, częstymi edycjami promptu lub słabą spójnością tras pamięć może być odtwarzana częściej niż oczekiwano. W długotrwałej pętli agenta lub powtarzanej analizie dokumentów ze stabilnym prefiksem liczba trafień może być znacznie wyższa. Prognozy powinny zatem używać zakresu zaobserwowanej częstości trafień, zamiast zakładać idealną sekwencję po pierwszym wywołaniu.
Implementation patterns that improve cache reuse
Konstrukcja promptu ma większy wpływ na współczynnik trafień niż sugeruje wiele arkuszy cenowych. Umieszczaj najbardziej stabilny materiał na początku i utrzymuj jego serializację deterministyczną: instrukcje systemowe, schematy narzędzi, tekst polityk i współdzielony kontekst referencyjny powinny zachować tę samą kolejność, białe znaki i reprezentację pól w powiązanych wywołaniach. Zmienną treść dołączaj później. Unikaj wstrzykiwania znaczników czasu, losowych identyfikatorów, stale zmieniających się liczników lub wyników pobierania specyficznych dla żądania do wielokrotnego używanego prefiksu, chyba że są one rzeczywiście tam potrzebne.
Wersjonuj stabilny materiał celowo. Jeśli zmienia się schemat narzędzia lub polityka, przypisz nową wersję konsekwentnie, zamiast pozwalać krążyć wielu niemal identycznym wariantom. Dla obciążeń konwersacyjnych lub agentskich używaj stabilnego identyfikatora sesji lub klucza pamięci podręcznej, gdy API to wspiera, i unikaj zmiany dostawców w tej samej sekwencji zależnej od cache. OpenRouter dokumentuje routing klejący się do dostawcy w buforowaniu promptu i udostępnia kontrolki takie jak session_id i prompt_cache_key; te kontrolki mogą poprawić ciągłość, ale nie gwarantują trafienia, gdy pamięć upstream jest zimna lub wygasła.
Aplikacje powinny też łagodnie degradować się przy chybieniu. Buforowanie to optymalizacja kosztu i opóźnienia, a nie zależność poprawności. Żądanie musi nadal dawać ten sam poprawny wynik, gdy pamięć jest niedostępna, a logika ponownych prób nie powinna bezrefleksyjnie tworzyć powtarzających się zapisów. Ten rozdział sprawia, że porównywanie tras jest bezpieczniejsze: zespoły mogą zmieniać politykę buforowania lub konfigurację bramki bez zmiany semantycznego zachowania aplikacji.
How to verify cache economics in production
Zacznij od telemetrii per żądanie, a nie od miesięcznej faktury. Loguj dokładny identyfikator modelu, trasę bramki lub dostawcę (gdy ujawnione), poziom usługi, łączną liczbę tokenów wejściowych, tokeny odczytu z pamięci, tokeny zapisu do pamięci, tokeny wyjściowe, opóźnienie i rozliczony koszt. Obiekt użycia OpenRouter zawiera cached_tokens i cache_write_tokens; inni dostawcy ujawniają równoważne szczegóły pod innymi nazwami pól. Zachowuj surowe pola użycia, aby późniejsza zmiana cen nie usunęła danych potrzebnych do rekonstrukcji kosztu.
Agreguj dane według wersji promptu i obciążenia, nie tylko według modelu. Przydatne miary obejmują udział kwalifikujących się żądań, które trafiają w pamięć, udział tokenów wejściowych rozliczanych po stawce odczytu, liczby zapisów na udany odczyt, czas między zapisem a ostatnim trafieniem oraz zrealizowany koszt na żądanie. Wysoki współczynnik trafień na poziomie żądania może nadal dawać niewielką wartość, jeśli zbuforowany prefiks jest mały, podczas gdy niższy współczynnik trafień przy bardzo dużym prefiksie może oszczędzić więcej. Sparuj te miary z percentylami opóźnień, ponieważ tańsza trasa, która wielokrotnie chybia lub zmienia trasę, może być operacyjnie gorsza.
Na koniec, analizuj anomalie zamiast je wygładzać. Nagły spadek liczby zbuforowanych tokenów może wskazywać na wdrożenie nowej wersji promptu, niestabilną serializację, wygasłe wpisy, przekroczenie progu długiego kontekstu lub zmianę trasy bramki. Porównaj dotknięte żądania z bieżącą stroną modelu i dokumentacją dostawcy, a następnie zweryfikuj rozliczoną stawkę. To zmniejsza lukę między opublikowaną zniżką a oszczędnościami rzeczywiście osiąganymi przez aplikację.
What to check before assuming a rate applies
Potwierdź pięć elementów, zanim użyjesz opublikowanej stawki w budżecie: dokładny model i poziom usługi, minimalny wielokrotnie używalny prefiks lub jawne punkty przerwania cache, koszt pierwszego zapisu lub przechowywania, czas życia pamięci oraz dowód, że żądania faktycznie trafiają w cache. OpenAI obecnie podaje minimalny czas życia 30 minut dla GPT-5.6, ale nie jest to uniślubowana zasada retencji. Google publikuje różne stawki dla poziomów Standard, Batch, Flex i Priority. Bramki mogą też routować między dostawcami lub poziomami, więc wybrana trasa ma znaczenie. Dokumentacja prompt-caching OpenRouter zaleca sprawdzanie pól użycia odpowiedzi, takich jak cached_tokens i cache_write_tokens. Dla każdego szacunku produkcyjnego porównaj bieżącą stronę modelu z rzeczywistym rozliczeniem i metadanymi użycia, zamiast polegać wyłącznie na ogólnej etykiecie „caching supported”.