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

Вывод инструментов занимает 96,1% символов в контекстном окне длинной агентской сессии. А когда кто-то спрашивает «что было раньше», 90% таких вопросов указывают на оставшиеся 3,9%, которые человек и модель написали друг другу, следует из разбора команды FutureOS, опубликованного на Github.

Коротко

• Сессию вырастили до полного окна, принудительно сжали и задали 178 вопросов с ответами только по памяти: стратегия FutureOS удержала 147 ответов, OpenCode 83, Codex 68.
• Разница не в качестве конспекта: Codex хранит реплики пользователя и общий конспект, а текст ассистента и вывод инструментов выбрасывает совсем, FutureOS кладёт первыми оригиналы.
• Платит FutureOS объёмом: проекция на 12 113 токенов против 1 706 у Codex, а цифры по кэшу смоделированы и привязаны к одному продакшен-измерению.

Если вы не следили: по описанию Codex Knowledge Base, нетривиальный рефакторинг с чтением исходников, прогоном тестов и перечитыванием изменённых файлов способен забить окно на 200 тысяч токенов за одну рабочую сессию, ради этого механизмы сжатия и существуют. В документации OpenCode сказано, что сжатие включено по умолчанию и держит около 15 000 токенов недавнего разговора рядом с конспектом, и там же предупреждают: сжатие лоссовое, при важных точных деталях увеличивайте keep.tokens.

147 ответов из 178 против 68 у Codex

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

Модель, вопросы и форма запроса совпадали, менялось только то, что сохраняет сжатие. FutureOS удержал 147 ответов (83%), OpenCode 83 (47%), Codex 68 (38%). Внешние реализации воспроизведены по фиксированным коммитам: Codex b13164d8, OpenCode e03db9bc (пакет 1.18.31).

Системы вкладывают в слово «сжать» разное. Codex сохраняет все реплики пользователя с потолком в 20 000 токенов плюс конспект всей истории. OpenCode хранит конспект и недавний хвост с потолком в 15 000 токенов, рассчитывая, что детали переживут внутри конспекта. FutureOS хранит оригиналы, а конспект и индекс улик идут компенсацией за то, что не влезло.

96,1% символов окна даёт вывод инструментов

Посчитали пять замороженных цепочек из реальных сессий: 9 665 записей и 6 889 611 символов. Вывод инструментов дал 4 370 записей (45,2% записей) и 96,1% символов, текст ассистента 784 записи и 3,7% символов, текст пользователя 141 запись и 0,2%. По отдельным цепочкам доля инструментов в символах держалась от 93,2% до 99,4%.

При этом 80% уточняющих вопросов указывают на то, что говорил сам ассистент, и ещё по 10% на реплики пользователя и на вывод инструментов. Вывод инструментов почти весь объём и почти ничто по обращениям, поэтому его можно ужать до указателей; проза занимает копейки объёма, и её сжатие экономит мало, а стоит ровно того, о чём спрашивают.

Оригиналы остаются на диске, пересчитывается только вид на них

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

Алгоритмов два. deterministic-evidence-v1 собирает защищённые оригиналы, недавний хвост и детерминированный индекс улик без обращения к модели; summarized-evidence-v1 добавляет к этому конспект-передачу и один вызов модели. Второй стоит по умолчанию, первый работает ещё и как запасной путь, если провайдер недоступен или конспект не получился.

Триггер считают перед каждым шагом модели: 80% окна (для миллиона токенов 800 000), но не выше, чем окно минус заявленный потолок вывода модели и запас min(2048, W/16). Внутри проекции текст пользователя сохраняется всегда, остаток комнаты уходит оригиналам ассистента, вывод инструментов ужимается до индекса на 2 048 токенов, хвост около 8 тысяч токенов, цель по истории около 32 тысяч. Аргумент авторов про приоритет пользователя: его цели и ограничения восстановить неоткуда, а прозу и вывод инструментов обычно можно.

Кэш опускает цену одного сжатия с 7,98 юаня до 0,53

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

На прогретом префиксе идентичная форма дала 93,7% попаданий; подмена системного промпта, выброшенные определения инструментов и одна добавленная строка давали 0%. На реальном пути сессия, выросшая до 212 911 токенов, сжалась с cache_read 212 548, то есть 99,8%, за 0,003 юаня против 0,53 холодных. Чтение из кэша дешевле свежего ввода в 50 раз.

Проекция по умолчанию весит 12 113 токенов против 5 152 у OpenCode и 1 706 у Codex, несжатая сессия заняла бы 232 777. Окупается сжатие только на десятках ходов: 61 ход для summarized, 46 для codex, 110 для opencode. Один пункт удержания обходится в 0,0070 юаня у FutureOS, 0,0112 у Codex и 0,0217 у OpenCode.

Может ли модель просто поискать в архиве?

Сама она туда не идёт. Открытый экзамен прогнали на одной руке (summarized), 18 кейсов, 178 значений. Три раунда с автономным доступом к поиску дали 148, 149 и 145 ответов при нуле вызовов инструментов, закрытая база 147, контрольный перезачёт под формулировками третьего раунда тоже 147.

27 значений так и остались в архиве во всех раундах, где поиск был лишь разрешён. Раунд с обязательным первым вызовом и явной инструкцией на проверку вернул 166 из 178 (93,3%) ценой 100 вызовов инструментов, но авторы называют его верхней границей: в продакшене такой инструкции нет. Подсказки про поиск из рантайма убрали, CLI (future session history search / get) оставили: три варианта формулировок, 54 кейса, ноль изменений в поведении.

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

Что обнулит эти колонки

Любой поздний коммит в Codex или OpenCode делает их числа недействительными, так что таблицу придётся пересобирать при каждом обновлении апстрима. Синтетические цепочки регенерируются побайтово из сидов, а реальные сессии опубликовать нельзя: сторонняя проверка этой половины идёт на своих данных, абсолютные числа разойдутся, сравнения должны устоять. Перед цитированием любого числа авторы просят запускать verify_request_shape.py, он не требует модели.