Skip to content

Claude Code В 20 РАЗ ДЕШЕВЛЕ: советы от Anthropic

Советы от Anthropic по эффективному использованию токенов в Claude Code, позволяющие снизить расходы в 20 раз.

Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.

Generated from the transcript and can be wrong — check the timestamp.

Key Takeaways

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

What the video covers

  • Объяснение механизма кэширования в Claude Code и его влияние на стоимость токенов.
  • Совет сохранять историю сессии перед её завершением, чтобы избежать больших затрат при возобновлении.
  • Кэш живёт 1 час с момента последнего взаимодействия, после чего возобновление сессии становится дороже.
  • Инвалидирование кэша происходит при смене модели, уровня усилий и некоторых других действиях.
  • Рекомендация не менять модель и настройки посреди сессии для экономии токенов.
  • Советы по управлению контекстом: очищать ненужные данные для уменьшения затрат и повышения качества.
  • Разделение задач на короткие сессии для избежания превышения лимитов и экономии токенов.
  • Обзор официальной документации Anthropic по работе кэша и его особенностям.
  • Обсуждение выбора моделей и уровней усилий на основе бенчмарков и личного опыта.
  • Рекомендации по использованию альтернативных моделей для разных задач с учётом стоимости и качества.

Answers

Questions about this video

Почему кэширование в Claude Code снижает стоимость использования токенов?

Кэширование позволяет повторно использовать контекст сессии без повторной отправки всех токенов в облако, что снижает стоимость примерно в 20 раз.

Что происходит, если я меняю модель или уровень усилий посреди сессии?

Такие изменения инвалидируют кэш, что приводит к его очистке и увеличению затрат на токены при дальнейшем использовании.

Как лучше организовать работу с сессиями, чтобы экономить токены?

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

Full Transcript — Download SRT & Markdown

