Підтримка й ефективність

Економіка студії штучного інтелекту: експертиза, ціна та повна вартість роботи

У демо агент створив робочий прототип за годину. До релізу засновник витратив ще пів дня на розбір неоднозначних рішень, повторний запуск перевірок,…

Глава 70Заморожене українське видання

У демо агент створив робочий прототип за годину. До релізу засновник витратив ще пів дня на розбір неоднозначних рішень, повторний запуск перевірок, розмову з клієнтом і виправлення помилки в доступах. Клієнт купував не швидкість генерації коду, а результат, який можна безпечно прийняти й підтримувати. Щоб зрозуміти економіку роботи, потрібно порахувати і те, що зробив агент, і людське судження навколо нього.

Навчальний результат. Після цієї глави читач може пов’язати спеціалізацію студії з тим, які проблеми вона розв’язує; провести діагностичну розмову без безоплатного повного проєктування; обрати між оплатою за час, фіксованою ціною, продуктовою послугою та підтримкою; порахувати людські й технічні витрати; розрізнити виручку, прибуток і рух грошей; оцінити вартість прийнятої задачі з урахуванням повторів і людської перевірки.

Усі розрахунки нижче навчальні. Вони показують спосіб мислення, а не ринкову ставку, прогноз доходу чи рекомендацію щодо договору або податків. Реальні суми залежать від клієнта, валюти, договору, країни, сервісів і конкретного місяця.

Блок A. Експертна студія продає судження та відповідальність за роботу

70.1. Клієнт платить за розв’язану проблему, а не за кількість токенів

Розроблена функція, агент, звіт або інтеграція — це результат роботи, але не обов’язково бізнес-результат клієнта. Клієнт може купувати швидше опрацювання заявок, менше ручних помилок, стабільніше обслуговування або спосіб прийняти рішення за неповних даних. Перш ніж оцінювати завдання, з’ясуйте, яку зміну має побачити замовник, як її прийматимуть і які частини результату залишаються поза контролем студії.

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

Девід Майстер у Managing the Professional Service Firm розглядає баланс клієнтського сервісу, розвитку фахівців і фінансового здоров’я фірми. В офіційно опублікованому уривку першого розділу видавництво наголошує на цьому балансі та на тому, що склад команди впливає на нього. У статті The Anatomy of a Consulting Firm Майстер окремо описує чотири метафоричні типи послуг — від процедурної роботи до складної діагностики й довірчого консультування.

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

Для послуги з високою невизначеністю важливіший час на діагностику й досвідчений перегляд. Повторюваний запуск на перевіреному конекторі можна стандартизувати, але лише після того, як студія знає винятки та критерії приймання. Швидка відповідь моделі не перетворює нерозібрану проблему на послугу з визначеним обсягом.

70.2. Спеціалізація дає змогу впізнавати закономірності, але не гарантує продажу

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

Девід С. Бейкер у матеріалах до The Business of Expertise: How Entrepreneurial Experts Convert Insight to Impact + Wealth описує три опорні ідеї книжки: експертність допомагає знаходити закономірності в даних; ці закономірності можна перетворити на виразне позиціонування, якому мало близьких замін; упевненість у позиціонуванні зростає, коли ринок приймає його застосування.

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

Бейкер також підкреслює різницю між стратегією та виконанням. Студія може добре реалізувати рішення, але не має автоматичного права називати себе стратегічним радником, якщо не може підтвердити якість діагностики. І навпаки, сильне судження не означає, що команда має власноруч виконати кожен технічний крок.

У The Win Without Pitching Manifesto Блер Еннс закликає спеціалізуватися, починати з діагностики, обговорювати гроші завчасно, вибирати відповідну роботу й не розв’язувати повну проблему до оплати. Це принципи продажу експертної творчої послуги; вони не доводять, що спеціалізація автоматично збільшить виручку або що кожен клієнт має оплачувати однаковий етап відкриття. Використовуйте їх, щоб побудувати чесну розмову про потребу й межі безоплатної роботи.

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

