Токени, контекст і вартість

Зміст

Кожен запит до LLM — це рахунок за токени й гонка з лімітом контексту. Модель не бачить ваш текст як букви чи слова: вона ріже його на токени, і саме за токени ви платите, саме в токенах вимірюється, скільки модель здатна «тримати в голові» за один раз. Для QA це не бухгалтерія, а щоденні рішення: чому генератор автотестів «забув» половину специфікації, чому один і той самий промпт українською дорожчий за англійський, чому агент після сотні кроків починає гальмувати й помилятися.

Зрозумієш механіку токенів і контексту — і навчишся свідомо керувати якістю, швидкістю та вартістю роботи з AI, а не покладатися на «якось воно порахується». Ця глава — місток між «Як працюють LLM» і практичним промптингом: без неї промпти пишуться наосліп.

Токен: одиниця, якою мислить модель

Токен (token) — це шматок тексту, яким оперує модель: частіше за все це не ціле слово й не окрема буква, а підслівний фрагмент (subword). Токенізатор (tokenizer) — алгоритм, що ріже текст на такі шматки; більшість сучасних моделей використовують різновид BPE (byte-pair encoding), який збирає найчастіші послідовності символів в окремі токени.

Груба, але робоча оцінка для англійського тексту: приблизно 4 символи на токен, або близько ¾ слова на токен (100 токенів ≈ 75 слів). Тобто коротке речення — це кілька десятків токенів.

Ключова пастка для нас: українська коштує дорожче. Токенізатори тренують переважно на англомовних даних, тож кирилиця ріжеться на дрібніші шматки — слово нерідко розпадається на кілька токенів. Той самий зміст українською може займати у 2–3 рази більше токенів, ніж англійською. Практичний наслідок: якщо женете великі обсяги (наприклад, генеруєте тест-кейси з україномовної специфікації), і токен-ліміт, і рахунок будуть відчутно більші, ніж підказує «на око».

Код і структуровані дані токенізуються ще менш очевидно: відступи, дужки, лапки, довгі ідентифікатори — усе це окремі токени. Мінімізований JSON або лог на кілька екранів легко зʼїдає тисячі токенів.

І останнє: різні моделі — різні токенізатори. Той самий рядок дасть різну кількість токенів у різних провайдерів і навіть у різних поколінь однієї моделі. Тому не можна оцінювати токени для однієї моделі лічильником від іншої (класична помилка — рахувати токени умовного Claude бібліотекою, написаною під GPT). Для точного числа є ендпоінти підрахунку токенів і офіційні токенізатори провайдера.

Контекстне вікно: скільки модель бачить за раз

Контекстне вікно (context window) — це максимальна кількість токенів, яку модель здатна обробити за один запит. У нього має вміститися все: системний промпт, уся історія діалогу, вкладені документи чи логи, поточне питання — і ще лишитися місце під відповідь, бо згенеровані токени теж рахуються у вікно.

Розміри дуже різні: від кількох тисяч токенів у старих чи маленьких моделей до 200 000 і навіть 1 000 000 у сучасних. Зазвичай є ще окремий ліміт на довжину відповіді (max output) — навіть із мільйонним вікном модель не видасть вам мільйон токенів тексту за раз.

Що критично зрозуміти QA: API моделі не має памʼяті між запитами — він stateless. «Чат» лише створює ілюзію памʼяті: клієнт щоразу надсилає всю історію повідомлень заново. Тому з кожним ходом діалогу вхід росте й рано чи пізно впирається у вікно. Коли контекст переповнюється, варіанти невеселі: помилка запиту, обрізання старих повідомлень або примусове стиснення історії — і модель справді «забуває» те, що ви їй казали двадцять реплік тому.

Чому довгий контекст ≠ кращі відповіді

Велике вікно спокушає: «закинемо туди все — і специфікацію, і код, і логи». Але місткість вікна й здатність моделі якісно цим користуватися — різні речі.

Добре задокументований ефект — «загублене посередині» (lost in the middle): моделі надійніше знаходять інформацію на початку та в кінці контексту, ніж усередині. Помістіть потрібний факт у середину довгого документа — і шанс, що модель його «не помітить», зростає. Є й ширше явище деградації: що більше зайвого в контексті, то дужче розпорошується увага, і на дуже довгих входах якість, стабільність і точність можуть просідати.

