Комментарии 5
Тут есть одна интересная штука, посмотрите статистику попадания в кеш, на облачных моделях, если слишком сильно заниматься оптимизацией и постоянно перестраивать окно то можно неприятно удивится =)
Казалось бы, токины не растут квадратично, как в стандартной схеме, но почти нулевое попадание в кеш, и выходные токины размывают всю выгоду.
Смотрел, просто позже написания статьи - в ней фокус был именно на input.
И Вы правы, там картина далека от приятной) Но и не ужас кромешный, чего я подспудно опасался.
Вот тут подробно по одной из серий (25 сессий): https://articles.rexarrior.online/skill-state-input-cache-output/
"Сокращение общего input сопровождается меньшей долей кешированных токенов. У Sol она падает с 89,4% в Native до 52,3% в V2; у Astra — с 85,3% до 56,5% в V3."
В общем, чтобы эти наброски превратить в новое ready-to-use ядро агента, еще работать и работать...
О ну не так все и плохо, я думал будет хуже =)
я все ваши шишки тоже собрал в своем проекте агента и уже решил по своему, так что да решение есть, но оно не столь простое, ну мне так показалось =)
А "проект агента" - он у Вас о чем? Свой харнесс (кодового агента) делаете?
Он больше по автономному управлению инфраструктурой для локальных моделей, код писать тоже может, но это скорей больше опция, чем цель, кодовых агентов как грязи, и по большей части для фронтир моделей, мой живет 24/7 с бесконечным окном в 32к, и может нормально работать с моделями начиная от Ornith 1.5 9B.

SKILL.state в coding-агентах: меньше истории, но не всегда меньше работы