Джерела до блоку A

  • David H. Maister, Managing the Professional Service Firm, Free Press, 1993. Перевірено офіційну сторінку Simon & Schuster і доступний уривок першого розділу; повний текст книжки не переглядався. Доступ: 25.09.2026. Видавець і уривок.
  • David H. Maister, “The Anatomy of a Consulting Firm”, авторський матеріал про різні типи послуг і їхню економіку; сторінка перевірена 25.09.2026. Це онлайн-стаття, а не повний текст книжки.
  • David C. Baker, The Business of Expertise: How Entrepreneurial Experts Convert Insight to Impact + Wealth, RockBench. Перевірено офіційні сторінку автора й картку видавця, включно з описом основних тез; сторінка видавця вказує тверду обкладинку, але не подає року чи номера видання. Завантажений зразок не вдалося прочитати, повний текст книжки не переглядався. Доступ: 25.09.2026. Авторська сторінка; видавець RockBench.
  • Blair Enns, The Win Without Pitching Manifesto, RockBench, перше видання 2010 року. Перевірено сторінку автора з дванадцятьма принципами та розмову Еннса про публікацію книжки; повний текст не переглядався. Доступ: 25.09.2026. Дванадцять принципів; розмова про видання книжки.

Блок B. Продаж і ціна починаються з розмови про ризик

70.3. Поставте діагноз до рецепта й не продавайте невідому роботу як певну

Перша розмова має з’ясувати, що спонукало клієнта звернутися зараз, які наслідки має проблема, що вже пробували, хто користуватиметься результатом і хто його прийматиме. Далі з’ясуйте обмеження: строки, доступи, чутливі дані, сумісність із наявними системами, бюджетний діапазон і право схвалити зміни. Пояснюйте питання як спосіб запобігти помилковій пропозиції, а не як техніку тиску.

До того як писати докладну архітектуру чи демонстрацію, узгодьте, який рівень роботи оплачений. Коротке знайомство може визначити відповідність і наступний крок. Discovery — оплачуваний етап діагностики — може завершитися картою вимог, варіантами, ризиками, оцінкою діапазону та планом приймання, не зобов’язуючи клієнта купувати реалізацію. Якщо невизначеність ще висока, не видавайте приблизний кошторис за гарантовану ціну. Скажіть, які припущення можуть змінити оцінку і що потрібно дізнатися, перш ніж обіцяти строк.

Розібраний приклад 1: повний безоплатний pitch проти обмеженої діагностики. Умовна студія має чотири звернення про агента для обробки замовлень. Власник готує кожному восьмигодинний дизайн рішення перед тим, як клієнт вирішить, чи купувати роботу. Для внутрішнього розрахунку година засновника коштує €80: це ставка повної вартості його часу, а не ринковий тариф. Чотири пропозиції забирають 4 × 8 × €80 = €2 560 і 32 години засновника. Одне звернення перетворюється на проєкт, інші три не переходять до оплати. У витратах залишається €2 560 продажної роботи; сам факт, що команда «виборола» один клієнт, не повертає час за інші пропозиції.

Альтернативний умовний процес: на кожну заявку студія витрачає годину на розмову про відповідність і ризики. Це 4 × 1 × €80 = €320 витрат на кваліфікацію всіх чотирьох звернень. Лише одна заявка підходить, і клієнт купує окрему шестигодинну діагностику за €1 200. Її собівартість виконання — 6 × €80 + €120 розподілених операційних витрат = €600; отже, після витрат на саме виконання лишається €600 до врахування продажного часу. Якщо для оцінки цього єдиного продажу віднести на нього всі €320 кваліфікації, після обох статей залишиться €280, а витрати на три інші звернення не принесуть доходу. Внутрішній управлінський звіт може показати €320 окремо як загальну вартість залучення; правило розподілу не має робити цей час безкоштовним. Клієнт отримує самостійно корисний результат: визначення проблеми, перевірені припущення, можливі варіанти, ризики й критерії приймання. Подальша розробка має окремий бюджет і може бути доручена студії чи іншій команді. Це не доводить, що платна діагностика завжди підвищить конверсію: вона робить ціну роботи й вибір сторін видимими.

Раннє обговорення грошей допомагає виявити, чи є відповідність очікувань і бюджету. Відмова теж може бути правильною рекомендацією: якщо проблема виходить за межі компетенції, студія має назвати цю межу, а не продавати впевненість, якої не має. Обсяг безоплатної передпродажної роботи може бути більшим для простого повторюваного замовлення та меншим для невідомої системи з високим ризиком.

