Инженерия с ИИ-агентами Цена работы с агентом: токены, время и внимание человека
0%

Цена работы с агентом: токены, время и внимание человека

Цена работы с агентом: токены, время и внимание человека

Предыдущие главы разбирали, что агент делает и где он врёт. Эта — про то, во что вам обходится каждая попытка это выяснить.

Тезис, вокруг которого построена глава:

У агентской работы три валюты — токены, время и внимание человека, — и они не конвертируются друг в друга. Токены докупаются мгновенно, время частично параллелится, внимание не докупается вообще. Поэтому оптимизировать надо третью статью, а считают обычно первую.

Из этого тезиса следует всё остальное: почему счёт за сессию — самая безобидная часть расходов; почему «агент сделал за пять минут то, на что ушёл бы час» ничего не говорит, пока вы не прибавили время на чтение диффа; и почему на некоторых задачах правильный ответ — не запускать агента.

Экономика 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, и совпадение стоит того, чтобы к нему отнестись серьёзно.

Правило решения

Собираем в правило, которое можно применить за пятнадцать секунд перед запуском.

Три узла в этой схеме — не украшение.

«Объяснение длиннее диффа». Самый дешёвый тест из существующих, и он отсекает большую часть неудачных запусков. Если задача формулируется дольше, чем делается, — делайте.

«Есть прогон, который поймает ошибку». Без него 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 (адрес у каждого утверждения). Смысл обоих правил экономический: не покупать одно и то же знание дважды.

Что дальше

Безопасность: секреты, права, инъекции в промпт и цепочка поставки — разберём статью расходов, которую эта глава сознательно не считала: цену инцидента. Что агент видит из ваших секретов, какие права ему реально нужны, как недоверенный текст из репозитория или из вывода инструмента превращается в команду, и почему пакет, который агент уверенно предложил установить, стоит проверить руками.

Нашли неточность? Выделите фрагмент текста — рядом появится жучок.

Нужен разбор именно вашей ситуации?

Статья описывает общий случай. Если у вас частный — можно разобрать его отдельно, платно. А если не хватает целого материала, предложите тему: её оплачивают вскладчину, и она выходит открытой для всех.

Доска запросов