DeepSeek Harness Compaction: как снизить расходы

По данным официального ответа DeepSeek API, prompt_tokens складывается из prompt_cache_hit_tokens и prompt_cache_miss_tokens, а total_tokens включает ещё и completion_tokens — это уже три разных показателя, которые нельзя заменять одним процентом кэширования. Описание полей usage в DeepSeek API

Симптом: кэш якобы хорошо работает, но длинная сессия DeepSeek Harness всё равно становится медленнее и дороже.
Быстрое решение: сначала разложите расход Token по истории, инструментам, системным инструкциям и ответам модели; затем применяйте Compaction, обрезку результатов или новую сессию — только после сохранения проверяемого состояния задачи.

SECTION 01Кому нужен этот разбор

Материал пригодится вам, если длинная сессия продолжает расти после каждого цикла Agent, ответы начинают задерживаться, а расходы по DeepSeek API сложно объяснить интерфейсом Harness.

Он также рассчитан на команды, которые оптимизируют постоянных Agent, и на технических руководителей, сравнивающих стоимость модели, рабочего окружения, памяти, хранения логов и ручного восстановления.

Последнее обновление: 18 августа 2026 года. Данные о полях usage, кэшировании и тарифной логике сверены с текущими материалами DeepSeek API; поведение Compaction относится к актуальной ветке Harness и может меняться вместе с предварительными обновлениями.

SECTION 02Источник роста Token

Длинная сессия не отправляет модели только ваше новое сообщение. В каждом следующем запросе Harness может повторно передавать несколько слоёв контекста:

• системные инструкции;
• историю диалога;
• предыдущие ответы модели;
• вызовы инструментов;
• результаты чтения файлов, поиска, сборки и тестов;
• текущую задачу и ограничения пользователя;
• новый запрос;
• очередной ответ модели.

Поэтому расход Token — не «размер последнего сообщения», а сумма фактически обработанного входа и выхода на протяжении множества запросов. В официальной схеме DeepSeek API поле prompt_tokens равно сумме попаданий и промахов кэша, а total_tokens равняется входным и выходным Token вместе. Проверяйте эти поля в каждом ответе, а не пытайтесь восстановить расходы по длине текста в терминале. Официальное описание Token и Token Usage и схема ответа Chat Completion

Для диагностики сохраните по каждой операции как минимум:

• идентификатор сессии;
• модель;
• время запроса;
• prompt_tokens;
• prompt_cache_hit_tokens;
• prompt_cache_miss_tokens;
• completion_tokens;
• total_tokens;
• тип последнего инструмента;
• событие Compaction или ручного сокращения;
• результат проверки задачи.

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

Почему кэширование может быть высоким, а Token всё равно много? Потому что высокий процент попаданий показывает долю совпавшего префикса, а не абсолютный размер запроса и не сумму всей сессии. Официальная документация описывает кэш как механизм повторного использования совпадающих префиксов; непостоянные фрагменты и изменившаяся середина запроса не становятся автоматически дешёвыми. Руководство DeepSeek по Context Caching

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

SECTION 03Инструменты и раздувание контекста

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

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

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

Если инструмент вернул лог на несколько экранов, Compaction не должен быть первым ответом. Сначала сохраните внешний артефакт: файл лога, отчёт тестов, diff или ссылку на конкретный результат. В контекст передайте только:

• команду;
• код завершения;
• ключевые строки ошибки;
• затронутые файлы;
• путь к полному артефакту;
• вывод, необходимый для следующего решения.

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

Как уменьшить объём ответа инструмента, если он слишком длинный? Ограничьте область операции до текущего файла или каталога, добавьте фильтр по уровню ошибки, передавайте последние события вместо всего журнала и сохраняйте полный результат как внешний артефакт. Для поиска используйте несколько узких запросов вместо одного широкого, который возвращает весь репозиторий.

Практическая схема выглядит так:

1. Сначала выполните инструмент с ограниченным диапазоном.
2. Если результат неполный, расширьте только нужную область.
3. Полный вывод запишите в файл или журнал.
4. В историю Harness внесите краткую выжимку и путь к артефакту.
5. Перед Compaction проверьте, что Agent сможет повторно открыть нужное доказательство.

SECTION 04Кэш и расчёт расходов

Текущая страница тарифов DeepSeek показывает отдельные ставки для входных Token при попадании в кэш, промахе кэша и выходных Token. В опубликованной на момент проверки таблице для актуальных моделей указаны разные цены за один миллион входных Token при cache hit и cache miss, а также отдельная ставка за выход. Точные суммы меняются, поэтому их следует брать непосредственно со страницы Models & Pricing, а не из старого примера или снимка экрана.

Формула для одной операции:

Стоимость запроса =
(prompt_cache_hit_tokens × цена cache hit)
+ (prompt_cache_miss_tokens × цена cache miss)
+ (completion_tokens × цена output)

Для сессии формулу нужно применять к каждому ответу API, после чего суммировать результаты:

Стоимость сессии =
Σ стоимость каждого запроса
+ стоимость повторных попыток
+ стоимость вызовов модели для сводки

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

В Harness, интерфейсе API и стороннем парсере могут отображаться разные агрегаты. Интерфейс может показывать текущую сессию, API возвращает показатели конкретного запроса, а парсер иногда суммирует повторные попытки или не учитывает потоковый финальный пакет с usage. При потоковой передаче включайте получение итогового блока usage, если клиент это поддерживает. Документация DeepSeek по потоковому ответу и usage

SECTION 05Compaction и потеря состояния

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

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

Перед сжатием сформируйте контрольную карточку:

• конечная цель задачи;
• список уже изменённых файлов;
• ожидаемый следующий шаг;
• открытые ошибки;
• проваленные тесты;
• ограничения пользователя;
• команды проверки;
• известные решения, которые нельзя повторять.

После Compaction задайте Agent ту же контрольную последовательность, которая использовалась до сжатия. Не спрашивайте только «что мы делали?». Попросите назвать изменённые файлы, текущую ошибку, следующий шаг и команду верификации. Затем продолжите задачу реальным действием — например, исправлением теста или повторным запуском проверки. Если Agent уверенно описывает общий контекст, но ошибается в одном из контрольных пунктов, состояние нельзя считать восстановленным.

Может ли Compaction потерять важный контекст кодовой задачи? Да, если критические детали существовали только в сообщениях и не были закреплены в файле состояния, внешнем отчёте или проверяемом плане. Риск выше, когда история содержит несколько похожих задач, отменённые решения, длинные логи и противоречивые инструкции.

Преимущества Compaction:

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

Ограничения:

• сжатие может добавить отдельный вызов модели;
• краткая сводка способна потерять исключения и отрицательные результаты;
• новый запрос после сжатия может иметь другой кэшируемый префикс;
• ошибка в резюме переносится дальше и становится менее заметной;
• проверка качества занимает время и должна учитываться как операционная стоимость.

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

SECTION 06Сжатие или новая сессия

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

Создавайте новую сессию, если:

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

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

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

Используйте чек-лист перед выбором:

• [ ] Цель задачи сформулирована одной фразой и не менялась.
• [ ] Рабочая директория и границы проекта остались прежними.
• [ ] Все изменённые файлы перечислены.
• [ ] Проваленные тесты и нерешённые ошибки сохранены.
• [ ] Полные логи доступны как внешние артефакты.
• [ ] Ограничения пользователя записаны отдельно.
• [ ] После Compaction можно повторить контрольные вопросы.
• [ ] Новая сессия не потребует переносить секреты или временные инструкции.
• [ ] Стоимость сводки ниже ожидаемой стоимости дальнейшей передачи истории.
• [ ] Один базовый запуск сохранён для сравнения до и после.

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

SECTION 07Пошаговая диагностика

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

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

2. Снимите usage по каждому запросу. Не ограничивайтесь общей суммой в панели. Запишите prompt_tokens, попадания и промахи кэша, completion_tokens, total_tokens, время ответа и наличие повторной попытки.