70.4. Ціна має відповідати обсягу, цінності й тому, хто несе ризик

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

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

Тип моделі оплати змінює розподіл ризику:

  • Час і матеріали (time and materials): клієнт платить за погоджені години й прямі витрати. Це може пасувати дослідницькій роботі, вимоги якої уточнюються в процесі; клієнт бере на себе ризик змінної кількості годин. Зменшуйте невизначеність бюджетними межами, короткими етапами та регулярною перевіркою пріоритетів.
  • Фіксована ціна: сторони погоджують визначений результат і суму. Клієнт отримує передбачуваний бюджет, а студія бере на себе ризик недооцінити власне виконання. Потрібні явні припущення, критерії приймання, межі змін, підтримки й зовнішніх витрат; зміна запиту проходить окреме погодження.
  • Продуктована послуга: клієнт купує обмежений пакет із заздалегідь визначеними умовами, результатом, ціною та способом виконання. Повторне використання методів може знизити собівартість, але пакет не підходить кожній системі. Заздалегідь визначте, які дані, платформи, обсяг і винятки роблять замовлення придатним.
  • Ретейнер або підтримка: клієнт оплачує доступність, регулярну роботу чи визначений обсяг підтримки в періоді. Уточніть час відповіді, години/місяць, порядок ескалації, тарифи за перевищення, права доступу, зміни поза переліком і те, чи переносяться невикористані години. Саме слово «ретейнер» не означає необмеженої роботи.

Оцінка, пропозиція, бюджет і договірна обіцянка — різні ступені впевненості. Оцінка дає діапазон за відомих припущень. Бюджет може бути межею планування. Пропозиція описує обсяг і комерційні умови. Погоджена обіцянка має бути достатньо конкретною, щоб обидві сторони знали, що означає завершення. Юридичні формулювання та правила обліку залежать від договору й місцевих вимог; за потреби їх погоджують із кваліфікованим фахівцем.

Розібраний приклад 2: та сама базова задача в трьох форматах ціни. Клієнт просить з’єднати вебформу замовлення з підтримуваною системою керування клієнтами. Навчальний стандартний результат: одна форма, одна система, до п’яти полів, перевірка помилок, один запуск і передавання інструкції. Подальша міграція даних, спеціальна автентифікація та невідомі правила обробки замовлень не входять у базове припущення.

Для порівняння студія оцінює повну собівартість саме стандартного проєкту:

Витрата Розрахунок Сума
Діагностика й огляд засновника 8 год × €80 €640
Реалізація інженера 30 год × €50 €1 500
Сервісні витрати, тестування й інфраструктура умовна пряма сума €200
Частка оренди, адміністрування та програмного забезпечення умовний розподіл накладних витрат €500
Резерв на погоджене виправлення й підтримку очікувана повна вартість €200
Повна собівартість у прикладі сума рядків €3 040

За оплатою часу й матеріалів ставка засновника — €130/год, а інженера — €85/год. Рахунок дорівнює 8 × €130 + 30 × €85 + €200 = €3 790. Після повної собівартості лишається €3 790 − €3 040 = €750; цей залишок становить €750 / €3 790 ≈ 19,8% рахунку. Якщо фактичний інженерний час збільшиться, рахунок клієнта й витрати зростатимуть разом у межах погоджених правил; клієнту потрібні бюджетні перевірки.

За фіксованої ціни €4 700 та тих самих очікуваних витрат лишається €4 700 − €3 040 = €1 660; цей залишок становить €1 660 / €4 700 ≈ 35,3% ціни. Якщо через помилку оцінки студії знадобиться ще 20 інженерних годин за внутрішньою вартістю €50/год, додаткова собівартість становитиме €1 000. Без погодженої зміни обсягу залишок зменшиться до €660 (€4 700 − €4 040), або близько 14,0% ціни. Якщо ж змінився сам запит клієнта, спочатку погодьте нову межу, строк і ціну, а не приховуйте зміну в тій самій обіцянці.