Для QA висновок прямий: не вивалюйте на модель усе підряд. Довгий контекст — це і дорожче, і повільніше, і не обовʼязково точніше. Краще подати релевантний зріз: потрібний фрагмент логу, а не весь файл; конкретний розділ вимог, а не весь Confluence. Це той самий принцип, що й у ручному тестуванні, — сфокусована перевірка бʼє «протестуй усе».

Скільки це коштує: input проти output

Оплата — за токени, зазвичай за мільйон (позначають MTok або /1M). Два тарифи рахуються окремо:

вхідні (input) токени — усе, що ви надіслали: промпт, історія, документи;
вихідні (output) токени — усе, що модель згенерувала.

Головне правило: вихідні токени коштують у кілька разів дорожче за вхідні — типово в 5–6 разів. Наприклад, для моделей рівня Opus станом на липень 2026 вхід — порядку кількох доларів за мільйон токенів, а вихід — кількох десятків (співвідношення 1:5); точні цифри залежать від моделі й регулярно змінюються, тож звіряйтеся з прайсом провайдера. Врахуйте й те, що токени «міркування» (reasoning), якщо модель їх генерує, теж ідуть у вихідні.

Звідси неочевидний наслідок — діалог дорожчає нелінійно. Оскільки історію щоразу пересилають повністю, десятий хід оплачує всі попередні девʼять як вхід:

// Кожен наступний виклик пересилає всю історію — вхід росте з кожним ходом
const messages = [{ role: "system", content: SPEC }]; // великий стабільний префікс
messages.push({ role: "user", content: "Згенеруй тест-кейси для логіну" });
messages.push({ role: "assistant", content: reply1 }); // відповідь теж лягає в історію
messages.push({ role: "user", content: "А тепер негативні сценарії" });
// другий запит оплачує SPEC + перше питання + першу відповідь ЗНОВУ

Довга агентна сесія з десятками кроків і великими логами в контексті може коштувати помітно більше, ніж здається з одного «дешевого» запиту.

Prompt caching: платити один раз за спільний префікс

Якщо багато запитів починаються з того самого великого шматка (системний промпт, велика специфікація, приклади), цей початок можна кешувати. Prompt caching (кешування промпта) зберігає вже оброблений префікс, і наступні запити з тим самим початком читають його з кешу — набагато дешевше й швидше, ніж рахувати заново.

Порядок цін у Anthropic станом на липень 2026: читання з кешу коштує близько 10% від звичайної ціни вхідного токена, а перший запис у кеш — трохи дорожче за звичайний вхід (1.25x за стандартного TTL). В інших провайдерів механіка й множники свої, тож звіряйтеся з документацією. Тобто вже з другого-третього повторення кеш окупається.

Критичний нюанс — це збіг за префіксом (prefix match): кеш працює, лише поки початок запиту побайтово однаковий. Одна змінена дужка, вставлена дата чи переставлений ключ у JSON на початку — і весь кеш після цієї точки анулюється. Тому стабільне (незмінний системний промпт, документ) кладуть на початок, а мінливе (поточне питання, timestamp) — у кінець. У кеша ще є час життя (TTL; у Anthropic за замовчуванням 5 хвилин), після якого префікс треба «прогріти» заново.

Це концептуально та сама ідея, що й HTTP-кеш (див. Кешування): зберегти вже пораховане, щоб не рахувати вдруге, з тим самим питанням валідності. Для QA це прямий важіль: якщо ви ганяєте сотню промптів проти однієї великої специфікації (генерація кейсів, ревʼю), кешування спеки економить і час прогону, і бюджет.

Як економити контекст і гроші

Кілька практичних прийомів, що випливають з усього вище:

Подавайте зріз, а не все. Релевантний фрагмент логу чи вимог замість цілого файлу — дешевше і точніше.
Тримайте стабільне на початку, мінливе — в кінці, щоб працювало кешування.
Стискайте історію. У довгих діалогах підсумовуйте попереднє замість того, щоб тягнути кожну репліку дослівно; починайте нову сесію, коли тема змінилася.
Використовуйте вибірку замість «запхати весь корпус». Підхід, коли в контекст підтягують лише потрібні шматки з бази знань (RAG), — окрема велика тема, але принцип той самий: менше нерелевантного в контексті.
Рахуйте перед відправкою. Для важливих чи масових прогонів прикидайте токени лічильником потрібної моделі, а не «на око».