3. Разделите историю на компоненты. Отметьте, сколько данных относится к системному контексту, старым сообщениям, инструментам, текущему запросу и выводу модели. Если Harness не даёт готовой разбивки, добавьте метки в собственный журнал до отправки запроса.

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

5. Стабилизируйте префикс. Не добавляйте изменяющиеся метки, временные даты, случайные идентификаторы и свежие логи перед постоянными инструкциями и справочными материалами. По правилам DeepSeek кэш работает с совпадающими префиксами, поэтому порядок данных влияет на повторное использование. Официальное руководство по Context Caching

6. Выполните Compaction с контрольной карточкой. Перед операцией сохраните цель, файлы, ошибки, тесты и ограничения. После неё попросите Agent восстановить эти пункты и выполнить небольшое проверяемое действие.

7. Сравните результат с базовым запуском. Сопоставьте не только Token и сумму, но и число повторных попыток, время ответа, рост логов, потребление памяти рабочего процесса и количество ручных исправлений.

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

Не используйте чужие скриншоты Harness как универсальную норму. Сообщество может показывать удачный или неудачный запуск на другой версии, модели, наборе инструментов и рабочем окружении. Для управленческого решения подходят только повторяемые измерения на вашей задаче, а официальные поля DeepSeek API должны оставаться источником расчёта.

SECTION 08Среда и полная стоимость

Token — только один слой затрат. При длинной сессии рабочее окружение может оставаться занятым, журналы — быстро увеличиваться, а параллельные задачи — конкурировать за память, процессорное время, дисковое пространство и сетевые ресурсы. Даже если API-счёт выглядит приемлемо, восстановление после сбоя или ручная проверка неверной сводки может стоить команде больше, чем сам вызов модели.

Сравнивайте до и после на одном базовом задании:

• сумму входных и выходных Token;
• долю попаданий и промахов кэша;
• число вызовов Compaction;
• время до первого полезного результата;
• время полного ответа;
• объём сохранённых логов;
• пиковое потребление памяти;
• число повторных запусков;
• количество ручных вмешательств;
• соответствие итогового результата требованиям.

Не делайте вывод по одному дешёвому запросу. Для устойчивой оценки нужна серия одинаковых запусков с тем же рабочим процессом. Отдельно учитывайте, что официальная тарифная страница может измениться: DeepSeek прямо рекомендует сверять актуальные ставки перед пополнением баланса. Актуальная таблица моделей и цен DeepSeek API

Если проблема находится только в растущем контексте, начните с обрезки инструментов и Compaction. Если одновременно наблюдаются задержки локальной среды, переполнение хранилища, конкуренция нескольких Agent и сложное восстановление после остановки, оптимизация промпта не решит всю проблему. В таком случае нужно разделить задачи по рабочим окнам и изолированным окружениям. Перед выбором проверьте варианты размещения Mac-среды для разработки, а условия и доступные варианты сопоставьте на странице тарифов MACNOX.

Если вы уже видите, что текущая схема держит локальный компьютер занятым часами, смешивает несколько задач в одной среде и заставляет повторно поднимать окружение после сбоев, её недостатки выходят за рамки Token: ограничиваются параллельность, восстановление и контроль доступа к рабочим данным. В такой ситуации аренда Mac у MACNOX может быть разумнее постоянного удержания собственного устройства под долгий Agent — особенно для временной разработки, тестирования или отдельного рабочего окна. Но при постоянной тяжёлой нагрузке, необходимости физических интерфейсов или строгом владении оборудованием сначала сравните аренду с покупкой собственного Mac и изолированным локальным контуром. Для кратковременной проверки такой среды можно начать с заказа Mac в MACNOX, а затем повторить тот же базовый тест Compaction, который вы использовали для оценки DeepSeek Harness.

SECTION 09Дополнительные материалы

• DeepSeek V4: официальный релиз, цены и результаты тестов
• DeepSeek V4 Flash: официальные тесты и стоимость запросов