Продуктований пакет може коштувати €2 600, якщо задача проходить перевірку відповідності й команда використовує повторюваний маршрут. Для цього пакета робота засновника — 3 × €80 = €240, інженера — 10 × €50 = €500, сервісні витрати — €80, накладні витрати — €250, резерв підтримки — €100. Собівартість становить €1 170, залишок — €2 600 − €1 170 = €1 430, або 55,0% ціни. Це не та сама угода, якщо клієнтові потрібні міграція старих даних чи нестандартна інтеграція: така вимога або не проходить критерії пакета, або оцінюється окремо. Вищий розрахунковий залишок не гарантує продажів, і стандартизація має зберігати якість та навчання команди.

Відсотки в прикладі — навчальне відношення залишку після всіх наведених витрат до ціни; це не стандартна валова маржа, бо в розрахунку вже є накладні витрати й резерв підтримки. Інші команди можуть інакше класифікувати прямі та накладні витрати. Запишіть власне правило й застосовуйте його послідовно; не порівнюйте відсотки, якщо знаменники й спосіб обліку відрізняються.

70.5. Зміни обсягу й підтримка потребують окремих домовленостей

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

Discovery краще оплачувати окремо, коли правильний обсяг неможливо визначити без перевірки даних, середовища чи правил. Підтримка після завершення теж є окремою роботою: виправлення дефекту в погодженій межі може входити до гарантійної домовленості; нова функція чи зміна зовнішнього програмного інтерфейсу (application programming interface, API) — ні, якщо сторони не погодили інше. Чіткі межі зменшують здивування обох сторін і дають змогу чесно прогнозувати ресурс.

Джерела до блоку B

  • Blair Enns, The Win Without Pitching Manifesto, RockBench, перше видання 2010 року; сторінка автора з принципами спеціалізації, діагностики до рецепта, ранньої розмови про гроші й меж безоплатного розв’язання. Перевірено 25.09.2026; повний текст книжки не переглядався. Сторінка автора.
  • David C. Baker, The Business of Expertise: How Entrepreneurial Experts Convert Insight to Impact + Wealth, офіційний опис автора й видавця про закономірності, позиціонування та перевірку попиту. Перевірено 25.09.2026; повний текст книжки не переглядався. Сторінка книги.
  • David H. Maister, “Responding to Fee Pressure,” авторський матеріал про продуктивність, ціну й умови результативної оплати. Перевірено 25.09.2026. Матеріал Maister.

Блок C. Економіка виконання враховує працю людей і гроші в часі

70.6. Розділяйте дохід, витрати, залишок і рух грошей

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

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

Засновник має записувати час на продаж, діагностику, постановку задачі, архітектуру, керування агентом, перевірку, виправлення, підтримку, навчання та адміністрування. Якщо він не отримує зарплату за окремо відстежені години, це не означає, що його час безкоштовний. Для внутрішнього розрахунку використайте обґрунтовану вартість заміни цієї праці або іншу сталу управлінську ставку; не додавайте її вдруге, якщо цю саму працю вже враховано в оплаті чи накладних витратах.

Розібраний приклад 3: чотири проєкти й порожня каса наприкінці місяця. Умовна студія прийняла чотири замовлення по €8 000: виручка за виконану роботу становить €32 000. Пряма праця виконавців коштувала €12 000, засновник записав 48 годин архітектури й огляду за внутрішньою ставкою €80/год (48 × €80 = €3 840), а зовнішні сервіси, моделі й інфраструктура коштували €720. Прямі витрати — €12 000 + €3 840 + €720 = €16 560. Валовий прибуток — €32 000 − €16 560 = €15 440, валова маржа — €15 440 / €32 000 ≈ 48,3%.

За цей самий місяць накладні витрати становили €6 000. Умовний операційний результат до податків і фінансових статей — €15 440 − €6 000 = €9 440. Проте клієнти сплатили лише два рахунки по €8 000. Грошові надходження — €16 000, тоді як банківські виплати студії становили €12 000 виконавцям, €720 зовнішнім сервісам і €6 000 накладних витрат: €16 000 − €18 720 = −€2 720 до виплат власнику й податків. Ще €16 000 очікують на оплату. Внутрішня оцінка часу засновника (€3 840) входить до собівартості навіть якщо гроші за неї не виведені з рахунку в цьому місяці. Якби він отримав зарплату чи оплату, це відобразилося б у реальних грошових витратах згідно з обліком компанії.