Вибір моделі під задачу

Немає «найкращої» моделі — є доречна. Провайдери зазвичай мають лінійку: від маленьких швидких і дешевих (клас Haiku) до великих потужних і дорогих (клас Opus), з проміжними (клас Sonnet). Компроміс завжди між трьома осями: якість — швидкість — вартість.

Орієнтир:

прості, масові, чітко окреслені задачі (класифікація баг-репортів, витяг полів, коротке підсумовування) — маленька швидка модель; часто різниця в якості мізерна, а в ціні й латентності — кратна;
складне міркування, генерація й ревʼю коду, багатокрокові агентні задачі — велика модель;
проміжне — середня.

Класична помилка — брати найпотужнішу модель на все «про запас». Для тисяч дрібних викликів це спалює бюджет і час без виграшу в якості. Зворотна помилка — тягнути найдешевшу модель на задачу, де вона систематично галюцинує чи не витягує логіку. Розумний підхід — підбирати модель під конкретний крок, а в агентних системах комбінувати: дешева модель на рутину, дорога — на складні рішення.

Типові помилки

Виглядає як «модель забула контекст» — а насправді історія вилізла за межі вікна й старі повідомлення обрізало. Не баг моделі, а переповнене вікно.
Виглядає як «токенів приблизно стільки ж» для англійської та української — а насправді той самий текст українською займає у 2–3 рази більше токенів. Оцінка за словами вводить в оману.
Виглядає як «великий контекст = точніше» — а насправді через lost in the middle факт у середині довгого документа модель може проігнорувати, і якість на довгому вході просідає.
Виглядає як «кеш не працює, хоча промпт майже той самий» — а насправді змінився початок префікса (дата, id, порядок ключів), і збіг за префіксом зламався.
Виглядає як «вартість = ціна одного запиту» — а насправді в діалозі історія пересилається щоразу, тож вартість росте з кожним ходом; вихідні токени ще й дорожчі за вхідні.
Виглядає як «візьмемо найпотужнішу модель, щоб напевно» — а насправді на простих масових задачах це зайві гроші й латентність без виграшу в якості.

Підсумок

Модель оперує токенами, не словами; українська й код коштують більше токенів, ніж здається, а різні моделі рахують токени по-різному.
Контекстне вікно — спільний бюджет на промпт, історію, документи й відповідь; API stateless, тож історію пересилають щоразу, і вона впирається у вікно.
Довгий контекст не гарантує кращих відповідей: працює lost in the middle і загальна деградація — подавайте релевантний зріз.
Платять за токени; вихідні дорожчі за вхідні в кілька разів, а діалог дорожчає нелінійно через повторне пересилання історії.
Prompt caching здешевлює спільний префікс, але тримається на побайтовому збігу початку; модель обирають під задачу за трикутником якість/швидкість/ціна.

Що питають на співбесіді

«Що таке токен і чому це важливо для роботи з LLM?» — інтервʼюер хоче почути, що модель оперує підслівними токенами, що від них залежать і ліміт контексту, і вартість, і що українська та код токенізуються дорожче.
«Що таке контекстне вікно і що станеться, якщо його перевищити?» — очікують згадку, що у вікно входить усе (промпт + історія + відповідь), що API stateless, і що при переповненні буде помилка, обрізання або стиснення, а не магічна памʼять.
«Чому не варто просто закидати в модель усі логи й вимоги?» — перевіряють розуміння деградації на довгому контексті (lost in the middle) і вартості; сильний кандидат говорить про подання релевантного зрізу.
«Чим відрізняється ціна input і output і як здешевити роботу з LLM?» — дивляться, чи знаєте, що output дорожчий, що діалог пересилає історію, і чи назвете prompt caching, стиснення контексту, вибір меншої моделі.
«Як обрати модель під задачу?» — хочуть побачити мислення в осях якість/швидкість/вартість, а не «беру найкращу»; плюс — приклад, де дешева модель доречна.

Джерела

OpenAI — Tokenizer (інтерактивний): platform.openai.com/tokenizer — подивитися, як текст ріжеться на токени, і порівняти англійську з українською.
Anthropic — Context windows: platform.claude.com/docs/en/build-with-claude/context-windows — як влаштоване контекстне вікно й що в нього входить.
Anthropic — Prompt caching: platform.claude.com/docs/en/build-with-claude/prompt-caching — механіка кешування префікса, ціни й TTL.
N. F. Liu та ін. «Lost in the Middle: How Language Models Use Long Contexts» (TACL, 2024): arxiv.org/abs/2307.03172 — дослідження ефекту «загубленого посередині».

