Цена работы с агентом: токены, время и внимание человека
Предыдущие главы разбирали, что агент делает и где он врёт. Эта — про то, во что вам обходится каждая попытка это выяснить.
Тезис, вокруг которого построена глава:
У агентской работы три валюты — токены, время и внимание человека, — и они не конвертируются друг в друга. Токены докупаются мгновенно, время частично параллелится, внимание не докупается вообще. Поэтому оптимизировать надо третью статью, а считают обычно первую.
Из этого тезиса следует всё остальное: почему счёт за сессию — самая безобидная часть расходов; почему «агент сделал за пять минут то, на что ушёл бы час» ничего не говорит, пока вы не прибавили время на чтение диффа; и почему на некоторых задачах правильный ответ — не запускать агента.
Экономика LLM-продукта вообще (батчи, эмбеддинги, выбор модели под нагрузку) разобрана в главе «Продакшн и стоимость» трека ИИ-инженерии. Здесь другой предмет: цена одной инженерной задачи, решаемой агентом в вашем репозитории, включая ту её часть, которая не попадает ни в какой счёт.
Три валюты
Разложим расходы по статьям — и сразу отметим, кто и когда за них платит.
| Валюта | Из чего складывается | Кто платит | Можно ли докупить |
|---|---|---|---|
| Токены | Вход (история, схемы инструментов, контракт), выход (ответы, рассуждение), запись и чтение кэша | Компания, по счёту провайдера или подписке | Да, мгновенно |
| Время | Латентность хода, ожидание прогонов, лимиты провайдера, повторные попытки | Календарь задачи | Частично: параллелится, если есть чем занять себя |
| Внимание | Формулировка задачи, чтение диффа, свой прогон, переделка, переключение контекста | Лично вы и ревьюер | Нет |
Три замечания, которые делают эту таблицу неудобной.
Первое: статьи не пропорциональны друг другу. Сессия, которая сожгла вдвое больше токенов, не обязательно отняла вдвое больше внимания — она могла быть длинной и скучной, а могла быть короткой и подсунуть тонкую ошибку. Обратное тоже верно: самая дешёвая в токенах правка может стоить часа разбирательства.
Второе: две из трёх статей невидимы. Провайдер показывает токены. Никто не показывает, что вы потратили сорок минут на чтение диффа, из которого приняли треть.
Третье: удешевление токена не снижает расход. Это парадокс Джевонса в чистом виде: чем дешевле единица ресурса, тем больше её потребляют. Когда токен дешевеет вдвое, сессии не становятся вдвое дешевле — они становятся вдвое длиннее. А узкое место переезжает туда, где докупить нельзя.
Что именно оплачивается на одном ходу
Прежде чем считать, надо понять, за что выставляется счёт. Разберём один ход цикла — механику самого цикла мы разбирали в главе «Модель исполнения».
Ключевая строчка — на седьмом шаге. API не хранит вашу сессию. Каждый ход — это новый HTTP-запрос, в котором весь накопленный транскрипт отправляется заново и заново оплачивается как входные токены. Это не особенность конкретного инструмента, это устройство протокола.
Откуда берётся квадрат
Пусть каждый ход добавляет к транскрипту примерно c токенов (реплика, вывод инструмента, ответ модели). Тогда на ходу номер k входная часть запроса — это примерно c·k, а суммарно за N ходов:
S(N) = c·1 + c·2 + ... + c·N = c · N(N+1)/2 = O(N²)
Выходные токены растут линейно — их примерно d на ход, итого d·N = O(N). Но выходной токен у большинства провайдеров стоит кратно дороже входного (конкретный множитель смотрите в прайс-листе своего — он разный у разных моделей и меняется), так что на коротких сессиях доминирует линейное слагаемое, а на длинных — квадратичное. Точка перелома у каждого своя; важно, что она есть.
Практическое следствие, ради которого всё это считалось:
Двадцатиходовая сессия стоит не вдвое дороже десятиходовой, а примерно вчетверо. Две отдельные сессии по десять ходов, решающие те же две задачи, дешевле одной двадцатиходовой — и по токенам, и по качеству, потому что во второй сессии окно не забито мусором из первой.
Оговорки, без которых модель выше — враньё:
- Ходы не одинаковы. Один
grepпо репозиторию добавляет больше, чем десять реплик. Реальный график ступенчатый, а не гладкий. - Кэш префикса меняет коэффициент, а не степень. Чтение из кэша стоит порядка десятой части обычной цены входного токена, запись — примерно на четверть дороже обычной при пятиминутном сроке жизни и вдвое дороже при часовом (документация Anthropic по кэшированию; у других провайдеров условия свои). То есть
S(N)остаётся квадратичной, просто с константой на порядок меньше. Раскладку префикса и способы случайно сломать себе кэш мы разбирали в главе про контекст. - Компакция обнуляет накопление, но не бесплатно. Сжатие истории — это отдельный вызов модели, который читает всё окно и пишет резюме; плюс безвозвратная потеря части фактов. Дешёвая по деньгам, дорогая по качеству операция.
- Схемы инструментов едут в каждый запрос, а рассуждение оплачивается как выход. Подключённый «на всякий случай» MCP-сервер с сорока методами — постоянная надбавка к каждому ходу всей сессии (подробно — в главе про инструменты и MCP); а токены расширенного размышления попадают в счёт, даже когда вы их не видите.
Как посчитать свою цену, а не чужую
Числа из статей и постов бесполезны: они получены на чужом репозитории, чужой моделью, в чужой версии инструмента. Единственная полезная цифра — ваша.
Поля usage — единственный честный источник
Ответ API содержит блок usage. У Anthropic поля называются так (у других провайдеров имена другие, суть та же):
input_tokens— входные токены, оплаченные по полной ставке;output_tokens— сгенерированные токены, включая рассуждение;cache_creation_input_tokens— записано в кэш;cache_read_input_tokens— прочитано из кэша.
Тут есть ловушка, на которой спотыкаются при первом же разборе: input_tokens — это только некэшированный остаток, а не размер промпта. Полный размер запроса — сумма трёх полей:
prompt_size = input_tokens + cache_creation_input_tokens + cache_read_input_tokens
Если после часа работы агента input_tokens показывает четыре тысячи, это не значит, что окно пустое. Это значит, что остальное пришло из кэша.
И отдельно: не считайте токены Claude чужим токенизатором. tiktoken — токенизатор OpenAI; на текстах он занижает счёт Claude заметно, на коде и не-английском — сильнее. Для оценки перед запросом есть отдельная ручка подсчёта (документация); у других провайдеров свои.
Скрипт: стоимость сессии из журнала
Если ваш харнесс умеет писать журнал ходов (или вы работаете через API напрямую), стоимость сессии считается за один проход. Никаких цен в коде — они живут в вашем файле, который вы обновляете по прайс-листу провайдера.
"""Стоимость сессии по журналу ходов в формате JSON Lines.
Строка журнала: {"model": "...", "usage": {"input_tokens": 0, ...}}
Цены за миллион токенов — в отдельном файле, который вы обновляете по
прайс-листу провайдера. В коде статьи цен нет намеренно: устаревшее
число хуже отсутствующего.
prices.json: {"модель-A": {"in": "0", "out": "0",
"cache_write": "0", "cache_read": "0"}}
Сложность: O(n) по числу ходов, O(1) по памяти сверх словаря цен.
"""
import json
import sys
from decimal import Decimal
MILLION = Decimal(1_000_000)
def turn_cost(usage: dict, price: dict[str, Decimal]) -> Decimal:
"""Стоимость одного хода. Ключи usage — как их называет провайдер."""
return (
Decimal(usage.get("input_tokens", 0)) * price["in"]
+ Decimal(usage.get("output_tokens", 0)) * price["out"]
+ Decimal(usage.get("cache_creation_input_tokens", 0)) * price["cache_write"]
+ Decimal(usage.get("cache_read_input_tokens", 0)) * price["cache_read"]
) / MILLION
def session_report(log_path: str, prices_path: str) -> None:
with open(prices_path, encoding="utf-8") as f:
prices = {m: {k: Decimal(v) for k, v in row.items()}
for m, row in json.load(f).items()}
total, turns, prompt_tokens, cached = Decimal(0), 0, 0, 0
with open(log_path, encoding="utf-8") as f:
for line in filter(str.strip, f):
rec = json.loads(line)
usage, model = rec["usage"], rec["model"]
# Молчаливо пропустить незнакомую модель — способ получить
# красивый и неверный отчёт. Лучше упасть.
total += turn_cost(usage, prices[model])
turns += 1
# Полный размер промпта — сумма трёх полей, а не input_tokens
prompt_tokens += (usage.get("input_tokens", 0)
+ usage.get("cache_creation_input_tokens", 0)
+ usage.get("cache_read_input_tokens", 0))
cached += usage.get("cache_read_input_tokens", 0)
print(f"ходов: {turns}")
print(f"средний размер промпта: {prompt_tokens // max(turns, 1)} токенов")
print(f"доля из кэша: {cached / max(prompt_tokens, 1):.0%}")
print(f"итого: {total:.4f}")
if __name__ == "__main__":
session_report(sys.argv[1], sys.argv[2])
Три числа из этого отчёта стоят того, чтобы смотреть на них регулярно.
Средний размер промпта показывает, растёт ли у вас окно бесконтрольно. Если он к концу сессии втрое больше, чем в начале, — это тот самый квадрат.
Доля из кэша — индикатор, ломаете ли вы себе префикс. Ноль при повторяющихся запросах означает, что где-то в начале промпта меняется байт: подставленное текущее время, переставленные ключи в JSON, изменённый набор инструментов.
Итог нужен не сам по себе, а для сравнения с ценой часа инженера. Именно это сравнение обычно и оказывается неприятным сюрпризом — но не в ту сторону, в которую ждут. Об этом ниже.
Быстрый вариант того же без Python, если журнал уже в JSON Lines:
# Сумма токенов по сессии: вход, выход, чтение кэша
jq -s '{
turns: length,
input: (map(.usage.input_tokens // 0) | add),
output: (map(.usage.output_tokens // 0) | add),
cached: (map(.usage.cache_read_input_tokens // 0) | add)
}' session.jsonl
Подписка вместо счёта: у вас может не быть денежной статьи вовсе
Значительная часть инженеров работает с агентом не через API с поминутной тарификацией, а по подписке. Тогда предельная стоимость токена для вас нулевая — до момента, когда упирается лимит.
Это меняет картину, и надо назвать изменения честно:
- Денежной обратной связи нет. Ничто не мешает сжечь окно на задаче, которую надо было сделать руками. Дисциплину приходится держать самому.
- Узкое место — лимиты. Они приходят не тогда, когда удобно, а в середине сложной сессии, и стоят не денег, а времени и потерянного контекста. Числа лимитов зависят от плана и меняются; смотрите документацию своего провайдера.
- Для команды деньги всё равно есть. Подписка на человека умножается на количество людей, и на уровне бюджета вопрос «а что мы за это получили» задают ровно так же.
Практический вывод: если у вас подписка, считайте не деньги, а ходы и размер окна. Это те же самые единицы, только без множителя.
Вторая валюта: время
Время делится на две части, которые ведут себя по-разному.
Латентность хода. От секунд на коротком ответе до минут на сложном запросе с глубоким рассуждением — на самых крупных моделях один запрос долгой агентской задачи может идти много минут. Это не патология, это заявленный режим работы. Планировать интерфейс и ожидания надо под него.
Ожидание себя. Прогон тестов, сборка, поднятие окружения. Агент здесь ничего не ускоряет — он ждёт ровно столько же, сколько ждали бы вы.
Ключевой вопрос про время всего один: можете ли вы в это время делать что-то ещё? Если да — время почти бесплатно; агент работает, вы читаете предыдущий дифф или пишете другой код. Если нет — вы сидите и смотрите на курсор, и это чистая потеря, которую не видно ни в каком счёте.
Отсюда единственный настоящий рычаг по времени: асинхронность. Задача, которую можно поставить и уйти, стоит принципиально дешевле по времени, чем задача, за которой надо следить. Что делает задачу асинхронной:
- сформулированный до запуска критерий готовности (см. «Промпт как спецификация»);
- прогон, который сам скажет «сломано», без вашей интерпретации (см. «Проверяемость»);
- ограниченные права, при которых уход не превращается в риск (см. «Безопасность»);
- стоп-правило: агент обязан остановиться и доложить, а не гадать (см. «Планирование»).
Обратная сторона: асинхронность имеет свою цену. Пока вы занимались другим, агент прошёл двадцать ходов, и теперь вам надо восстановить контекст по его отчёту — а отчёт, как мы знаем из главы «Где агенты врут», не свидетельство.
И отдельный пункт для неинтерактивной работы: если задача терпит часы (прогон по репозиторию, массовая генерация тестов, разметка), у некоторых провайдеров есть пакетный режим за половину обычной цены — у Anthropic это Message Batches. Для интерактивной работы в редакторе он бесполезен, для фоновых задач — самая простая экономия из существующих.
Третья валюта: внимание
Здесь начинается настоящий счёт.
Почему чтение дороже написания
Когда вы пишете код сами, понимание строится по ходу: к моменту, когда функция дописана, вы знаете, почему каждая строка там, где она есть. Когда код написал агент, понимания нет — его надо построить заново, читая результат. Это работа другого рода и другой скорости.
Разница усугубляется тремя свойствами агентского кода, разобранными в главе «Ревью кода от агента»:
- он правдоподобен, то есть выглядит как правильный, и защитная реакция «тут что-то странно» не срабатывает;
- он объёмен: агент не устаёт и добавляет обработку случаев, которых не бывает, вместе с абстракциями, которые не понадобятся;
- он однороден: нет авторских странностей, за которые цепляется глаз, — а значит нет и естественных точек внимания.
Практическое следствие, которое стоит принять до, а не после: дифф на четыреста строк от агента читается дольше, чем такой же дифф от коллеги, потому что у коллеги можно спросить «почему так», а у агента ответ будет сгенерирован задним числом и правдоподобен независимо от истины.
Переключение контекста
Цикл «сформулировал — подождал — прочитал — проверил» состоит из переключений, и каждое стоит отдельно. Это не специфика ИИ: работа Глории Марк и соавторов The Cost of Interrupted Work: More Speed and Stress (CHI 2008) показывает, что прерванную задачу люди действительно доделывают быстрее — но ценой большего стресса и нагрузки. Агент производит прерывания промышленными темпами: каждый ход — потенциальная точка выхода из потока. Отсюда неочевидная рекомендация: одна длинная агентская задача, за которой вы не следите, дешевле по вниманию, чем десять коротких, за каждой из которых надо присмотреть — даже если по токенам всё наоборот.
Налог на проверку
Самая дорогая и самая забываемая статья. Она состоит из:
- прогона, который делаете вы, а не агент (утверждение агента о поведении кода не является свидетельством — сквозная мысль трека);
- разбирательства, когда прогон не сошёлся с отчётом;
- переделки, которая наступает с некоторой вероятностью и стоит почти столько же, сколько первая попытка, — потому что начинается с «понять, что именно не так в чужом коде».
Вот как эти статьи складываются на двух разных по масштабу задачах.
Пропорции на картинке условны — это форма зависимости, а не измерение. Но форма важнее чисел: на мелкой задаче агент проигрывает всегда, потому что нижние два блока (понять задачу, прочитать результат) не сокращаются, а верхний (написать) и так был маленьким. Выигрыш появляется там, где блок «написать руками» большой, а блок «прочитать дифф» растёт медленнее его.
Модель безубыточности
Соберём это в формулу, которой можно пользоваться. Не для точного расчёта — для проверки, не забыли ли вы слагаемое.
Время на задачу руками:
T_рук = t_понять + t_написать + t_прогнать
Время на ту же задачу через агента:
T_аг = t_понять + t_сформулировать + w·t_ждать + t_прочитать + t_прогнать + p·t_переделать
Где w — доля ожидания, которую вы не можете занять другой работой (от 0 при настоящей асинхронности до 1, если вы смотрите в экран), а p — вероятность того, что результат придётся переделывать или доводить.
Агент выгоден, когда T_аг < T_рук, то есть когда:
t_написать > t_сформулировать + w·t_ждать + t_прочитать + p·t_переделать
Слева — единственное, что агент действительно экономит. Справа — четыре слагаемых, из которых в обсуждениях обычно фигурирует ноль.
from dataclasses import dataclass
@dataclass(frozen=True)
class Task:
"""Оценки в минутах. Все числа — ваши замеры, а не чужие."""
understand: float # понять задачу — платится в обоих случаях
write_by_hand: float # написать руками
specify: float # сформулировать для агента
wait: float # ждать агента
blocked: float # доля ожидания, которую нечем занять (0..1)
read_diff: float # прочитать и понять дифф
run: float # свой прогон — платится в обоих случаях
rework: float # переделка, если результат не подошёл
p_rework: float # вероятность переделки (0..1)
def by_hand(t: Task) -> float:
return t.understand + t.write_by_hand + t.run
def with_agent(t: Task) -> float:
return (
t.understand
+ t.specify
+ t.blocked * t.wait
+ t.read_diff
+ t.run
+ t.p_rework * t.rework
)
def verdict(t: Task) -> str:
a, h = with_agent(t), by_hand(t)
if a < h * 0.8:
return f"агент: {h - a:.0f} мин экономии — запас есть"
if a < h:
return f"агент: {h - a:.0f} мин экономии — в пределах погрешности оценки"
return f"руками: агент дороже на {a - h:.0f} мин"
Две вещи, ради которых эта модель написана.
Первая: p решает всё. Это единственный параметр, который вы не можете оценить заранее и который целиком определяет ответ. Он зависит не от модели, а от вашего репозитория: есть ли тесты, покрыт ли ими этот участок, поймает ли прогон ошибку сразу или через неделю на продакшне. Отсюда прямая связь с главой «Проверяемость»: инвестиция в тесты — это инвестиция в снижение p, то есть в удешевление всей агентской работы. Не в качество кода, а именно в стоимость.
Вторая: сравнивайте честно. Частая ошибка — сравнивать t_написать с t_сформулировать и объявлять победу. Это сравнение «час против пяти минут», в котором просто не учтено всё остальное.
Про измеренное расхождение между ощущением и фактом уже говорилось в обзоре трека, но повторю, потому что оно ровно про эту главу: в рандомизированном эксперименте METR (Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025) 16 опытных контрибьюторов на 246 реальных задачах в собственных зрелых репозиториях с ИИ-инструментами работали на 19% дольше — и при этом были уверены, что ускорились примерно на 20%.
У этого результата есть важные ограничения, и честно их назвать: выборка маленькая, репозитории — крупные и хорошо знакомые участникам (то есть худший случай для агента: контекст уже в голове у человека, а не в файлах), инструменты — начала 2025 года. Переносить «19%» на вашу ситуацию нельзя. Переносить методологический вывод — можно и нужно: собственное ощущение ускорения не является измерением.
Второй ориентир с другой стороны: отчёт DORA State of DevOps 2024 на опросных данных фиксирует, что рост внедрения ИИ связан с ростом индивидуально воспринимаемой продуктивности — и одновременно с ухудшением командных метрик поставки. Это корреляции в опросе, а не эксперимент, и причинность из них не следует. Но направление совпадает с METR, и совпадение стоит того, чтобы к нему отнестись серьёзно.
Правило решения
Собираем в правило, которое можно применить за пятнадцать секунд перед запуском.
длиннее ожидаемого диффа?"} B -- "да" --> R1["Делать руками.
Это арифметика, не поражение"] B -- "нет" --> C{"Есть прогон, который
поймает ошибку?"} C -- "нет" --> D{"Можно сначала
написать прогон?"} D -- "да" --> E["Сначала тест — руками или агентом,
но с вашим ревью"] D -- "нет" --> R2["Руками либо мелкими шагами
с ручной проверкой каждого"] C -- "да" --> F{"Можно уйти,
пока агент работает?"} F -- "нет" --> G{"Работы всё ещё
заметно много?"} G -- "нет" --> R1 G -- "да" --> H["Агент, но короткой сессией
и с промежуточной проверкой"] F -- "да" --> H E --> C H --> I{"Два провала подряд
на одном месте?"} I -- "да" --> R3["Стоп. Дальше дешевле руками:
агент уже наврал про причину"] I -- "нет" --> J["Ревью диффа и свой прогон"]
Три узла в этой схеме — не украшение.
«Объяснение длиннее диффа». Самый дешёвый тест из существующих, и он отсекает большую часть неудачных запусков. Если задача формулируется дольше, чем делается, — делайте.
«Есть прогон, который поймает ошибку». Без него p·t_переделать неограниченно, и модель безубыточности не имеет решения: вы просто не узнаете, во сколько вам это обошлось, до самого инцидента.
«Два провала подряд». Жёсткое стоп-правило. После второй неудачной попытки на одном и том же месте агент уже построил в контексте неверную картину причины и будет достраивать её дальше — каждый следующий ход дороже и вреднее предыдущего. Это же правило стоит записать в контракт проекта, чтобы агент останавливался сам.
Жизненный цикл бюджета одной задачи
Полезно видеть, где именно расходы возникают повторно.
Обратите внимание на петлю Переделка → Формулировка. Каждый её оборот заново оплачивает всё: токены новой сессии, время ожидания и — главное — ваше внимание, уже потраченное на чтение предыдущего диффа. Именно поэтому уточнять критерий готовности заранее дешевле, чем два раза читать неверный результат.
Рычаги: что действительно снижает цену
Не все способы сэкономить равны по отдаче.
Разберём то, что попало в верхнюю половину.
Резать задачу на короткие сессии. Самый дешёвый и самый недооценённый рычаг: он бьёт по квадрату напрямую. Границу проводите по задачам, а не по времени: закончился связный кусок работы — новая сессия.
Стоп-правило и гигиена инструментов. Первое записывается одной строкой в контракт и экономит самые дорогие ходы — те, что идут после того, как агент уже ошибся в диагнозе. Второе ещё проще: каждая схема едет в модель каждый ход всей сессии, поэтому отключённый MCP-сервер, который сегодня не нужен, — чистая экономия без единого недостатка.
Контракт проекта. Команды сборки и прогона, запретные каталоги, требования к оформлению — записанные один раз, они не пересказываются в каждой сессии и не выдумываются агентом заново. Это одновременно экономия токенов и снижение p.
Тесты на затрагиваемый участок. Самый дорогой рычаг по внедрению и самый сильный по эффекту, потому что он единственный бьёт по p·t_переделать — слагаемому, которое доминирует в неудачных случаях.
Записывать опровергнутые гипотезы. Формулировка из нашего пакета шаблонов products/workbench/templates/memory/: каждый раз, когда утверждали X, а наблюдение показало не-X, это повод для отдельной заметки с адресом источника. Экономическое обоснование простое: опровержение, которое не записано, будет куплено ещё раз — той же сессией через десять ходов после компакции, вами через неделю, коллегой через месяц. Правило MEM-11 там сформулировано вместе с наблюдаемым нарушением, то есть его выполнение можно проверить в диффе, а не на слово. Подробнее — в главе «Память агента».
Модель под ярус задачи. Здесь нужна честная оговорка. Идея «простое — дешёвой моделью, сложное — дорогой» звучит разумно и иногда работает. Но экономия здесь измеряется в токенах, а перерасход — во внимании: дешёвая модель, которая ошиблась и потребовала переделки, обошлась дороже дорогой, которая не ошиблась. Плюс переключение модели посреди сессии сбрасывает кэш префикса. Считайте по полной формуле, а не по прайс-листу. Как оценивать модели на своей задаче — в главе «Оценка и бенчмарки».
Чего не стоит оптимизировать
Символы в промпте. Сокращать формулировку задачи ради экономии двухсот токенов — это оптимизация статьи расходов, которая и так не видна на фоне вывода первого же grep. А недосказанность в формулировке уходит прямо в p. Про то, почему подробная спецификация окупается, — глава «Промпт как спецификация».
Прогоны и ревью. «Не будем гонять весь набор, чтобы сэкономить время» — самый дорогой способ сэкономить: прогон стоит минуты, необнаруженная ошибка — дни. «Агент написал, что тесты прошли, посмотрю по диагонали» — та же статья с большим множителем.
Длина сессии ради кэша. Соблазн понятный: длинная сессия дешевле по кэшу, чем несколько коротких, — префикс уже прогрет. Но платите вы за это местом в окне, деградацией качества на длинном контексте и своим вниманием на разбор того, что там накопилось. Экономия в дешёвой валюте за счёт дорогой — и оправдывают её обычно ощущением скорости, которое приятно и измерением не является (см. METR выше).
Цена на уровне команды
Одна деталь, которая на индивидуальном уровне не видна, а на командном определяет всё.
Агент экстернализует издержки. Автор экономит время на написании кода. Ревьюер тратит время на чтение диффа, который стал длиннее и однороднее. Экономия достаётся одному, расход раскладывается на всех. Если в команде не проговорено, что автор отвечает за агентский дифф так же, как за свой, — а лучше строже, потому что он его не писал, — то суммарно команда теряет, притом что каждый отдельный человек уверен, что выиграл.
Что с этим делать практически, разбирает глава «Агенты в командной работе». Здесь — два пункта с прямым ценовым обоснованием. Размер PR — ограничение, а не пожелание: агент способен произвести дифф, который никто не прочитает целиком, а непрочитанный дифф не экономия, а отложенный расход с процентами. И мерить надо на выходе, а не на входе: строки кода в единицу времени с агентом растут почти гарантированно, время от задачи до работающего изменения в продакшне — не обязательно.
Типичные ошибки
Считать только счёт провайдера. Это самая маленькая и самая видимая статья. Полная цена — в трёх валютах.
Сравнивать t_написать с t_сформулировать. Победа в этом сравнении ничего не значит: остальные четыре слагаемых никуда не делись. Хуже всего забывается p·t_переделать — слагаемое, которое чаще всего решает исход и которое нельзя оценить до запуска.
Держать одну бесконечную сессию и подключать всё, что подключается. Квадрат по токенам, деградация по качеству, каша в окне — и схемы инструментов, едущие в модель каждый ход, а не однажды.
Спорить с агентом три хода подряд. Дороже, чем открыть файл и сделать самому. После второй неудачи — стоп.
Считать, что подписка означает отсутствие цены. Она означает отсутствие денежной статьи. Время и внимание тарифицируются по-прежнему.
Оптимизировать токены за счёт проверок. Единственная оптимизация в этой главе, которая гарантированно приводит к убытку.
Мини-итог
- Валют три: токены, время, внимание. Первая докупается, вторая частично параллелится, третья не докупается вообще.
- Входные токены оплачиваются на каждом ходу заново, и суммарно растут как
O(N²)по числу ходов. Кэш меняет константу, а не степень; компакция обнуляет накопление ценой потери фактов. input_tokens— не размер промпта, а некэшированный остаток. Полный размер — сумма трёх полейusage. Считайте токены токенизатором своего провайдера, а не чужим.- Правило безубыточности: агент выгоден, когда
t_написать > t_сформулировать + w·t_ждать + t_прочитать + p·t_переделать. В обсуждениях справа обычно не пишут ничего. p— вероятность переделки — зависит от вашего репозитория, а не от модели. Тесты снижаютp, то есть удешевляют агентскую работу как таковую.- Если объяснение задачи длиннее ожидаемого диффа — делайте руками. Это арифметика, а не поражение.
- Два провала подряд на одном месте — стоп. Дальше каждый ход дороже и вреднее.
- Ощущение ускорения не является измерением: в эксперименте METR участники замедлились на 19% и были уверены в обратном.
- Агент экстернализует издержки на ревьюера: экономия у одного, расход у всех. На уровне команды это надо проговаривать явно.
Источники
- Anthropic. Pricing — актуальные цены за миллион токенов; числа меняются, сверяйтесь в день работы.
- Anthropic. Prompt caching — множители чтения и записи кэша, минимальный кэшируемый префикс, поля
usage. - Anthropic. Token counting — почему считать токены надо токенизатором провайдера.
- Anthropic. Message Batches — пакетный режим за половину цены для задач, которые терпят часы.
- Anthropic. Rate limits — лимиты как реальное ограничение при работе по подписке.
- Anthropic. Building Effective Agents — про то, когда агентная петля оправдана, а когда достаточно простой цепочки.
- METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — рандомизированный эксперимент: замедление на 19% при уверенности в ускорении.
- Peng et al. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot — противоположный результат на синтетической задаче с нуля; полезен именно как контраст.
- Google Cloud / DORA. Accelerate State of DevOps Report 2024 — воспринимаемая продуктивность против командных метрик поставки.
- Mark, Gudith, Klocke. The Cost of Interrupted Work: More Speed and Stress (CHI 2008) — цена переключения контекста, измеренная задолго до агентов.
- Jevons paradox — почему удешевление ресурса увеличивает его потребление.
products/workbench/templates/memory/— наш пакет правил:MEMORY-PROTOCOL.md(MEM-11— опровергнутое убеждение как обязательная запись),REASONING-DISCIPLINE.md(адрес у каждого утверждения). Смысл обоих правил экономический: не покупать одно и то же знание дважды.
Что дальше
Безопасность: секреты, права, инъекции в промпт и цепочка поставки — разберём статью расходов, которую эта глава сознательно не считала: цену инцидента. Что агент видит из ваших секретов, какие права ему реально нужны, как недоверенный текст из репозитория или из вывода инструмента превращается в команду, и почему пакет, который агент уверенно предложил установить, стоит проверить руками.