Висновок прикладу не в тому, що студія збиткова або що виставлення рахунків потрібно замінити передоплатою в кожному договорі. Видно дві різні управлінські задачі: чи окупається робота після всіх витрат і чи збігаються строки надходжень із виплатами. Умови авансу або проміжних платежів, резерв ліквідності та порядок стягнення боргу команда обирає з урахуванням клієнта, договору та місцевих правил.

70.7. Завантаженість не є самостійною метою

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

ДеМарко й Лістер у доступному видавничому уривку Peopleware: Productive Projects and Teams, третьому виданні, розрізняють присутність на роботі та зосереджений час виконання. Вони критикують табелі, що змушують складати години без різниці між змістовною роботою й перериваннями, як ненадійне джерело оцінки продуктивності. Їхній уривок не є універсальним нормативом завантаженості для кожної студії. Не перетворюйте наведений авторами коефіцієнт часу потоку на ціль, і не використовуйте показник billable utilization як преміювання окремих людей без контексту.

Розібраний приклад 4: засновник переглядає все сам. У попередньому прикладі 48 годин засновника пішли на чотири огляди — по 12 годин на проєкт. Студія навчає колегу виконувати першу перевірку: 6 годин на проєкт за внутрішньою ставкою €50/год. Засновник залишає 3 години перевірки на проєкт за ставкою €80/год і витрачає 8 годин на початкове навчання.

Складник Раніше Після делегування
Огляд засновника 4 × 12 год × €80 = €3 840 (48 год) 4 × 3 год × €80 = €960 (12 год)
Перша перевірка колеги — 4 × 6 год × €50 = €1 200 (24 год)
Початкове навчання — 8 год × €80 = €640 (8 год)
Загальна вартість €3 840 €2 800
Час засновника 48 год 20 год

Розрахункова економія першого місяця — €1 040.

Результат залежить від припущень: колега справді має час; якість не падає; виправлення й підтримка не зростають; €50/год правильно відображає його повну внутрішню вартість. Решта 28 годин засновника — це спроможність, а не дохід. Вона стає прибутком лише якщо студія робить із нею корисну роботу, може її продати, доставити без нової черги й отримати оплату. Передавання роботи без навчання та перегляду може лише відкласти дорожчу помилку.

Джерела до блоку C

  • David H. Maister, “Results and Rewards in the Multi-Group Firm,” авторський матеріал про маржу, ставку, використання часу, склад команди та збалансовані результати. Перевірено 25.09.2026; твердження застосовано як концептуальне застереження, не норматив для маленьких студій. Матеріал Maister.
  • Tom DeMarco та Tim Lister, Peopleware: Productive Projects and Teams, 3-тє видання, Addison-Wesley Professional, 2013/2014. Перевірено сторінку видавця та безкоштовний уривок розділу 10 (сторінки 63–70) про звітність часу, переривання й зосереджену роботу; повний текст не переглядався. Доступ: 25.09.2026. Сторінка Pearson; уривок видавця.
  • David H. Maister, Managing the Professional Service Firm, Free Press, 1993. Сторінка видавця й доступний уривок першого розділу; повний текст книжки не переглядався. Доступ: 25.09.2026. Simon & Schuster.

Блок D. Витрати агента потрібно рахувати до прийнятого результату

70.8. Повна вартість починається з журналу використання

Токен — частина тексту чи іншого модельного входу, яку обробляє модель. У рахунку важливі не лише вхідні й вихідні токени, а й контекст, який надсилають повторно, запис/читання кешу, кількість викликів, повторні спроби, паралельні робітники та платні інструменти. Інструмент із власною ціною може додавати окрему плату поверх токенів, а його результати можуть збільшити вхідний контекст. Не припускайте, що два агенти з однаковою назвою витрачають однакову кількість ресурсів на задачу.

Зберігайте дані за клієнтом і задачею: ідентифікатор проєкту, модель і її версію, ревізію інструкцій, розмір контексту, вхідні/вихідні/кешовані токени, платні виклики інструментів, повтори, тривалість, витрати на середовище та підсумок оцінювання. Для кожної зміни рахуйте також людські хвилини на перевірку, виправлення, ескалацію й очікувану підтримку. Записи мають містити найменше потрібних даних; не зберігайте секрети доступу та приватні клієнтські дані в журналах лише заради вартості.