Що таке токен і чому модель не працює зі словами напряму?

Токен (token) — це найменша одиниця тексту, якою оперує модель: зазвичай не ціле слово й не окрема буква, а підслівний фрагмент (subword). Текст ріже на такі шматки токенізатор (tokenizer), найчастіше різновидом BPE (byte-pair encoding), який склеює найчастотніші послідовності символів в окремі токени. Слова моделі «незручні»: словник був би нескінченним і не покривав би одруки та нові слова, а окремі символи — надто дрібні, щоб нести сенс ефективно. Підслівний компроміс дає обмежений словник, який усе ж збирає часте слово в один токен, а рідкісне — з кількох. Для QA це не термінологія заради термінології: саме від токенів залежить і скільки модель вміщає за раз, і скільки коштує кожен запит.

Груба оцінка «100 токенів ≈ 75 слів» — коли вона підводить?

Це робоче правило для англійського тексту (приблизно 4 символи на токен), але для української воно систематично занижує число. Токенізатори тренують переважно на англомовних корпусах, тож кирилиця дробиться на дрібніші шматки — слово нерідко розпадається на кілька токенів. Той самий зміст українською може займати у 2–3 рази більше токенів, ніж англійською. Практично це б'є там, де женете обсяг: генерація тест-кейсів з україномовної специфікації і в ліміт вікна впреться раніше, і за рахунком вийде дорожчою, ніж підказує прикидка «на око» за словами. Тому для масових чи важливих прогонів число токенів рахують лічильником, а не множенням слів на коефіцієнт.

Чому код і JSON токенізуються не так, як здається?

Бо токенізатор бачить не «логіку», а символи, і структурні елементи коштують окремих токенів. Відступи, дужки, лапки, коми, довгі ідентифікатори — усе це окремі шматки, тож щільний на вигляд фрагмент може давати несподівано багато токенів. Мінімізований JSON чи лог на кілька екранів легко з'їдає тисячі токенів, хоч «корисної» інформації там мало. Для QA наслідок прямий: вкидати в контекст цілий сирий лог або весь дамп відповіді — це і роздутий рахунок, і швидше переповнення вікна. Дешевше й точніше подати зріз — потрібні рядки, а не весь файл.

Чому не можна рахувати токени для однієї моделі лічильником від іншої?

Бо різні моделі використовують різні токенізатори, і той самий рядок дає різну кількість токенів у різних провайдерів і навіть у різних поколінь однієї родини. Токенізатор — частина конкретної моделі, а не універсальний стандарт. Класична помилка — оцінювати токени умовного Claude бібліотекою, написаною під токенізатор GPT: число буде правдоподібним, але неправильним, і на межі вікна чи бюджету це підведе. Для точної цифри беруть офіційний токенізатор потрібного провайдера або ендпоінт підрахунку токенів саме тієї моделі, якою збираєтесь працювати.

Що таке контекстне вікно і що в нього входить?

Контекстне вікно (context window) — це стеля токенів, яку модель обробляє за один запит. Ключове: у цей бюджет входить усе одразу — системний промпт, уся історія діалогу, вкладені документи чи логи, поточне питання, і ще має лишитися місце під відповідь, бо згенеровані токени теж рахуються у вікно. Розміри дуже різні: від кількох тисяч у старих чи маленьких моделей до 200 000 і навіть 1 000 000 у сучасних. Окремо зазвичай існує ліміт на довжину самої відповіді (max output), тож навіть мільйонне вікно не означає мільйон токенів тексту за раз. Для QA це бюджет, який треба свідомо розподіляти, а не сподіватися, що «якось поміститься».

Що означає «API моделі stateless» і як тоді працює «памʼять» чату?

Stateless означає, що між запитами модель не зберігає нічого: кожен виклик API самодостатній і не знає про попередні. «Памʼять» чату — ілюзія, яку створює клієнт: він щоразу надсилає всю історію повідомлень заново, і модель щоразу перечитує її з нуля. Звідси два наслідки. По-перше, з кожним ходом діалогу вхід росте, бо історія накопичується й пересилається повністю. По-друге, рано чи пізно ця історія впирається у вікно. Розуміти це важливо, щоб не дивуватися ні зростанню вартості довгої сесії, ні тому, що модель раптом «забула» сказане на початку.