00:00
Speaker A
Несколько дней назад антропики в своём блоге поделились советами, как максимально эффективно использовать токены в Клод-коде. Тема интересная, и один из советов делает использование Клод-кодов в 20 раз дешевле. В этом видео разберём все эти советы, плюс, конечно же, накину мнение от себя. Меня
00:15
Speaker A
зовут Ваня, несерьёзный атишник. Поехали. И первая вещь, о которой я не думал, — это кэширование. То есть, когда мы говорим про агентов в продакшене, где мы платим за API токены, то, конечно же, мы думаем о кэшировании. Но на самом деле
00:26
Speaker A
оно точно также работает и в подписке. Для начала давайте вспомним, как оно вообще работает. То есть, когда мы стартуем новую сессию в Клодкоде, пусть это будет сессия с Fable, первым делом в контекст попадают те вещи, которые загружаются автоматически. То есть это
00:37
Speaker A
код MD-файлик, это описание скилов и так далее. То есть то, что всегда попадает в контекст. Как это можно посмотреть на старте сессии? Просто вызовите контекст и увидите всё, что туда попало. То есть там MCP, скилы, код MD, Memory MD. Далее
00:49
Speaker A
вы начинаете общаться, то есть вы задаёте там какой-то вопрос или какую-то инструкцию даёте, соответственно, вам КД отвечает и так далее. То есть ваш диалог продолжается. Так вот, каждое ваше взаимодействие, вся предыдущая история постоянно отправляется в облако. Если бы
01:03
Speaker A
этого кэша не существовало, то за 300 000 токенов мы бы заплатили 6 долларов вместо 30 центов, то есть в 20 раз больше. И казалось бы, если оно работает автоматически, зачем нам вообще об этом переживать? Ну, платим мы в 20
01:18
Speaker A
раз меньше и хорошо. Так вот, есть о чём переживать. Кэш живёт 1 час с момента последнего взаимодействия. Так вот, в чём проблема. Если мы уйдём, ну вот просто мы решили бросить сессию, забили, да, продолжать будем позже, то для того,
01:30
Speaker A
чтобы просто нам возобновить диалог, нам нужно будет заплатить в 20 раз больше, чем мы могли бы заплатить до. Отсюда следует простой совет. Если вы собираетесь бросить сессию, вам результат, пока он ещё в кэше находится, вся ваша история, нужно куда-то сохранить. То есть либо
01:45
Speaker A
сделать компакт, уменьшив вот эту часть, которая у вас была до, то есть диалог, который был до, сжать его до какого-то адекватного summary, либо там сделать какой-то хендоф и сложить его в файлик.
01:54
Speaker A
Короче говоря, любым способом, в моём случае там я чаще использую компакт, ну и рядом стоящий совет. Если у вас длинные сессии, ну, допустим, вы работаете на 5x в подписке, то вероятность, что вы упрётесь в лимит, она сильно больше, если ваши сессии
02:07
Speaker A
маленькие. То есть вы можете просто посередине выполнения задачи, ну, то есть у вас агент уже код, например, пишет, вы упираетесь в лимит. Пока эти лимиты сбрасываются, скорее всего, пройдёт уже час, и вы снова заплатите в 20 раз больше просто на то, чтобы
02:20
Speaker A
продолжить то, что делали до этого. Если же ваши сессии будут короткие, то как минимум у вас какие-то логические точки будут задачи. То есть вы будете завершать каждую задачу в короткой сессии, и вероятность, что на середине вы прекратите, она будет сильно меньше.
02:32
Speaker A
Ну и, соответственно, здесь же рядом может быть вывод, что если вы возвращаетесь просто по кайфу, потому что вам вернутся какие-то старые сессии, то в любом случае ваш старт будет дорогим. То есть, если вы до этого там не сделали компакт, у вас в любом случае
02:44
Speaker A
протух уже кэш. Ну и, соответственно, будьте добры, заплатите в 20 раз больше, потому что будет запись в кэш. Стоит задуматься, стоит ли возвращаться к старой сессии, либо у вас и так уже в контексте вашего проекта есть понимание, как продолжить что-то делать. Второй
02:56
Speaker A
нюанс: кэш можно просто сломать. В официальной доке антропиков рассказывается, в каких случаях кэш инвалидируется, то есть очищается. Всё, что нам нужно знать, что, например, переключение модели, изменение уровня усилий — всё это инвалидирует кэш, то есть очищает кэш. Здесь ещё есть
03:11
Speaker A
некоторые условия, допустим, включение быстрого режима, но кто в Клодкоде включает быстрый режим, мы же не бояре.
03:16
Speaker A
Ну, есть действия, которые этот кэш не очищают, то есть сохраняют. Можете это всё почитать. Но если коротко, если вот это всё не запоминать, ну, максимально частое действие, которое мы можем делать, — это смена модели, чуть реже может быть
03:28
Speaker A
смена эффорта. Вот если мы посередине диалога это всё меняем, мы тоже очищаем кэш и тоже будем платить в 20 раз больше для того, чтобы просто перейти на другую модель. Я на всякий случай эту документацию прикреплю. Если кому-то хочется почитать, как работает кэш,
03:41
Speaker A
какие действия инвалидируют, то можете почитать. Но совет простой: не меняйте коней на переправе. То есть, если вы хотите посередине дороги поменять модель, эффорт или конфигурацию, лучше этого не делать, если хотите сэкономить токены.
03:53
Speaker A
Делайте все эти вещи на старте. То есть запустили сессию, посмотрели, какая у вас модель, какой эффорт, и продолжаете с этим работать. Вот такая вот интересная история с кэшом. Обязательно пишите в комментариях, знали вы об этом или не знали. Я хоть и знал про
04:05
Speaker A
существование кэша, но почему-то в подписке об этом даже не думал. Ну и если вы тоже не думали, то обязательно втыкаем лайк, подписываемся. Но если думали, то просто так это сделайте.
04:14
Speaker A
[смех] Итак, с кэшом разобрались. Следующий совет связан с контекстом. Я не обязательно в том же порядке, в котором написана статья, рассказываю советы, потому что мне показался такой порядок более логичный. Я об этом уже рассказывал в полном курсе по Клод-коду.
04:26
Speaker A
Если кто не смотрел, вот здесь вот где-то в углу всплывёт подсказочка, на неё можно нажать и сохранить себе просто на будущее посмотреть. Но здесь проведу краткий экскурс. Итак, как я уже сказал, до этого у нас по умолчанию что-то
04:37
Speaker A
попадает в контекст, просто потому что мы стартуем сессию. Cд MD memory, описание скилов и так далее. Короче говоря, в контекст сразу что-то попадает. Вы можете посмотреть командой сшконтекст, что попадает на старте в этот контекст. И если у вас там много
04:51
Speaker A
мусора, то, соответственно, это повод заняться тем, чтобы почистить всё, что у вас накопилось за время использования. Я для этого прямо целое видео посвящал.
04:58
Speaker A
Тоже вот здесь вот где-нибудь сейчас плывёт. И в конце я тоже эти два видео оставлю и в описании тоже оставлю, поэтому тоже его сохраняйте, посмотрите.
05:04
Speaker A
Очень короткое видео. Прямо сегодня можно улучшить свою ситуацию с Клод-кодом. Те советы давал Борис Чёрный — это создатель Клод-кода. Я просто чуть-чуть переиграл эту историю, потому что то, как он предлагает это делать, мы просто не можем сделать, потому что мы
05:16
Speaker A
не настолько богатые. Так вот, несмотря на то, что у нас есть кэш, мы всё равно за него платим. Пусть в 20 раз меньше платим, но какая разница, всё равно платим. Так вот, если вы задачи делаете одна за одной просто в рамках одной
05:27
Speaker A
сессии, это не имеет никакого смысла. То есть, если ваша задача логически завершилась, вам не нужен контекст от первой задачи для того, чтобы приступить ко второй задаче. Если он и нужен, то уж точно не весь. Ну и, как мы уже знаем,
05:40
Speaker A
если мы бросим нашу сессию, ну, допустим, вот нам здесь уже можно было очистить сессию, но мы решили, что не будем её чистить. Ну и, допустим, в рамках третьей задачи где-нибудь вот здесь у нас просто кончились лимиты.
05:49
Speaker A
Соответственно, когда мы вернёмся после того, как кэш уже будет сброшен, мы за вот это всё снова заплатим только в 20 раз больше. Мы ещё можем посмотреть на саму схему, которая есть у антропиков.
05:59
Speaker A
Может быть, она будет более понятная. Они здесь как раз-таки показали, как это выглядит. Но по сути здесь то же самое.
06:04
Speaker A
То есть вот у нас есть какое-то количество токенов, которые мы тратим на старт. Потом у нас выполняется задача, количество токенов, соответственно, растёт. И далее мы можем сбросить сессию и начать [откашливается] просто заново.
06:14
Speaker A
То есть у нас снова есть какое-то количество токенов на старт и так далее. Если же мы просто в этой сессии продолжаем это всё делать, то бессмысленно тратим токены. Плюс рискуем тем, что когда очистится кэш, мы заплатим ещё и в 20 раз больше. И самое
06:26
Speaker A
главное, что у этих жирных сессий у них вообще нет никаких плюсов. То есть они просто баналь
06:39
Speaker A
опусе. Вообще, в идеале максимально эффективноя для меня лично оставаться, ну, где-то там 400-500, может быть. Ну и, соответственно, мы начинаем злиться, а зачем оно нам надо? О'кей, думаю, здесь понятно. Это работает и просто в чате. То есть не нужно в рамках одного
06:51
Speaker A
чата решать вообще все ваши задачи. Если ваша задача логически завершена, перейдите просто в другой чат. Ну и, конечно, если мы говорим вот про такой процесс, на нём особо далеко не уедешь.
07:00
Speaker A
У нас есть какая-то большая задача, и в любом случае мы потратим огромное количество токенов. В любом случае там внутри будут какие-то подзадачи. Ну, если там клод хотя бы самостоятельно разобьёт это на подзадаче, если вы этим не озадачились. Что ж делать? Что же
07:11
Speaker A
делать? А делать надо следующее. Нам нужно делегировать задачу субагентам. Именно для этого они существуют. Я думаю, что, может быть, многие из вас слышали про слово оркестрация. То есть у нас есть какой-то главный агент в главной сессии, у которого есть план, и
07:24
Speaker A
он вызывает субагентов для того, чтобы этот план выполнять. Плюсом вклад-коде есть динамические workflow, которые тоже могут реализовать план. И здесь даже не модель вызывает уже субагентов, а заранее написанные план вызывает этих субагентов. То есть это написано в виде
07:37
Speaker A
скрипта. Об этом тоже рассказывал вот в этом видео про ультракод. Тоже можете себе его сохранить и посмотреть позже.
07:43
Speaker A
Эту иллюстрацию я тоже взял из той же статьи. То есть у нас есть главная сессия. Вот он наш главный агент. Пусть это будет, допустим, Fable. А вот эти субагенты пусть будут опуст. Да, здесь есть, конечно, минус, что мы тратим
07:53
Speaker A
какое-то количество токенов на старт этих субагентов, чтобы им какой-то контекст передать. Но в рамках вот этой подзадачи в любом случае потратится ещё какое-то количество токенов на то, чтобы эту задачу реализовать. И в конечном итоге в главной сессии вся эта история
08:08
Speaker A
не нужна в Кыше. То есть ему нужен просто ответ. Допустим, вы отправили субагента поискать на десяти сайтах какую-то информацию. Он эти 10 сайтов, соответственно, на вход получил. То есть в виде там текста, например. В конечном итоге он нашёл нужную информацию, сделал
08:22
Speaker A
короткое сари. Допустим, вы потратили на то, чтобы это сделать, там 300.000 токенов. Ну, пусть будет так. А на выходе получили, ну, допустим, 30.000 токенов. И вот эта информация, она уже не нужна нам в Кэше вообще. То есть для
08:34
Speaker A
того, чтобы продолжать задачу в главной сессии, достаточно лишь вот этого ответа. Ну и, соответственно, если мы вызываем там множество субагентов, это нам позволяет в рамках вот этой одной сессии выполнять какую-то большую нарезанную задачу. У нас есть какой-то пласт функционала. Если мы занимаемся
08:49
Speaker A
вебкодингом, да, и что-то реализуем там в каком-нибудь приложении, например, то, соответственно, главный агент понимает план, как вызывать субагентов и что каждый субагент должен сделать. Вот таким вот образом у нас получается, что в главной сессии агента подзадачи выполняются субагентами. Это позволяет
09:05
Speaker A
вот этой сессии жить достаточно долго, потому что именно ответы от субагентов занимают малое количество токенов в рамках вот этого контекста основной сессии. Отсюда следуют выводы. Первое - это нужно есть слона по частям. То есть, если у нас есть какая-то большая задача,
09:19
Speaker A
её нужно поделить на подзадачи. И эти подзадачи нужно отдать субагентам. Тогда у нас получится в основной сессии переварить весь вот этот большой план.
09:27
Speaker A
Второй совет, соответственно, - это следить за тем, что установлено в код-коде. Если у вас накопилось большое количество мусора, это не только дороже, на самом деле это ещё и очень сильно портит качество. Если у вас много противоречий внутри инструкций, то,
09:40
Speaker A
соответственно, у вас просто модель начинает тупить. Об этом я рассказывал в этом видео. Напоминаю, можете потом перейти и посмотреть. Ну и третий совет- использовать субагентов. Если всё это звучит сложно, залетайте в эти гараж.
09:50
Speaker A
Там я рассказываю прямо начиная с простых промптов, как построить этот процесс. От планирования до нарезки вот этих задач, до реализации этого всего субагентами и до процесса, как вы это всё зарелизите. Короче говоря, если вам нужно поучиться вайпкодингу на простых
10:03
Speaker A
шагах, залетайте, ссылочка будет в описании. Ну и такой совет с натяжечкой, но всё-таки я ему иногда следую. Если вы понимаете, где у вас есть какая-то проблема или в каком файле что-то нужно посмотреть, лучше этот файлик тегнуть через собаку и посмотреть, потому что
10:18
Speaker A
если агент пойдёт это искать, он начнёт читать там какие у вас вообще файлы существуют. Это тоже потратит какое-то количество токенов. Потом он будет пытаться найти этот файл. Когда он его найдёт, уже будет там, ну, допустим, вместо одного вызова инструмента будет
10:31
Speaker A
там, ну, например, 10 вызовов инструментов. Поэтому, если у вас есть конкретика это конечно сложно достигать, когда у нас есть какой-то большой процесс. Но если вы просто в рамках какой-то маленькой задачи что-то делаете и понимаете, где её делать, то,
10:43
Speaker A
соответственно, просто укажите нужный файл. Кстати говоря, если вы указываете через собаку нужный файл, то вы тоже чуть-чуть доэкономите. То есть, если вы просто путь укажете полный, то агенту всё равно нужен будет инструмент вызвать для того, чтобы этот файл прочитать.
10:56
Speaker A
Если вы через собаку это делаете, то этот файл сразу прикрепляется к сессии. То есть вам не нужно будет вызывать на один инструмент больше. Это, конечно, сущие копейки, поэтому, ну, просто такой совет существует. Статьям, кстати, тоже был. Это просто тоже интересно. С кэшом
11:08
Speaker A
разобрались, контекстом разобрались. Двигаемся к выбору модели. Самая такая темка, которая, ну, не имеет на самом деле объективных ответов. У антропиков тоже есть статья, она вот 7 июля 2026 года вышла про выбор модели. И если сделать короткое summary, то нужно
11:24
Speaker A
думать так: если ваша задача простая, выбирайте модель поменьше. Если ваша задача сложная, выбирайте модель побольше. как будто бы мы и сами до этого не догадались. И про уровень усилий плюс-минус то же самое. Это effort. В основном рекомендуют просто
11:38
Speaker A
ставить дефолтный уровень усилий. То есть это будет такое идеальное соотношение цены качества. То есть сколько бы наибольшее количество людей были готовы заплатить за получение такого-то качества ответа. Поэтому, если вы вообще не хотите думать, то, соответственно, просто оставляйте то,
11:52
Speaker A
что было по умолчанию. Сейчас в клодкоде, кажется, это везде хай. Ну, по крайней мере, на OPus - это хай, на Fable - это тоже хай. Но всё-таки давайте об этом поговорим. какие-то очевидные моменты существуют, и лучше их придерживаться для того, чтобы ваши
12:04
Speaker A
лимиты были в целости и сохранности. Ну, например, если вы пришли в ваш проект и просто задали какой-нибудь вопрос в рамках этого проекта и делаете это на Fable, то это, конечно же, будет дорого.
12:14
Speaker A
То есть, если вы просто хотите спросить, как у вас что-то работает в проекте, ну, забыли вы, допустим, то здесь может справиться даже Sonet. То есть, если вы максимально хотите увеличить эффективность использования токенов, вы можете и тот же Sonet вызвать. Ну, если
12:26
Speaker A
не получится у него ответить наш вопрос, о'кей, переключитесь, ничего страшного, но я уверен, что получится. Потому что для того, чтобы ответить на этот вопрос, нужно просто посмотреть, как оно реализовано. Не нужно реализовывать что-то новое. Ну и, соответственно, даже
12:37
Speaker A
если вы просто это сделаете не на Fable, а хотя бы уже на опус, то у вас уже в два раза меньше потратится лимитов. То есть здесь, конечно, нужно каждому выбирать, то есть смотря какие у вас цели. Вот в моём случае, например, если
12:48
Speaker A
я не [откашливается] активно работаю, то есть у меня просто какая-то рутина наклоде, допустим, помогает он мне там видео монтировать, ещё какие-то вещи делать и, может быть, поддерживать проекты, там закрывать баги, ещё что-то, то мне иногда может хватать и 5x. Вот
13:00
Speaker A
если бы ещё пятичасовых лимитов не было, то вообще было бы замечательно. Но если у меня какой-то активный старт проекта, то просто перехожу на 20x, потому что, ну, я вам покажу сейчас на бенефшмарках, почему я не использую тот же Sunet, хотя
13:10
Speaker A
в некоторых задачах, конечно же, можно его использовать. С моделями разобрались. Теперь давайте посмотрим, что андропики с вами говорят про уровень усилий, то есть про эfort. Уровень усилий - это не только время на обдумывание, то есть это влияет на то,
13:22
Speaker A
сколько будет он файлов считывать, насколько тщательно проводится проверка и насколько далеко система продвигается по многоэтапной задаче, прежде чем связаться с вами. То есть, если у нас низкий уровень усилий, то модель будет прилагать меньше усилий для того, чтобы довести задачу до конца перед тем, как
13:37
Speaker A
просто прийти к вам и сказать, что делать. Здесь так и написано. При более низком уровне усилий он предпочтёт запросить у вас больше контекста, чем тратить токены. Лично мне на том, что рекомендуют, сложно делать какие-то выводы. То есть понятно, что можно
13:49
Speaker A
сделать какие-то косвенные выводы, но они все субъективные. То есть если кто-то мне рассказывает, что вот эту модель вот с этим уровнем усилий обязательно нужно использовать для кодинга. Ну, честно говоря, я к этому серьёзно не отношусь. Если вы пойдёте
14:01
Speaker A
просто послушайте 10 разных мнений, то поймёте, что ни одну из моделей нельзя вообще использовать. У всех разные задачи, у всех разный контекст, у всех разные инструменты внутри харнеса.
14:10
Speaker A
Поэтому оценивать модель по мнению какого-то конкретного человека с непонятным набором инструментов, ну, я считаю, что это не особо правильно. Вы и моё мнение, конечно же, должны фильтровать и сами можете опираться на те источники, которым вы доверяете.
14:22
Speaker A
Поэтому единственное, на что лично я предпочитаю опираться - это на бенчмарке, потому что это хотя бы какое-то измерение. Мой текущий сертап такой, и я сейчас объясню, почему он такой. Во-первых, я делаю брейншторм на опусе или Fable. То есть, если мне
14:36
Speaker A
позволяют лимиты, я это делаю на Fable. Не могу здесь даже объяснить, на самом деле, объективно, почему на Fable, но мне как будто бы больше вайп Брейншторма с Fable нравится. По крайней мере, вот когда первый раз его зарелизили, это
14:47
Speaker A
точно было сильно выше уровнем, чем был опус. Когда его уже порезали, ну, стало похуже, конечно, но тем не менее именно вот обсуждение каких-то задач мне нравится с FA. Обычно у меня стоит хай, то есть то, что стоит по умолчанию в
15:00
Speaker A
клод-коде. Иногда перехожу на x. Опять же исходя из вот этой логики. То есть, если мы выкручиваем уровень усилий больше, то модель сделает больше самостоятельных действий до того, как спросит что-то у вас. Теперь про сам кодинг. Здесь чуть попроще, потому что
15:14
Speaker A
мы можем опираться на какие-то бенчмарки. Если вот этому бенчмарку, например, верить, а этот бенчмарк отвечает за то, что йтенер, то есть тот, кто ответственный за кодовую базу, принял бы этот merch requкquest. То есть не просто тесты какие-то пройдены, а что
15:26
Speaker A
код написан качественно. Понятно, что это тоже не до конца объективно, но тем не менее, если вот мы опираемся на бенчмарке, то в целом как будто бы код можно писать на opus 5 medмедиум. Далее, если мы посмотрим на Deepsv, этот
15:38
Speaker A
benchmark отвечает за то, что агент может решить какую-то длинную задачу, то здесь мы опять же видим, ну, во-первых, да, вот я говорил про санет, ну, смотрим, да, вот где sonнеet, где opus.
15:48
Speaker A
Если мы говорим про тот же бенчмарк, который только что смотрели, опять же, где sonнеet, где опус. Ну, понятно, что где-то здесь есть пересечение, но опять же это не то, чтобы супективно, но я для себя решил, что просто мне нет никакого
15:58
Speaker A
смысла пытаться играться с Сонетом, пытаться сделать какой-то классификатор, который точно будет те задачи, которые Sнеet может сделать, сделать. Ну, то есть я просто не готов тратить на это своё время, поэтому я пишу код на опусе.
16:10
Speaker A
То есть здесь мы получаем, что медиум вполне себе справляется с длинными задачами, в том числе. Поэтому, если у нас задачи ещё и короткие, то медиум, как будто бы это какая-то золотая середина, если мы пишем код. Опять-таки, обычно, когда выходит какая-то модель,
16:23
Speaker A
они подсвечивают какие-то лучшие бенчмарки этой модели, конечно же. И здесь опять мы видим, ну, плюс-минус похожую картину, да, что low сильно ниже, чем medium, а дальше уже, ну, понятно, что всё-таки скоро растёт. Ну вот, допустим, здесь мы понимаем, что
16:35
Speaker A
даже если вы вот выбираете максимальное, то нет смысла, допустим, выбирать макс. Если смотрим на следующий бенчмарк, здесь тоже видим, что нет никакого смысла идти выше, чем xig. То есть здесь уже разница вообще будет неощутимая. Да, даже здесь, на самом деле, разница будет
16:47
Speaker A
неощутимая. И так далее. То есть вот так вот вы можете нащупать плюс-минус, какой уровень эфтанга вам подходит. Короче говоря, в результате вот этих всех вводных, то есть на что влияет уровень усилий, на бенчмарки, которые связаны с кодингом, я для себя решил, что я могу в
17:03
Speaker A
рамках вот своего процесса, когда у меня есть Fable OP для оркестрации и брейншторма, то есть у них есть план, который они держат и понимают, что происходит в субагентах, то я могу себе позволить снизить свои расходы, переключив агента, который кодит. То
17:19
Speaker A
есть у него есть понятные задачи, он пишет код по Тdд, то есть сначала пишет тесты, и потом, если я буду проверять это всё ревьювером на хай, то есть на опус хай, то как будто бы в среднем я всё равно получу хай, то есть дефолтную
17:32
Speaker A
модель. Поэтому это просто способ у меня экономить чуть-чуть токенов на достаточно большое количество действий, потому что написание кода - это большое количество действий. Поэтому мой текущий сетап такой, но если не хотите заморачиваться, как будто бы можно просто всё делать на опус хай. Если вам
17:47
Speaker A
нужно экономить лимиты, то вот на это место можно, соответственно, ставить OP medium либо брать Sonet. Но, как мы видели, даже если в сонете выкрутить там уровень усилий, он всё равно не достигает результатов опуса. Тут уж смотрите, как вам более комфортно с
18:02
Speaker A
точки зрения затрат. Ну либо можно вообще идти там выбирать, допустим, модели, которые просто стоят дешевле.
18:07
Speaker A
Ну, например, вам нравится брейнштормить и нравится, как оркестрируют модели клода. Вы можете, например, задачи делегировать тому же кодексу, потому что у них сильно дешевле и качество, ну, если опять-таки пойти посмотреть на бренчмарки они ну сопоставимые.
18:20
Speaker A
Соответственно, если вы просто смотрите по бенчмаркам или кто-то, кому вы доверяете, рассказывает о том, что эта модель делает тоже хорошо, ну, соответственно, вы можете просто большую часть работы делегировать более дешёвым моделям. Ну вот примерно все советы, как удешевить использование клод-кода, то
18:35
Speaker A
есть кэш, контекст и модели. Не забываем, что если мы уходим более чем на 1 час, то делаем компакт, а лучше вообще завершать сессию. А сессия для этого должна быть небольшой. То же самое следим за тем, что у нас находится в
18:47
Speaker A
контексте. То есть, если у вас накопилось большое количество мусора, надо его почистить. Смотрим вот это видео и понимаем, как это всё почистить.
18:53
Speaker A
Ну и в конечном итоге играемся с моделями. Если не хотите играться, просто берите Opus High и делайте всё на OPUS High. Это плюс-минус будет идеальное соотношение цена качества.
19:03
Speaker A
Если хотите экономить, как я уже сказал, можно ставить на большой объём задачи модель, либо помладше, либо effort поменьше, но потом делать ревью моделью, у которой будет либо effor, либо просто сама модель будет побольше. Вот такая вот история, по моему мнению, является
19:18
Speaker A
адекватной. Ну, а на этом предлагаю завершать. Если какие-то советы показались полезными, интересными, обязательно нажимаем лайк, подписываемся, пишем какой-нибудь комментарий. Ну а все, кто хочет научиться вайп-кодить на простых шагах, с простых промтов и доходя уже до каких-то готовых процессов, залетаем в
19:32
Speaker A
IT гараж. Ну и спасибо за просмотр.
Topics:Claude CodeAnthropicкэшированиетокеныэкономияискусственный интеллектмодели ИИоптимизация контексталимиты токеновкодинг

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

Or transcribe another YouTube video here →