Корисна формула:

Повна вартість прийнятої задачі = витрати на всі модельні виклики та повтори + інструменти й зовнішні API + середовище, безперервна інтеграція (continuous integration, CI), зберігання та хостинг + час людей на оцінювання, перевірку й виправлення + очікувана підтримка + обґрунтована частка накладних витрат.

Собівартість одного прийнятого результату = повна сума витрат за всі спроби / кількість результатів, прийнятих за визначеним критерієм.

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

70.9. Підписка, API й рахунок за інфраструктуру — різні статті

Підписка на клієнтський продукт і використання API можуть мати різні можливості, ліміти, правила та рахунки. Наприклад, довідка OpenAI прямо відокремлює оплату ChatGPT від оплати API Platform. Не закладайте у собівартість API нуль лише тому, що засновник має підписку на користувацький продукт; водночас не перетворюйте вартість усієї корпоративної підписки на рахунок одного проєкту без зрозумілого правила розподілу.

На повну вартість також впливають мережеві запити, пошуковий індекс, сховище, сервіс розгортання, зовнішня база даних, середовище запуску коду та виконавці CI-задач. Для GitHub Actions загальні правила залежать від типу репозиторію, плану й типу виконавця (runner): офіційна документація відрізняє безплатне використання стандартних керованих виконавців у відкритих репозиторіях і власних виконавців від можливих оплат за приватні репозиторії понад включену квоту. Перевіряйте власну сторінку записів використання, а не множте хвилини на чужу ставку.

Розібраний приклад 5: повтори, модель і перевірка змінюють вартість прийнятого результату. Порівняймо два умовні способи виконати однаковий набір із десяти задач з однаковими критеріями приймання. Нижче задані вигадані для навчального розрахунку лічильники використання й людський час: це не вимірювання реальних моделей, прогноз їхньої якості чи бенчмарк. Їх можна замінити даними власного контрольованого запуску.

Наведено стандартні короткоконтекстні ставки OpenAI, перевірені 10 жовтня 2026 року, за мільйон токенів:

Модель Звичайний вхід Кешований вхід Запис кешу Вихід
gpt-6-luna $0,10 $0,01 $0,125 $0,50
gpt-6-sol $2,00 $0,20 $2,50 $10,00

Fast-режим, Batch/Flex, довгий контекст, податки, договірні знижки та регіональні надбавки не включені. Вбудований пошук у вебі в обох сценаріях рахується окремо — $10 за 1 000 викликів; текст отриманих результатів оплачується за ставкою моделі та входить до звичайних вхідних токенів.

Складник для десяти прийнятих задач Сценарій Luna: 14 спроб Сценарій Sol: 11 спроб
Звичайний вхід 1,70 млн × $0,10 / млн = $0,17 1,20 млн × $2,00 / млн = $2,40
Кешоване читання входу 0,30 млн × $0,01 / млн = $0,003 0,20 млн × $0,20 / млн = $0,04
Записи кешу 0,20 млн × $0,125 / млн = $0,025 0,10 млн × $2,50 / млн = $0,25
Вихід 0,28 млн × $0,50 / млн = $0,14 0,15 млн × $10,00 / млн = $1,50
Модельні токени $0,338 $4,19
Вбудований пошук у вебі 30 / 1 000 × $10 = $0,30 20 / 1 000 × $10 = $0,20
Модель і платні інструменти $0,638 $4,39
Людська перевірка спроб 14 × 12 хв / 60 × $60 = $168 11 × 8 хв / 60 × $60 = $88
Виправлення десяти прийнятих задач 10 × 15 хв / 60 × $60 = $150 10 × 6 хв / 60 × $60 = $60
Резерв підтримки 10 × 3 хв / 60 × $60 = $30 10 × 3 хв / 60 × $60 = $30
Прямі витрати прикладу, без накладних $0,638 + $168 + $150 + $30 = $348,638 $4,39 + $88 + $60 + $30 = $182,39
Прийняті задачі 10 10
Прямі витрати на прийняту задачу $348,638 / 10 = $34,86 $182,39 / 10 = $18,24