Що станеться, коли розмова перевищить контекстне вікно?

Магічної памʼяті не буде — станеться одне з трьох, і всі варіанти неприємні. Або запит поверне помилку про перевищення ліміту, або клієнт/сервіс обріже старі повідомлення, щоб влізти у вікно, або історію примусово стиснуть у коротший переказ. У двох останніх випадках модель справді «забуває» те, що ви казали багато реплік тому — не тому, що вона «дурна», а тому, що цих токенів уже немає у вході. Для QA це діагностичний орієнтир: коли агент після сотні кроків «губить» початкову інструкцію, перший підозрюваний — переповнене вікно й обрізана історія, а не баг моделі.

Чому «закинути в модель усе підряд» — погана ідея навіть з великим вікном?

Бо місткість вікна і здатність якісно нею скористатися — різні речі. Велике вікно спокушає вкинути туди і специфікацію, і код, і всі логи, але довгий контекст одночасно дорожчий, повільніший і не обов'язково точніший. Що більше зайвого в контексті, то дужче розпорошується увага моделі, і на дуже довгих входах якість, стабільність та точність можуть просідати. Розумніше подати релевантний зріз: потрібний фрагмент логу замість цілого файлу, конкретний розділ вимог замість усього Confluence. Це той самий принцип, що й у ручному тестуванні: сфокусована перевірка б'є «протестуй геть усе».

Що таке ефект «загублене посередині» (lost in the middle)?

Це добре задокументоване спостереження, що моделі надійніше дістають інформацію з початку та кінця контексту, ніж із його середини. Помістіть потрібний факт у середину довгого документа — і шанс, що модель його «не помітить», зростає, навіть якщо формально факт у вікні. Причина не в тому, що токенів бракує, а в тому, як модель розподіляє увагу вздовж довгого входу. Практичний висновок для QA: не покладайтеся на те, що модель знайде критичну деталь, похована в середині простирадла логів чи вимог. Важливе краще виносити ближче до країв або взагалі подавати окремо, а не топити в масиві.

Чим різниться ціна input і output токенів?

Оплата йде окремо за два потоки: вхідні (input) токени — усе, що ви надіслали (промпт, історія, документи), і вихідні (output) токени — усе, що модель згенерувала. Головне правило: вихідні коштують у кілька разів дорожче за вхідні, типово в 5–6 разів. Наприклад, для моделей класу Opus станом на липень 2026 вхід — це порядку кількох доларів за мільйон токенів, а вихід — кількох десятків, тобто співвідношення 1 до 5; точні числа залежать від моделі й регулярно змінюються, тож звіряйтеся з прайсом провайдера. Ще нюанс: токени «міркування» (reasoning), якщо модель їх генерує, теж рахуються як вихідні. Тому задачі з довгими відповідями плануйте бюджетувати за вихідним тарифом, а не за дешевшим вхідним.

Чому діалог з моделлю дорожчає нелінійно?

Бо історію пересилають повністю на кожному ході (API stateless), тож кожен наступний запит оплачує всі попередні як вхід. Десятий хід везе у вході і системний промпт, і всі дев'ять попередніх реплік разом із відповідями — і платить за них знову. Виходить, що вартість росте не рівномірно, а прискорено: чим довший діалог, тим більший вхід кожного нового кроку. Довга агентна сесія з десятками кроків і великими логами в контексті легко коштує помітно більше, ніж здається з ціни одного «дешевого» запиту. Тому в оцінці вартості дивляться на всю сесію, а не на окремий виклик, і стискають історію, коли вона розростається.

Що таке prompt caching і коли він окупається?

Prompt caching (кешування промпта) зберігає вже оброблений початок запиту, щоб наступні запити з тим самим початком не рахували його заново. Це має сенс, коли багато запитів починаються з того самого великого шматка: незмінного системного промпта, великої специфікації, набору прикладів. Порядок цін у Anthropic станом на липень 2026: читання з кешу коштує близько 10% від звичайної ціни вхідного токена, а перший запис у кеш — трохи дорожче за звичайний вхід (1.25x); в інших провайдерів множники свої. Тобто вже з другого-третього повторення того самого префікса кеш окупається і грошима, і швидкістю. Для QA це прямий важіль: якщо ганяєте сотню промптів проти однієї великої спеки (генерація кейсів, ревʼю), кешування цієї спеки економить і бюджет, і час прогону.

