Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 36
Тоже есть проблемы с токенами, попробую, может поможет.
Отличная статья, а во сколько вы оцениваете вам бы обошлось это не по подписке, а по api pricing? 5.7 миллиардов токенов - не уверен, что у вас там за модель, но по ходу пару десятков тысяч долларов пришлось бы отдать?
Страшно бесят эти лимиты на про тарифе. Вчера решил купить про тариф и попробовать клауд, в целом действительно интересно работает, но даже часа не уходит, чтобы поработать на нем нормально, лимит через полчаса слетает даже на соннете. Может я что-то не так делаю, но огромная загадка как все им пользуются. Неужели все на максе, а точнее как токены докупаются и как часто? Пока не разобрался что и как преимущество пока у ChatGPT.
Pro аккаунт действительно плохо подходит крупным задачам, если использовать его в режиме вайбкодинга, но за полчаса у меня ни разу не получалось израсходовать.
Чтобы снизить расходы, надо чаще очищать контекст.
Обычнно для крупных проектов пишу краткий ТЗ, прошу расписать подробно - сделать общий файл и отдельные файлы на каждый шаг. Потом проверяю, правлю (чаще всего не вручную, а с помощью Клода). А дальше прошу выполнить по одному шагу за раз, перед каждым шагом делаю /clear.
у мну 2 миллиарда за месяц, и это на аккаунте без автономных агентов еще
Я смотрела, я трачу около миллиарда токенов... в день. Упс.)
Я скоро напишу вторую статью обновление, как я это делаю.
О_О это на про подписке или макс?
Если вкратце.
GPT 5.6 Luna - 20$
Minimax M3 - 20$
Qwen 3.8 flash next - 18$
Когда мне нужен GPT 5.6 Sol, я иду в веб версию, там у меня десятки проектов, и есть интеграция с Google Drive, на котором у меня тоже организованы папки проектов. В локальном агенте у меня тоже есть скилл google drive. Я общаюсь с GPT 5.6 Sol в вебе, прошу его сделать гугл доку, иду в локальный агент и кидаю ссылку на гугл доку.
Простите, вы интернет переписываете? :)
Просто свой опыт)
У меня 60 пет проектов, которые я разделила по 6 виртуальным организациям.
Вот те, что я активно применяю каждый день:
Starframe - все про утилиты.
Portalis - возможность встраивать терминал в приложения на Go.
Automata - мой личный harness поверх Pi, с возможностью сохранять контекст по папкам, делать вложенные папки сессий в боковой панеле в терминале. TUI.
Warp - библиотека для grid/flex TUI поверх bubble tea.
Cue TTY - playwright-cli для TUI - агенты могут играться с терминальными апами, по тому же принципу, как это делают через agent browser или playwright-cli.
Dream Frame - сервер и клиент, который встраивается в код игры или three приложения, предоставляя playwright cli like апи для агента - тот может видеть описание рендера кадра, делать скриншоты игры и управлять игроком.
Rune Map - сервер и клиент, который встраивается в код игры, предоставляя внутренние игровые данные - ресурсы, жизнь, положение персонажей, карту, позволяя агенту видеть состояние игры и управлять игроком.
View Print - крутая штука, playwright-cli на стероидах, но свой, позволяет агенту видеть каскады css на элементах, запрашивать указанные части DOM без полной вложенности. Создано для верстки - агент читает макеты и точечно смотрит страницу. Умеет вызывать скрипты, нажимать кнопки и все что нужно, чтобы верстать в том числе попапы и выпадающие списки.
Human Horizon - все экспериментальное интересненькое.
Code Keeper - смотрит мусорные файлы и кривые конфигурации в Go/TS проектах, проверяет покрытие теста. health-check для моих проектов.
Test Warden - его и запускает Code Keeper для проверки тестов.
Проверяет наличие unit тестов каждой функции, e2e, интеграционные тесты. Интегрирован с AI.
Code Check - Набор AI пайплайнов для:
- генерируем файл тестов на каждый .ts/.go файл
- генерируем спеку на каждый файл кода
- генерируем документацию по спекам, на vitepress на двух языках.
- проверяем проблемы и ошибки в коде.
- генерируем общие спеки кода.
Weft - автоматизация ИИ через typescript - удобные weave, flow функции для построения цепочек TS кода и вызовов нужной модели с нужным промтом, параллельно или последовательно.
ИИ - все, связанное с моделями:
TTS - Qwen, Vosk, Cartesia, GPT озвучка, тестирую какие лучше/дешевле
Aura - локальный ИИ на стероидах, быстрая модель через CTranslate2 переводит любой язык в английский, и обратно, - ИИ типа Qwen 2b/0.8b видит только английский, от чего на русском начинает работать сильно лучше. Проект по real time ИИ локально на CPU. Есть прототип, умеет говорить погоду, текущее время и говорить, что у него хорошее настроение.
Everwake - прототип, создание виртуальной симуляции в образовательных целях - солнечная система, земля, государства, территории, в будущем - информация о течении финансов, ресурсов, добыча и так далее.
https://everwake.space
Как это связано с ИИ? я планирую поселить там колонию ИИ существ.)
Computer Use - текущие мультимодальные ИИ так себе читают точное расположение пикселей и промахиваются по кнопкам - я исследую Owl, OmniParser и прочие специализированные модели для анализа скриншотов, соединяя LLM с готовыми json координатами и тулами по управлению ПК и смартфонами.
Life Line - что-то полезное для людей
Emma - локальный агент на CPU, способный быть полезным, как Алиса, и при этом не забывать факты, как Алиса. Выше писала про Aura.
Empty Set - игровая студия
Мое хобби - всю жизнь хотела делать игры и делаю одну.
Between Worlds - MMORPG, где все стычки и споры решаются посредством выбранной настольной игры. Хочу дух Ori, Heroes 3.
Бизнес проекты
https://helpsi.ru
Психологическая поддержка. Я дистиллировала десятки книг по психологии и психиатрии и сделала три линии ИИ - один ИИ работает только с психологическим портретом и говорит следующий ход, второй проверяет риски (самоповреждение, попытка сменить задачу агента), получая только последние 1-3 сообщения, и сам чат бот, который получает всю переписку + информацию от аналитика.
https://nisharadar.ru
Найти хорошую нишу для торговли на wildberries
Luma Coach
Как Мира (психологическая поддержка), но про коучинг
Nanny Lumi - делаю приложение все в одном для детей, когда есть и графики кормления, сна (банально и везде есть), и создание сказок, где герой ребенок (кое у кого такое есть), и живая собеседница, и способность читать сказки как своим голосом так и голосами родителей, отвечать на вопросы про динозавров и про все на свете, с контролем безопасности и этичности.
Study Reels - озвучивает лекцию и генерирует (у меня огромный парк локальных ИИ по генерации, Comfy UI, голоса, звук, видео) слайды, с фоновыми изображениями, показывает текст, подсвечивает озвученные предложения. Удобный способ визуалам не читать текст лекции, а слушать, видеть картинки и читать с экрана по одному абзацу за слайд. Для обучения.
Latent Current - пишу агрегатор для ИИ новостей, сайт-портал.
Я нейроманьяк.)
Выход — 0,03B против 5,75B входа, это полпроцента.
Не совсем так. Чтение из кеша стоит копейки - этим амортизируется разрастание истории. У вас чистый вход это запись в кеш - 0,20B. То есть соотношение выход/вход около 15%. Выход стоит в несколько раз дороже входа.
Справедливо, спасибо — «полпроцента» это доля в токенах, а не в деньгах, и в статье я это не развёл.
По тарифам Opus 5 ($5/$25 за Mtok, чтение кеша $0.50, запись $6.25) выходит: чтение 5,75B → $2875 (59%), запись 0,20B → $1250 (26%), выход 0,03B → $750 (15%). Ваша цифра сходится.
Вывод от этого не меняется, но становится точнее: 85% стоимости — вход, и режется он не длиной ответов, а длиной сессии. Плюс у выхода есть вторая цена, которой нет у ответа как такового: всё, что модель написала, ложится в контекст и потом читается заново на каждом следующем шаге. Так что «короче отвечать» помогает, но пока сессия живёт 800 запросов, эти 15% не там, где горит.
Добавлю пересчёт в статью как UPD.
Уточнение к этой ветке: пересчитывая, я ошибся в ставке записи. Она зависит от TTL кеша — 1,25 базового входа для пятиминутного и 2 для часового, и в транскриптах видно, какой именно: usage.cache_creation.ephemeral_1h_input_tokens. У меня вся запись оказалась часовой, то есть $10 за Mtok, а не $6,25, как я написал выше.
Правильный расклад: чтение 5,75B — $2875 (51%), запись 0,20B — $2000 (36%), выход 0,03B — $750 (13%). Ваш вывод от этого только крепнет: запись в кеш оказалась второй статьёй счёта при доле в токенах около трёх процентов. UPD в статье поправил.
Эту статью модель тоже вычитала.
А судя по тексту она полностью её написала!
Вывод «выход — полпроцента» держится на том, что токены в таблице сложены без веса, а тарифицируются они по-разному: чтение кеша идет по 0.1 базовой ставки за вход, запись — по 1.25, выход — по 5. Пересчитала вашу же таблицу в этих единицах: 5.75B чтения дают 0.58, 0.20B записи — 0.25, 0.03B выхода — 0.15, то есть выход не полпроцента, а около четверти от стоимости чтения, а запись кеша — почти половина. На квадратичный вывод про марафонские сессии это никак не влияет, а вот «просить отвечать короче бессмысленно» из этих цифр уже не следует. Ваш скрипт умеет складывать расход по тарифам, или в нем везде сырые токены?
Всё верно, и это уже поправлено в статье — UPD в конце раздела с таблицей, цифры сходятся с вашими до второго знака.
Скрипт в статье складывает сырые токены. Взвешенный вариант — три строки поверх него:
const W = {read: 0.1, write: 1.25, out: 5};const cost = read*W.read + write*W.write + out*W.out;
По моим данным получается: чтение 60,2%, запись 26,3%, выход 13,5%. Заодно пересчитал главный вывод в тех же единицах: сессии длиннее 300 запросов дают 62,5% стоимости вместо 67% в токенах — просадка есть, но вывод держится.
Про «просить отвечать короче»: соглашусь, что формулировка была слишком широкой, но конкретно у меня этот рычаг маленький не из-за тарифа, а из-за объёма. Средний ответ — 895 токенов на запрос: это агентная работа, где модель в основном читает и правит файлы, а не пишет текст. Сократить его вдвое — это 7% счёта, и то если инструкция «покороче» не добавит лишний шаг: каждый лишний шаг тянет полный контекст, а он у меня был 201k. На чат-нагрузке, где ответы длинные, ваш вывод был бы верен и без оговорок.
Возвращаюсь с поправкой к собственным цифрам: в весах я взял write: 1.25, а это ставка пятиминутного кеша. Часовой стоит 2 базовых входа, и какой именно использован — видно прямо в транскрипте: usage.cache_creation.ephemeral_1h_input_tokens против ephemeral_5m_input_tokens. У меня вся запись оказалась часовой.
С правильным весом — W = {read: 0.1, write5m: 1.25, write1h: 2, out: 5} — выходит чтение 51%, запись 36%, выход 13% вместо моих 60,2 / 26,3 / 13,5. Выход почти не сдвинулся, а вот запись в кеш оказалась второй статьёй счёта при доле в токенах около трёх процентов.
Заодно нашлось следствие, которого я не ждал: три четверти всей записи — это обычная работа подряд, около 5k на каждый шаг просто за факт шага, а самые дорогие единичные записи — возвраты к сессии после паузы больше часа: TTL истёк, префикс пишется заново целиком — 178k против 5k. UPD в статье поправил.
Жесткая остановка сессии скорее вредна. В текущей сесси у модели есть контекст, в новой сессии модель пойдёт снова перечитывать и изучать всё что ей нужно, что тоже стоит денег
Цена у перезапуска действительно есть, вопрос в том, с чем её сравнивать.
Новая сессия у меня стартует не с нуля: есть конспект предыдущей на пять строк и карта кода с диапазонами строк, так что модель читает один-два нужных фрагмента, а не изучает проект заново. Стартовый контекст выходит 50–65k плюс 10–20k на чтение — разово. А на 150-м шаге старой сессии каждый следующий запрос идёт от 200k и выше. Разница ~140k на запрос, то есть перезапуск окупается за три-пять шагов.
Где вы правы: режу не «через 150 шагов посреди мысли», а на границе задачи, и если задача одна большая и не делится — рвать её смысла нет, дороже выйдет. Правило работает ровно потому, что работа заранее нарезана на куски, каждый из которых закрывается за одну сессию.
«отвечай кратко» не помогает - счёт приходит за вход, а не за выход. И ловушка с повторным чтением файлов знакомая: каждый лишний файл в контексте потом оплачивается сотни раз. Для себя вынес: лучше чаще начинать сессию заново, чем достраивать марафон. Те же грабли и у сайтов в диалоге - я собирал страницу через чат-ассистента smart-ai24, и там правки лучше давать как ваши, а не тащить всю историю.
Вообще для меня удивительно выглядят советы делать clear через 200к контекста. Это ведь не рашает вашу проблему повторного чтения файлов , а лишь усугубляет ее. Потому как после Clear вы получаете чистый контекст, который забыл все о чем говорили и ему снова надо делать реконы.
У меня сессия выглядит так:
У каждой части проекта имеется папка docs со всей архитектурной документацией. Она обязательно актуализируется перед каждым compact на основании изменений сделанных за сессию. Плюс обязательно актуализиурется handof файл передача контексту после компакта. В основном клод делает это автоматом после каждой серьезной задачи, а в конце подтягивает хвосты.
Сессию часто довожу до 2/3 или почти до конца , если нужно задачу завершить в текущей сесии. В конце обязательно синк документов.
Потом компакт и прогрев сесии на основании handof. С лимитами проблем не возникает, мне не нужно постоянно обьяснять тожесамое и наступать на те же грабли, ни живут и накапливаются в TROUBLESHOOTING , решения в DECISIONS, планы актуальные и что в работе в ROADMAP, архитектура проекта всегда актуальна и живет в ARCHITECTURE ... . Эти документы описаны в HANDOFF и перечитываются после компакта в обязательном порядке.
С одной стороны небольшой оверхэд, зато у меня по каждому компоненту актуальная документация и я могу всегда вернуться к любой задаче и продолжить с того места, на котором закончил.
Корень же постоянного перечитывания файлов надо искать в ином. Может постараться разбить монолит на части. Сделать версионность , дать точки опоры.
Docs-слой у меня ровно такой же, спор не про него. CLAUDE.md с протоколом, ARCHITECTURE.md, планы фаз в memory, /carry — это тот же HANDOFF, он пишется перед clear, а не вместо него. Clear без хендоффа — это, конечно, потеря контекста, тут вы правы. Речь про другое.
Compact только откладывает: саммари само становится контекстом, дальше он снова растёт ~0.7k за запрос. Вход оплачивается на каждом запросе, поэтому цена сессии — не сумма ответов, а интеграл контекста по числу запросов. Рекон после clear — это 3-4 ranged read, 15-20k токенов один раз. Недосброшенная сессия — это 200k, умноженные на все оставшиеся запросы. У меня по замерам сессии длиннее 300 запросов съели 72% всех потраченных токенов за всё время проекта.
А вот по корню вы правы полностью: перечитывание лечится не clear’ом. Я сделал docs/map.md — генерируемый line-level индекс (секции CSS, блоки разметки, индексы функций и констант). Читается 20 строк оглавления, потом Read с offset/limit по нужному диапазону вместо файла целиком. Повторные чтения были 32% всего объёма, style.css — 266 раз за историю.
Монолит распилен на app-*.js по вкладкам. Не режется только index.html: ванильный JS без бандлера и ~460 инлайновых onclick=, вызывающих глобальные функции по имени. Обернуть в IIFE — сломать вкладку. Так что вместо распила — карта.
Тут видно многое зависит от того, чем занимается агент.
У меня это чаще когда сессия редактирует большие md промпты , к слову про перечитывание странно, у меня были раньше ситуации, когда у меня были тяжелые монолитные промпты по 400-500 кб (это задания для воркеров на различные операции). было тяжко, но в целом перечитывания не было, я бы заметил :).
Для кода сброс сессии действительно не так страшен, если сделать грамотный роутинг (у вас он, к слову, есть, а можно его еще расширить). Тогда после компакта или очистки в контекст попадает этот маршрутизатор, что дергать в каком случае, и нет проблем с потерей контекста.
Правда ваш style.css на 16 тыс строк 642 KB - это жуть, уж простите) И map.md ему наверное поможет, но это костыли. Вы хоть сами в него заглядываете? )
Мне кажется там львиная часть контекста пошла на работу с этим монстром. К тому же для контекста это очень высокая когнитивная нагрузка, содержать в порядке эти скобочки и стрелочки .... вы сами спросите своего клода, он вам выскажет всю боль, что постоянно испытывает по этому поводу. Каждая скобочка и точка - это токен! Не удивительно что он забывает постоянно.
... сессии длиннее 300 запросов ,а что у вас за запросы такие? Тут опять-таки дело не в длине контекста, а в том почему столько запросов на сессию. По типу подвинь то влево, подвинь то вправо ... тут проще навреное тогда написать какую-то песочницу для редактирования дизайна. Это уже к организации процесса, clear это просто заплатка тут,а не лечение причины.
Про «зависит от того, чем занимается агент» — согласен, и это главное расхождение. У вас сессия редактирует промпты, у меня правит код в 44 модулях с проверкой в браузере после каждой фазы.
По style.css спорить не буду: 647 КБ и 16 тысяч строк — плохо, и это прямое следствие отказа от сборки. Сам я в него не заглядываю, правки идут через map.md, и да, индекс поверх монстра лечит симптом. В проекте без бандлера он заменяет то, что в нормальном даёт модульность и IDE.
Только замер говорит, что львиная доля ушла не туда. Чтение файлов — 43% результатов инструментов, а те — 32% контекста; на все чтения вместе выходит около 14%. При ranged read файл стоит не 642 КБ, а прочитанный диапазон. Его 266 чтений — это не размер, а отсутствие правила «не читай дважды».
А вот «дело не в длине контекста, а в том, почему столько запросов на сессию» — тут вы правы, и после того разговора я пересчитал расход в другом разрезе. Запись в кеш даёт 36% счёта при доле в токенах около трёх процентов, и три четверти её — примерно 5k на каждый шаг просто за факт шага. То есть запрос стоит денег сам по себе, независимо от содержимого. Ваш вывод из этого следует прямо: резать надо число шагов, а не только контекст.
Что до «а что у вас за запросы» — шаг это не «подвинь влево», а звено цикла: карта → чтение диапазона → правка → node --check → тест → проверка в превью. Часть уже ушла в хуки и сабагентов, но цикл всё равно длинный.
Про «clear — заплатка»: да, но на другую дырку. Диалог растёт сам по себе даже при идеальной архитектуре, и его длиной приходится управлять отдельно от того, насколько аккуратен код.
То есть запрос стоит денег сам по себе
Тут как бы не запрос стоит, а как вы правльно писали у вас на каждый запрос отправляется весь контекст . Если кэш не протух, и вы постоянно работаете , то 1/10 (ну примерно) от размера контекста считается. Если же возвращаться к задаче с большим окном через интервалы, когда кэш умер, то это 10/10 и это очень больно! И тут ваши чтения файлов - это реально капля в море.
В этом случае поможет только изменение в стиле работы. Я стараюсь держать все сесии с горячим кэшем, доводить до конца , потом синк доков, саммари и компакт/холд. Между собой все части общаются через тз- послания.
Бужу сесии по мере накопления заданий, потом разом применяю, пишутся отчеты обратно в зоны - компакт/холд. Пока сессия горячая (интервал час для подписки), то не так страшно , но если открыто куча сессий , с большим окном , и к каждой идет обращение с большим интервалом, то тут даже с небольшим числом запросов будет выжираться контекст со свистом, ибо каждое пробуждение это - фулл контекст.
Ну и куча запросов - это тоже к стилю работы. Стараться промпты писать так, чтобы за раз решалось несколько задач.
Механику подтверждаю, только коэффициент жёстче, чем вы пишете: горячее чтение идёт по 0,1 базового входа, а запись в часовой кеш — по 2,0. Протухший префикс дороже горячего чтения того же объёма в двадцать раз, не в десять.
А вот распределение у меня вышло другое, и это, по-моему, самое интересное. Я разложил запись по паузе перед запросом: после перерыва больше часа пишется 178k против 5k при работе подряд — механизм ровно ваш, 89% контекста переписывается. Но таких запросов оказалось 131 из 30 774, и вся переплата за пробуждения — 3,8% счёта. Главная статья у меня всё равно чтение горячего кеша, умноженное на число шагов.
Похоже, мы описываем два разных режима. У вас много сессий, которые будятся с интервалами, — там доминируют пробуждения. У меня одна задача за сессию подряд от начала до конца, и пробуждаться просто нечему. Отсюда практический вывод: структуру счёта надо мерить у себя, а не выводить из механики — она одна, а расклад получается противоположный.
По «ваши чтения файлов — капля в море» не соглашусь, и как раз из вашей же арифметики. Лишний файл на 20k токенов стоит $0,2 записи один раз плюс по $0,01 чтения на каждом следующем шаге. За сотню шагов это доллар с одного лишнего файла — при том что сам файл был прочитан однократно. Дорог не акт чтения, а то, что прочитанное едет дальше.
И к «не запрос стоит сам по себе»: стоит, просто немного. Хвост в кеш — около 5k на шаг, это ~5 центов. Шаг при контексте 200k выходит примерно в 15 центов, из них треть запись, две трети чтение. Поэтому ваш последний совет — писать промпт так, чтобы за раз решалось несколько задач — бьёт по обеим статьям сразу, и это, пожалуй, самый сильный рычаг из всего, что мы тут перебрали.
Собственно согласен со всем) Я просто хотел сказать, что многое зависит от стиля работы. Люди открывают по куче сессий , будят их с протухшим кэшем мелкими сообщениями, а потом удивляются куда деваюся лимиты ... потому такие статьи, как ваша , всегда мне нравятся. Многие не понимают суть работы с кэшем ИИ и прочим. Плохо что нету нормальной статистики сразу в дашборде где-то. Каждый собирает свой велосипед. Я когда-то тоже городил его, потом забросил, ибо эти метрики тромозили работу.
Ну и 20к токенов, это в целом не маленький файл. Перечитывание такого действительно больно , лечится разбивкой, версионностью . Собственно у меня потому и много сессий, каждый решает свою отдельную задачу из пайплайна. Внимание контекста не размазывается. Но свести их вместе часто нетривиальная задача, но она стоит того.
Механику подтверждаю, только коэффициент жёстче, чем вы пишете: горячее чтение идёт по 0,1 базового входа, а запись в часовой кеш — по 2,0. Протухший префикс дороже горячего чтения того же объёма в двадцать раз, не в десять.
А вот распределение у меня вышло другое, и это, по-моему, самое интересное. Я разложил запись по паузе перед запросом: после перерыва больше часа пишется 178k против 5k при работе подряд — механизм ровно ваш, 89% контекста переписывается. Но таких запросов оказалось 131 из 30 774, и вся переплата за пробуждения — 3,8% счёта. Главная статья у меня всё равно чтение горячего кеша, умноженное на число шагов.
Похоже, мы описываем два разных режима. У вас много сессий, которые будятся с интервалами, — там доминируют пробуждения. У меня одна задача за сессию подряд от начала до конца, и пробуждаться просто нечему. Отсюда практический вывод: структуру счёта надо мерить у себя, а не выводить из механики — она одна, а расклад получается противоположный.
По «ваши чтения файлов — капля в море» не соглашусь, и как раз из вашей же арифметики. Лишний файл на 20k токенов стоит $0,2 записи один раз плюс по $0,01 чтения на каждом следующем шаге. За сотню шагов это доллар с одного лишнего файла — при том что сам файл был прочитан однократно. Дорог не акт чтения, а то, что прочитанное едет дальше.
И к «не запрос стоит сам по себе»: стоит, просто немного. Хвост в кеш — около 5k на шаг, это ~5 центов. Шаг при контексте 200k выходит примерно в 15 центов, из них треть запись, две трети чтение. Поэтому ваш последний совет — писать промпт так, чтобы за раз решалось несколько задач — бьёт по обеим статьям сразу, и это, пожалуй, самый сильный рычаг из всего, что мы тут перебрали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
5,75 миллиарда токенов за полгода: как я перестал жечь контекст в Claude Code