В обох стовпцях десять результатів пройшли той самий критерій у межах умовного сценарію, але це задане припущення, а не доказ, що одна модель у середньому потребує менше спроб чи перевірки. Тут токени Sol дорожчі, а людський час і загальна пряма собівартість у заданому сценарії нижчі; на реальних задачах співвідношення може бути протилежним.

Ставка людської роботи $60 за годину — умовна повна внутрішня вартість. Окремий виконавець CI-задач, сховище, хостинг, платна зовнішня база й частка студійних накладних витрат не включені. Порівнюйте на репрезентативних задачах кількість результатів, що пройшли приймання, кількість спроб, людську перевірку, виправлення, затримку та рахунок; не робіть висновок за однією ціною токена.

Для поточного вибору тарифу відкрийте прайс конкретного постачальника, перевірте модель, режим, вікно контексту, кешування, інструменти та одиницю виміру. На сторінці цін Anthropic, наприклад, окремо описані токени інструментів і додаткові витрати для деяких серверних інструментів; числа одного провайдера не переносяться на іншого. OpenAI також документує, що за використання API можуть окремо тарифікувати токени, інструменти та зберігання. Тарифи змінюються, тому для кошторису збережіть дату перевірки та фактичні дані використання після запуску.

70.10. Оптимізуйте для прийнятого результату, а не найдешевшого виклику

Часто дешевше вибрати правильний контекст, прибрати повторне читання незмінних матеріалів, кешувати придатний префікс або використати скрипт для детермінованої перевірки. Але коротший запит може прибрати потрібне джерело, дешевша модель — збільшити число повторів, а паралельні агенти — подвоїти витрати на однакове дослідження. Зміни оцінюйте на репрезентативних задачах за главою 69: якість прийнятого результату, ризики, кількість виправлень, затримка, технічна ціна та людський час.

Перед запуском задайте дозволений бюджет на задачу, кількість повторних спроб, умови зупинки й поріг ескалації. Лічильник має зупинити безкінечний цикл, а агент повинен повідомити, що досягнув межі, замість непомітно створювати додаткові витрати. Не надавайте агенту права збільшувати платіжний ліміт або змінювати спосіб оплати тільки тому, що його задача перевищила бюджет.

Розрізняйте сповіщення й обмеження. У довідці OpenAI окремо описані spend alerts, що повідомляють про використання, і налаштовані hard spend limits, які можуть зупинити запити. Організаційний ліміт і ліміт проєкту можуть діяти одночасно.

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

Панель постачальника допомагає звірити використання API за моделлю й проєктом із рахунком. OpenAI окремо застерігає, що детальна статистика використання може трохи не збігатися з даними кінцевої точки Costs, рекомендованої для фінансової звірки з рахунком-фактурою. Для внутрішнього обліку прив’язуйте зовнішній рахунок до свого журналу задач, а не замінюйте рахунок оцінкою, побудованою з токенів.

Джерела до блоку D

  • OpenAI, сторінки gpt-6-luna, gpt-6-sol, API pricing і Prompt caching. Сторінки розрізняють стандартні ставки й дешевші Batch/Flex; обидва сценарії вище використовують стандартні короткоконтекстні ставки, перевірені 10.10.2026. Ціни й умови можуть змінитися.
  • OpenAI, Organization Usage and Costs API reference та Troubleshooting API usage and spend limits. Перевірено 10.10.2026; джерела розрізняють статистику використання, звірку витрат, сповіщення та жорсткі ліміти.
  • OpenAI, Managing billing for ChatGPT and the API platform. Оновлено у вересні 2026 року; перевірено 25.09.2026. Підписки ChatGPT та оплата API мають окремі білінгові системи.
  • Anthropic, Claude Platform pricing. Оновлювана документація токенних ставок, кешування, пакетної обробки та серверних інструментів; перевірено 25.09.2026. Поточні модельні ставки тут не перенесені в навчальний приклад.
  • GitHub, Billing and usage for GitHub Actions, setting up budgets і budgets and alerts. Оновлювана документація квот, бюджету й доступного блокування використання; перевірено 10.10.2026.