Чому кеш «ламається», хоча промпт майже той самий?

Бо кеш працює на збігу за префіксом (prefix match): він валідний рівно доти, доки початок запиту побайтово однаковий. Одна змінена дужка, вставлена дата, інший порядок ключів у JSON на початку — і кеш після цієї точки анулюється, запит рахується з нуля за повною ціною. «Майже той самий» тут не рахується: важлива буквальна тотожність початку. Ще є час життя кеша (TTL, часто кілька хвилин), після якого префікс треба «прогріти» заново. Тому симптом «кеш не працює, хоча промпт майже ідентичний» майже завжди означає, що на початку щось мінливе зламало збіг, або минув TTL.

Куди класти стабільне, а куди мінливе в промпті, і чому?

Стабільне — на початок, мінливе — у кінець. Оскільки кеш тримається на побайтовому збігу префікса, усе незмінне (системний промпт, велика специфікація, приклади) має стояти першим, щоб цей блок кешувався й перевикористовувався між запитами. А все, що змінюється від виклику до виклику (поточне питання, timestamp, id запуску), має йти після — інакше воно зсуне префікс і зламає збіг для всього, що далі. Це та сама ідея, що й у HTTP-кеші: зберегти вже пораховане й не рахувати вдруге. Практично для QA це означає структурувати промпт свідомо: не вставляти дату чи випадковий id на початку великого сталого блоку.

Автотести з LLM-генерацією подорожчали після переходу на україномовну специфікацію. Це баг білінгу?

Ні, це очікуваний ефект токенізації, а не помилка в рахунку. Той самий за змістом текст українською займає у 2–3 рази більше токенів, ніж англійською, бо кирилиця дробиться токенізатором на дрібніші шматки. Якщо специфікація, з якої генеруються кейси, переїхала з англійської на українську, вхідних токенів на кожен запит стало кратно більше — звідси й зростання рахунку, і швидше наближення до ліміту вікна. Перевірити просто: прогнати обидві версії спеки через токен-лічильник потрібної моделі й порівняти числа. Це аргумент подавати сталу частину промпта мовою, якою вона компактніша, або принаймні закладати цей коефіцієнт у бюджет.

Як обрати модель під задачу і чому «беру найпотужнішу» — не стратегія?

Немає «найкращої» моделі — є доречна, і вибір роблять у трикутнику якість / швидкість / вартість. Провайдери зазвичай мають лінійку: маленькі швидкі й дешеві (клас Haiku), великі потужні й дорогі (клас Opus), проміжні (клас Sonnet). Прості, масові, чітко окреслені задачі — класифікація баг-репортів, витяг полів, коротке підсумовування — часто без втрати якості тягне маленька модель, а різниця в ціні й латентності кратна. Складне міркування, генерація й ревʼю коду, багатокрокові агентні сценарії — робота для великої. Брати найпотужнішу «про запас» на тисячі дрібних викликів — це спалювати бюджет і час без виграшу в якості; зворотна крайність — тягнути найдешевшу туди, де вона систематично галюцинує. Розумний підхід у агентних системах — комбінувати: дешева модель на рутину, дорога на складні рішення.

Три робочі кейси, де токени й контекст перетворюються на конкретні рішення QA: прикидка вартості прогону генерації тест-кейсів (де ховаються гроші), розкладка промпта під prompt caching у коді (що вмикає й що ламає кеш) і таблиця вибору моделі під типові задачі. Числа тут ілюстративні — точні тарифи звіряйте з прайсом провайдера, важлива механіка.

Кейс 1. Скільки коштує прогін генерації тест-кейсів

Задача: згенерувати тест-кейси проти специфікації розміром ~20 000 токенів, у діалозі з чотирьох ходів (згенеруй позитивні → додай негативні → покрий межові → перепиши у форматі Gherkin). Спека українською, тож її розмір у токенах уже враховує «кириличний податок». Порахуймо вхід по ходах, памʼятаючи, що історію пересилають повністю щоразу.

Хід	Що у вході (input)	Вхідних токенів	Вихідних токенів
1	спека 20k + питання	~20 300	~2 000
2	спека + питання 1 + відповідь 1 + питання 2	~22 400	~2 000
3	усе попереднє + питання 3	~24 500	~2 000
4	усе попереднє + питання 4	~26 600	~2 500

