# Как мы снижаем стоимость токенов без потери результата

Canonical: https://www.kt-team.ru/blog/token-cost-control-ai-process

Source: https://www.kt-team.ru/blog/token-cost-control-ai-process

28.06.2026

Токены дорожают не в момент генерации, а раньше: когда в модель кладут лишний архив, длинный лог, повторяющиеся правила, слишком широкий контекст и просят большой отчёт там, где нужен ответ в три строки. Поэтому мы снижаем стоимость не одним «промптом», а устройством рабочего процесса.

Мы сравниваем не цену миллиона токенов, а стоимость готового результата: сколько контекста, вызовов, итераций и ручной доработки нужно, чтобы получить ответ нужного качества. Эта логика продолжает наш разбор [выбора LLM под процесс и бюджет](/blog/llm-comparison-2026-choose-by-process-and-budget): модель важна, но экономику чаще решает маршрут задачи.

## Главное

- **Сначала считаем результат.** Дешёвый токен может быть дорогим, если задача проходит через три переделки. Дорогой контур может быть дешевле, если сразу даёт результат, который проходит приёмку.
- **Контекст готовится заранее.** llm-wiki и Sloy превращают рабочий след проекта в короткий справочник, а не заставляют каждый раз перечитывать архив.
- **Шум не идёт в основной контекст.** RTK фильтрует вывод команд, Caveman убирает служебную вежливость, Cavecrew возвращает из широких проверок короткие findings вместо длинного отчёта.
- **Сильный контур включается точечно.** Поиск, черновик, критика и архитектурное решение не должны оплачиваться одинаково.
- **Повторяемое переиспользуется.** Batch, кеширование и короткий формат ответа работают только там, где процесс специально под них собран.

![Стоимость результата важнее цены токена](/assets/original/token-cost-control-ai-process-01-result-cost-vs-token-price.svg)

## Где обычно сгорают токены

В расходе почти всегда виноват не один дорогой вызов, а несколько слабых решений вокруг него.

| Потеря | Как выглядит в работе | Что меняем |
| --- | --- | --- |
| Лишний вход | В запрос кладут весь документ, весь лог или всю историю переписки | Перед задачей собираем короткое досье: факты, ограничения, ссылки на источник |
| Повтор правил | Одни и те же инструкции оплачиваются заново в каждом запросе | Выносим правила в постоянный контекст, шаблон или кешируемый префикс |
| Длинный вывод | Модель пишет объяснение, когда нужен список правок | Заранее задаём формат ответа: finding, решение, следующий шаг |
| Неверный контур | Простую инвентаризацию отдаём самому дорогому режиму | Разделяем поиск, черновик, критику и финальное решение |
| Нет приёмки | Ответ выглядит хорошо, но не проходит проверку и уходит на повтор | Задаём критерии качества до запуска, а не после текста |

Экономия появляется не от одного приёма, а от маршрута: что дать модели, какой контур выбрать, сколько ответа попросить и что переиспользовать.

## Короткий контекст вместо архива

Контекст должен быть как досье для решения, а не как архив всего проекта. Если каждый запрос начинается с чтения десятков страниц, переписок и логов, команда платит за одно и то же знание снова и снова.

В llm-wiki мы держим структуру проекта так, чтобы агент сначала видел карту: README, правила, ключевые документы, решения и ссылки на исходники. Sloy расширяет этот подход на рабочую память компании: переписки, встречи, задачи, файлы и финансы превращаются в проверяемые короткие представления.

В наших продуктовых материалах для Sloy ориентир обычной операции - 2-3K токенов при подготовленном контексте. Это не универсальная гарантия: в клиентском проекте показатель считается отдельно. Важен принцип: чем раньше компания превращает сырьё в рабочий справочник, тем меньше она платит за повторное чтение.

![Контекст-фильтр: из сырья в короткое досье](/assets/original/token-cost-control-ai-process-02-context-filter-pipeline.svg)

## Команды не должны превращаться в простыню

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

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

На практике это меняет дисциплину работы. Широкий поиск должен вернуть найденные места, а не весь архив совпадений. Проверка должна вернуть статус и причину падения, а не весь журнал. Повторный запуск не делается вслепую, если первая ошибка была вызвана формой команды.

## Сжатые ответы без потери смысла

Много токенов уходит не на факты, а на служебные обвязки: приветствия, перестраховки, повтор постановки задачи, длинные переходы между очевидными шагами. Внутри рабочего процесса это не вежливость, а оплачиваемый шум.

Caveman убирает этот слой. В лёгком режиме остаются нормальные предложения, но исчезают filler, hedging и повтор очевидного. Ответ держится на фактах: что найдено, что сломано, какой риск, какой следующий шаг.

Cavecrew применяет ту же дисциплину к консилиуму. Если широкую проверку делает отдельный участник, основной контекст получает не эссе о ходе исследования, а короткие findings: путь, строка, проблема, действие. Это важно в длинных задачах: главный контур должен помнить решения, а не протокол раскопок.

![Служебный контур: меньше шума в координации](/assets/original/token-cost-control-ai-process-03-service-loop-compression.svg)

## Не каждая задача заслуживает самый дорогой контур

Дорогая модель не должна быть универсальным грузчиком для любой мелкой задачи. В рабочем процессе есть разные классы задач, и у каждого свой достаточный контур.

