Codex после сжатия вспомнил 68 ответов из 178

Разработчики FutureOS взяли три стратегии сжатия контекста (свою, OpenCode и Codex) и прогнали их на одной модели, с одинаковыми вопросами и одинаковой формой вызова. Различалось только то, что сжатие оставляет. После сжатия на 178 вопросов «по памяти» FutureOS ответила в 147 случаях (83%), OpenCode в 83 (47%), Codex в 68 (38%). Самая интересная цифра в разборе другая: за каждый пункт удержанного ответа FutureOS платит меньше обоих соперников, хотя её проекция самая большая.

Отчёт вышел 4 августа в инженерном блоге FutureOS на GitHub. Схема эксперимента такая: сессию растят до полного окна, принудительно сжимают и спрашивают то, что можно знать только из истории. Например, третью строку вывода какого-нибудь скрипта, ID, который вернул инструмент, или ограничение, которое пользователь задал несколько часов назад. Восемь вопросов подставные, их ответ нигде не встречался. На эту приманку не попалась ни одна из трёх систем.

Что занимает окно и о чём спрашивают

Авторы подсчитали состав пяти замороженных реальных сессий: 9 665 записей, 6 889 611 символов. На вывод инструментов приходится 96,1% символов, на текст ассистента 3,7%, на реплики пользователя 0,2%. По отдельным сессиям доля вывода инструментов колеблется от 93,2% до 99,4%. Зато в вопросах «что было раньше» картина обратная: 80% касаются того, что говорил сам ассистент, и только по 10% приходится на реплики пользователя и на вывод инструментов.

Отсюда и разница в результатах. Codex хранит все сообщения пользователя (до 20 000 токенов) и конспект всей истории, а прозу ассистента и вывод инструментов выбрасывает целиком. Так он заранее отказывается от тех 80% вопросов, которые касаются ассистента. OpenCode держит конспект и свежий хвост до 15 000 токенов, детали должны пережить сжатие внутри конспекта, а конспект теряет часть информации. FutureOS в первую очередь сохраняет защищённые оригиналы реплик пользователя и ассистента. Конспект и индекс по выводу инструментов лишь возмещают то, что в бюджет не влезло.

Сколько стоит удержанный ответ

Без сжатия проекция, которую модель видит на следующем ходе, занимала бы 232 777 токенов в медиане. Стратегия FutureOS по умолчанию ужимает её до 12 113 токенов (5,7%), детерминированный вариант без вызова модели до 9 945 (4,7%). У OpenCode выходит 5 152 токена (2,1%), у Codex 1 706 (0,6%). Каждый следующий ход с проекцией FutureOS стоит 0,00048 юаня, у Codex 0,000068, у OpenCode 0,000204, а без сжатия 0,0092. Проекция FutureOS примерно в семь раз тяжелее, чем у Codex, и авторы прямо пишут, что тратят токены ради удержания.

Решает здесь кэш префикса. Без него одно сжатие у FutureOS обходится в 7,98 юаня, с кэшем в 0,53. У Codex соответственно 7,64 и 0,42, а OpenCode платит одинаковые 0,99 в обоих случаях, потому что у его запроса на сжатие собственный системный промпт и общий префикс с сессией он не делит. В итоге «в восемь раз дороже OpenCode» превращается в «вдвое дешевле». Если взять одно сжатие плюс 100 ходов и разделить на пункт удержания, получится 0,0070 юаня у FutureOS, 0,0112 у Codex и 0,0217 у OpenCode.

Сжатие окупается не сразу: у суммаризирующего режима FutureOS через 61 ход, у Codex через 46, у OpenCode через 110. В короткой сессии это чистый расход. И главная оговорка: цифры по кэшу смоделированы, а не измерены. Собственные счётчики кэша в прогонах искажены порядком запуска, поэтому модель привязали к единственному замеру в продакшене, 99,8%. Детерминированный режим FutureOS не вызывает модель вовсе: сжатие ничего не стоит, удержание 71%.

Как устроена проекция FutureOS

Оригиналы сообщений не удаляются и не переписываются. Сжатие только пересчитывает, что увидит следующий запрос, а журнал остаётся на диске, его можно искать, экспортировать и ответвлять. Порог срабатывания равен 80% окна: для окна в миллион токенов это 800 000, но не больше, чем позволяет заявленный моделью лимит вывода с небольшим запасом. Текст пользователя сохраняется всегда. Свободное место отдаётся оригиналам ассистента, свежий хвост занимает около 8 тысяч токенов, история целится в 32 тысячи (максимум 128 тысяч). Вывод инструментов сводится к индексу на 2 048 токенов, который собирается без модели: сначала ошибки, затем группы по инструменту и цели с приоритетом конфигов, схем, валидации и тестов. Вытесненный ответ ассистента помечается как «omitted / not summarised» и остаётся доступным по запросу.

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

Отдельного промпта у запроса на конспект нет. Кэш провайдера сравнивает токены с самого начала: системный промпт, определения инструментов, сообщения. На прогретом префиксе запрос той же формы попадал в кэш на 93,7%. Подмена системного промпта, удаление определений инструментов или даже одна добавленная строка давали 0%. В реальной сессии, выросшей до 212 911 токенов, при сжатии из кэша прочитали 212 548. Чтение из кэша в 50 раз дешевле свежего ввода: 0,02 против 1,0 за миллион токенов.

Почему не искать в архиве

Раз оригиналы целы, модель могла бы сама находить потерянное. Это проверили в режиме «с открытой книгой» на 18 кейсах. В трёх вариантах промпта с доступом к поиску модель не сделала ни одного вызова инструмента, а результат держался на уровне 145-149 из 178. Закрытый контроль без инструментов дал 147. Ровно 27 значений лежали в архиве, но модель туда не заглянула. Только когда первый вызов сделали обязательным и прямо велели проверять, результат вырос до 166 из 178 (93,3%): поиском нашлись 20 из 28 отсутствовавших значений. Авторы считают этот раунд верхней границей, потому что в продакшене такой инструкции нет.

Из рантайма в итоге убрали подсказки о том, как вспоминать, а CLI для поиска по истории (future session history search / get) оставили. Вывод авторов: поиск не закрывает разрыв, который возник из-за того, что выброшено при сжатии.

Где цифры могут поплыть

Экзамен проверяет узнавание точных значений, а не продолжение задачи. На таком экзамене дословное хранение сильнее всего, а конспект слабее всего, и на задачах результат может отличаться. Codex и OpenCode реализованы заново по конкретным коммитам, b13164d8 и e03db9bc (пакет 1.18.31), так что любое последующее изменение в их коде делает цифры недействительными. Собственные инструменты поиска Codex требуют его облачного бэкенда, поэтому в таблице стоит локальный запасной режим. В каждой ячейке один прогон, и разницу в несколько пунктов на такой выборке не различить. Реальные сессии опубликовать нельзя, поэтому сторонней команде придётся подставить свои: абсолютные числа изменятся, а соотношение между стратегиями, по словам авторов, должно сохраниться.

Прежде чем ссылаться на любую цифру, авторы советуют запустить verify_request_shape.py. Скрипту не нужна модель: он проверяет, что экзамен по-прежнему отправляет тот же промпт и те же инструменты, что и продакшен.