Що тут видно і чому:

Вхід росте щоходу, хоча спека одна. Причина не в спеці, а в накопиченій історії: API stateless, тож кожен хід везе всі попередні репліки заново. До четвертого ходу спека фактично оплачена чотири рази.
Вихід дорожчий, ніж здається. Якщо вихідний токен коштує в ~5 разів більше за вхідний, то ~8 500 вихідних токенів за сесію можуть переважити частину «дешевого» входу. Довгі відповіді бюджетують за вихідним тарифом.
Українська спека — прихований множник. Та сама спека англійською зайняла б ~7–10k токенів замість 20k, тобто і вхід кожного ходу, і рахунок були б помітно меншими. Це аргумент тримати стабільну частину промпта компактною мовою.
Головний висновок: оцінюємо вартість усієї сесії, а не одного «дешевого» першого запиту. Довга агентна сесія з логами в контексті дорожчає прискорено.

Груба прикидка перед масовим прогоном — без здогадок «на око»:

// Ілюстративні тарифи за 1M токенів; підставте актуальні з прайсу провайдера
const IN = 3;      // input, $/MTok
const OUT = 15;    // output, $/MTok (дорожчий у ~5x)

const inputTokens = 20_300 + 22_400 + 24_500 + 26_600; // сума входів по ходах
const outputTokens = 2_000 + 2_000 + 2_000 + 2_500;

const cost = (inputTokens * IN + outputTokens * OUT) / 1_000_000;
// приблизно (93 800 * 3 + 8 500 * 15) / 1e6 ≈ $0.41 за одну сесію
// помножте на 200 сценаріїв — і «копійчаний» запит стає відчутним бюджетом

Кейс 2. Розкладка промпта під prompt caching

Ганяємо сотню запитів проти однієї великої спеки (генеруємо кейси й робимо ревʼю). Спека незмінна, змінюється лише поточне питання — ідеальний випадок для кешування префікса. Кеш працює на побайтовому збігу початку, тож усе стале кладемо першим, усе мінливе — останнім.

// ПРАВИЛЬНО: стабільний префікс на початку → кешується й перевикористовується
const messages = [
  { role: "system", content: SYSTEM_PROMPT }, // незмінний
  { role: "user", content: SPEC },            // велика незмінна спека (20k токенів)
  { role: "user", content: currentQuestion }, // єдине, що змінюється щозапиту
];
// перший запит: запис у кеш ~1.25x; далі читання префікса ~0.1x замість повної ціни

А тепер типова помилка, через яку кеш «мовчки не працює»:

// НЕПРАВИЛЬНО: мінливе значення заповзло на ПОЧАТОК префікса
const messages = [
  { role: "system", content: `Запуск від ${new Date().toISOString()}\n${SYSTEM_PROMPT}` },
  { role: "user", content: SPEC },
  { role: "user", content: currentQuestion },
];
// timestamp на самому початку зсуває префікс щозапиту → збіг ламається,
// спека рахується з нуля за повною ціною кожного разу

Що дивитися і чому:

Симптом «кеш не окупається, хоча промпт майже той самий». «Майже» тут не рахується: одна вставлена дата, id запуску чи переставлений ключ у JSON на початку — і весь префікс після цієї точки анулюється. Шукайте, що мінливе заповзло у голову промпта.
Порядок оплачується. Зі стабільним префіксом уже з другого-третього запиту кеш повертає вкладене: читання ~10% проти повної ціни вхідних токенів спеки. На сотні запитів це кратна економія бюджету й латентності.
Памʼятайте про TTL. Кеш живе обмежений час (часто кілька хвилин); якщо між запитами великі паузи, префікс доведеться «прогрівати» заново. Для щільного прогону це не проблема, для рідких викликів — так.
Це той самий принцип, що й HTTP-кеш: зберегти вже пораховане й не рахувати вдруге, з тим самим питанням валідності початку.

Кейс 3. Яку модель узяти під задачу

Спокуса взяти найпотужнішу модель «щоб напевно» коштує грошей і латентності там, де виграшу в якості немає. Розкладаємо типові QA-задачі по трикутнику якість / швидкість / вартість.