| Тип задачи | Достаточный контур | Почему дешевле |
| --- | --- | --- |
| Найти место в проекте | Поиск, RTK, короткая выдача совпадений | В основной контекст попадает список мест, а не весь результат поиска |
| Составить черновик | Короткое досье, формат ответа, ограничение объёма | Не оплачиваем длинное рассуждение там, где нужен первый вариант |
| Проверить риск | Отдельный критик или консилиум с короткими findings | Сильный контур получает только спорные места |
| Принять архитектурное решение | Полный контекст, доказательства, явные ограничения | Здесь нельзя экономить на понимании: ошибка дороже токенов |
| Обработать много похожих задач | Batch и стабильный формат | Несрочные операции уходят в более дешёвый асинхронный режим |

Часть задач не требует консилиума. Часть, наоборот, опасно отдавать одному исполнителю. Экономия появляется там, где этот выбор сделан заранее.

![Маршрутизация задач по сложности](/assets/original/token-cost-control-ai-process-04-task-routing-circuits.svg)

## Повторяемое не должно оплачиваться каждый раз

Кеш полезен не потому, что это технический приём, а потому что бизнес не должен платить дважды за один и тот же смысл. У крупных провайдеров уже есть тарифные механики для этого: cached input, prompt/context caching, batch API для несрочных задач. Условия меняются, поэтому перед внедрением мы проверяем прайс и ограничения на дату расчёта.

В процессе важны три правила.

- **Стабильный префикс.** Правила, роли, формат ответа и неизменяемые справочники должны идти одинаково. Плавающие даты, несортированные списки и случайные изменения ломают кеш.
- **Асинхронность там, где она допустима.** Ночная проверка документов, пакетная классификация, массовая переработка карточек и ревью архивов не требуют мгновенного ответа.
- **Короткий output.** Output часто существенно дороже input, а reasoning-токены тоже стоят денег. Если нужен verdict, не просим эссе.

## Что измеряем в проекте

Без замера «экономия токенов» быстро превращается в лозунг. Поэтому мы смотрим не только на счёт провайдера, а на путь задачи до результата.

| Метрика | Зачем нужна |
| --- | --- |
| Входной и выходной объём | Показывает, где раздувается контекст или ответ |
| Доля повторяемого контекста | Показывает потенциал кеширования |
| Доля задач, терпящих batch | Показывает, сколько работы можно вынести из интерактива |
| Success rate | Показывает, сколько ответов проходит приёмку без ручной переделки |
| Ручная доработка | Показывает скрытую стоимость «дешёвого» ответа |
| Ошибки и инциденты | Показывает, где сжатие стало опасным |

Эффект от Caveman, RTK, Cavecrew, llm-wiki, batch и cache измеряется в конкретном процессе. Один и тот же набор инструментов даст разную экономику в разработке, поддержке, юридическом анализе, контенте и аналитике.

## Где мы не режем

Сжатие не означает бедный ответ. Оно означает отсутствие служебного шума. Но есть зоны, где короткость опасна.

- **Безопасность и персональные данные.** Нужны явные ограничения, следы проверки и понятная ответственность.
- **Необратимые действия.** Перед удалением, миграцией, публикацией и платежом важнее порядок шагов, чем короткость.
- **Архитектурные решения.** Сильный вывод должен держаться на контексте, вариантах и рисках.
- **Юридически и финансово значимые тексты.** Здесь важны оговорки, источники и проверка формулировок.
- **Публичные материалы.** Короткий черновик допустим внутри, но наружу выходит текст после редакторского и фактологического прохода.

Мы режем шум, не доказательство.

## Что это даёт бизнесу

Когда стоимость одной AI-итерации падает, меняется не только счёт за токены. Команда начинает чаще проверять гипотезы, быстрее обновляет регламенты, дешевле делает ревью, спокойнее масштабирует AI на десятки пользователей.

Для KT.Team это связано с общим подходом: маленькая команда 3-7 человек, короткий TTU, слабая связанность и ответственность за результат. AI не должен превращаться в ещё один дорогой монолит. Он должен быть частью управляемого процесса: данные подготовлены, правила не повторяются, задачи маршрутизируются, результат проверяется.

**Если команда уже использует LLM в разработке, поддержке или операционных процессах, но стоимость и качество итераций непредсказуемы, KT.Team может разобрать маршрут задачи и показать, где сгорают токены: в контексте, инструментах, маршрутизации или архитектуре работы.**

## Вывод

Токены становятся дешевле только тогда, когда процесс перестаёт быть случайным. Не отправлять лишнее, не пересчитывать повторяемое, не просить большой отчёт вместо короткого решения, не гонять простые задачи через самый дорогой контур и не резать там, где ошибка дороже экономии.

Именно так стоимость AI перестаёт быть сюрпризом и становится инженерной метрикой.

## Источники

Дата проверки внешних источников: 28.06.2026.

- [Возможности LLM 2026: что выбрать под процесс и бюджет](/blog/llm-comparison-2026-choose-by-process-and-budget)
- [Sloy — рабочая память для AI-агентов](/ai-products/sloy)
- [AI-воркшопы KT.Team](/ai-workshops)
- [OpenAI API: Pricing](https://developers.openai.com/api/docs/pricing)
- [OpenAI API: Batch API](https://developers.openai.com/api/docs/guides/batch)
- [OpenAI API: Prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching)
- [Claude Platform: Pricing](https://platform.claude.com/docs/en/about-claude/pricing)
- [Claude Platform: Batch processing](https://platform.claude.com/docs/en/build-with-claude/batch-processing)
- [Claude Platform: Prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)
- [Gemini API: Pricing](https://ai.google.dev/gemini-api/docs/pricing)
- [Gemini API: Batch API](https://ai.google.dev/gemini-api/docs/batch-api)
- [Gemini API: Context caching](https://ai.google.dev/gemini-api/docs/caching)