Задача	Профіль	Розумний вибір	Чому
Класифікація баг-репортів за компонентом	масова, чітка, проста	маленька (клас Haiku)	різниця в якості мізерна, а в ціні й латентності — кратна
Витяг полів з тексту тикета	масова, шаблонна	маленька	структурований витяг не потребує глибокого міркування
Коротке підсумовування логу падіння	обсяг, проста мета	маленька / середня	якщо не треба глибокого аналізу — дешевша впорається
Генерація складних тест-сценаріїв зі спеки	міркування, покриття	велика (клас Opus)	тут якість покриття прямо залежить від сили моделі
Ревʼю коду автотестів	міркування, точність	велика	дешева модель систематично пропускає логіку
Багатокрокова агентна сесія	планування, стійкість	комбінація	рутинні кроки — дешева, складні рішення — дорога

Що дивитися і чому:

Дві дзеркальні помилки. Найпотужніша модель на тисячі дрібних викликів спалює бюджет без виграшу; найдешевша на складному міркуванні систематично галюцинує чи не витягує логіку. Обидві однаково дорого коштують — просто по-різному.
В агентних системах комбінують. Дешева модель на рутину (парсинг, класифікація проміжних кроків), дорога — на вузлові рішення. Це не компроміс якості, а розподіл ресурсу під конкретний крок.
Рішення не вічне. Лінійки й ціни моделей регулярно змінюються, тож вибір варто переглядати, а числа звіряти з поточним прайсом, а не з памʼяті.

Токени й токенізація

Можу пояснити, що таке токен (підслівний фрагмент) і що модель ріже текст токенізатором, найчастіше різновидом BPE.
Знаю оцінку для англійської (≈4 символи або ≈¾ слова на токен) і що українська коштує у 2–3 рази більше токенів за той самий зміст, бо кирилиця дробиться дрібніше.
Розумію, чому код і JSON токенізуються неочевидно: відступи, дужки, лапки, довгі ідентифікатори — окремі токени.
Знаю, що різні моделі мають різні токенізатори, тож не рахую токени однієї моделі лічильником від іншої.

Контекстне вікно

Можу перелічити, що входить у вікно: системний промпт, історія, документи, поточне питання і місце під відповідь (згенеровані токени теж займають вікно).
Знаю, що окремо існує ліміт на довжину відповіді (max output), не тотожний розміру вікна.
Можу пояснити, що API stateless: «памʼять» чату — це щоразове пересилання всієї історії клієнтом.
Знаю три сценарії переповнення вікна: помилка запиту, обрізання старих повідомлень, примусове стиснення історії.

Довгий контекст і деградація

Розумію, що місткість вікна і здатність якісно нею скористатися — різні речі: на довгих входах увага розпорошується, точність і стабільність просідають.
Можу пояснити ефект «загублене посередині» (lost in the middle): факт у середині довгого входу модель дістає гірше, ніж з країв.
Можу сформулювати практику: подавати релевантний зріз, а не «вивалити все підряд».

Вартість: input проти output

Знаю, що input і output тарифікуються окремо (зазвичай за мільйон токенів) і вихідні дорожчі за вхідні в кілька разів (типово 5–6).
Розумію, що reasoning-токени рахуються як вихідні.
Можу пояснити, чому діалог дорожчає нелінійно: історію пересилають повністю щоходу, тож пізні кроки оплачують усі попередні.

Prompt caching

Розумію ідею кешувати спільний префікс і порядок цін (Anthropic, станом на 07.2026): читання з кешу ≈10% вхідної ціни, перший запис ≈1.25x, окупність з 2–3-го повторення.
Можу пояснити, що кеш тримається на побайтовому збігу префікса (prefix match): зміна дати, дужки чи порядку ключів на початку його ламає; є ще TTL (кілька хвилин), після якого префікс прогрівають заново.
Розумію правило розкладки: стабільне — на початок, мінливе — в кінець.

Економія й вибір моделі

Можу назвати прийоми економії: зріз замість усього файлу, стиснення історії, вибірка з бази знань (RAG), підрахунок токенів перед відправкою.
Розумію трикутник вибору моделі (якість / швидкість / вартість) і розкладку по класах (Haiku / Sonnet / Opus): рутина на дешеву, складне міркування на дорогу.
Можу пояснити обидві крайні помилки: найпотужніша модель на масову дрібноту і найдешевша там, де вона систематично галюцинує.