Есть ещё неочевидный, ускользающий от внимания большинства момент про стоимость. Каждый tool call агента отправляет в API весь накопленный контекст -- все предыдущие запросы и ответы. Первый вызов -- 3k токенов, десятый -- уже 30k, двадцать пятый -- 65k. Это арифметическая прогрессия, сумма растёт квадратично от числа итераций.
Prompt caching снижает стоимость пересчёта, но за передачу кэшированных токенов всё равно нужно платить. Квадратичность остаётся. O(n²) живёт в протоколе, это следствие stateless HTTP-API и накопления контекста. Чем больше итераций нужно инструменту -- тем дороже каждый следующий шаг.
Забить итерациями до отсечки окно 200к Opus-a обходится примерно в 30 у.е., а сделать то же самое в 1M окне -- это уже 700 у.е.. Разница по бюджету ×23, а не ×5. Просто сейчас вендоры активно субсидируют расходы пользователей. Но эта щедрость не вечна и не бесконечна.
jdtls-lsp -- полезная вещь для автономных сценариев, когда агент работает один, без IDE, с чистого листа. Но в парной работе, когда Eclipse уже запущен и настроен -- форматтер, чекстайл, тест-лаунчер, свои чекеры, плагины -- всё под проект. Поднимать рядом ещё один headless Eclipse с отдельным индексом потом избыточно. Это как третья нога при ходьбе.
Всё, что даёт LSP-плагин (диагностика, навигация), в IDE уже есть и работает точнее, потому что это ваш настроенный workspace. JDT CLI Bridge просто выставляет это наружу.
К слову, про jdtls-lsp -- типичная ситуация: https://github.com/anthropics/claude-code/issues/17643 — на Windows плагин не работает из-за обратных слешей в file:// URI. Баг открыт, подтверждён множеством пользователей, воспроизводится до последней версии -- и тишина. Один из комментаторов https://github.com/anthropics/claude-code/issues/17643: "These are not edge cases, these are basic smoke test type defects." При 5500+ открытых issues в репозитории Claude Code ждать починки можно долго — проще сделать самому.
Лимитов по токенам хватило на задачу? Я так понимаю, там тариф 16 евро в месяц? А как делали? Всё в их облаке или есть какие-то CLI для неё? Первый раз про Figma Make слышу.. Простите, за нубские вопросы, просто раз это туториал, то может они уместны будут здесь.
В Claude Code несмотря на буквальную формулировку в его системном промте: "Do NOT use the Bash to run commands when a relevant dedicated tool is provided" - я регулярно вижу, как модель скатывается к sed, awk, echo >, cat <<EOF и разным самопальным python-скриптам, когда внезапно нарывается на проблемы со вставкой своих патчей или вопросы с кодировками/переносами строк. Это очень раздражает ещё и потому, что клод код тогда требует явного подтверждения действия от пользователя. А с его однопотончной хук моделью это означает, что и другие агенты в это время ждут в очереди, что бы продолжить работу. Из-за этого невозможно отойти от монитора даже на пару минут. Один запутавшийся агент блокирует всех остальных.
Плюсанул. Это движение в правильном направлении, особенно, когда речь идет про полную автономность агентов.
Но для парной работы в специализированных средах -- и, особенно, когда вокруг все LLM-вендоры борются с тем, что бы их подписку не использовали в "самопальных" решениях и конкурентах (Opencode, OpenClaw и т.д.), когда уже начата открытая война с создатеями альтернативных агентных сред (зачастую гораздо более качественных, чем тот же Антигравити или Клод Код) -- не получится придумать ничего более естественного, чем CLI-шлюз к процессу твоей программы.
И дело ещё в cвободе, неохота оказаться в ситуации, как с ремонтом тракторов John Deere/заправкой картриджей HP -- когда ты, купив вещь, становишься рабом её дилера. И не можешь там даже лампочку поменять, без риска потери гарантии.
Десятки всяких песочниц уже есть. Начиная с docker sandobx и gVisor (на которых облачный клод код работает) и заканчивая всякими менее распространенными вариантами.
Спасибо за отзыв. LSP (или любой другой отдельный вычислительный процесс на стороне) был отброшен на ранней стадии — он не подходил под задачу. Мне нужно было вытаскивать информацию из процесса именно моей IDE. Нужны были именно её маркеры компиляции, её чекстайл, её тест-лаунчер и так далее. Отдельный Language Server — это отдельный индекс, отдельный build state, и он неизбежно рассинхронизируется с тем, что вы видите в IDE.
LSP — слишком низкоуровневая вещь, заточенная под редактор. Это протокол не для людей и не для агентов. textDocument/references с позиционными координатами в JSON-RPC — попробуйте это отдебажить руками. Даже если вы его как-то подключите — не факт, что ваша модель захочет этим пользоваться и не соскочит на свои фолбэки после первой же неудачи. Кто хоть немного поработал с кодинг-агентами — тот сразу поймёт, о чём речь. Модель нужно ещё убедить, что данный инструмент лучше и полезнее, чем то, на чём её тренировали. Агент обучен на grep/find, он к ним тянется рефлекторно. CLI с понятными командами (jdt refs, jdt err) имеет куда больше шансов быть подхваченным моделью, чем LSP JSON-RPC.
Кажется, что в Anthropic всем навязали KPI на медиаприсутствие. Вместо того, что бы фиксить 5500+ багов в своем Claide Code (на самом деле их гораздо больше - просто они закрываются автоматически) -- их контора фокусируются на cоздании разных хелло-вордных MVP, лишь имитирующих развитие и дающих повод о себе напомнить.
Расскажите, зачем вообще нужен RAG в 2026 году? Получать ответ за одну итерацию инференса? Добивать промт от юзера релевантным мусором? Я просто хочу разобраться.. как это ПРАВИЛЬНО готовить? Поверх серч резалтов выполнять саммаризацию, как это делает гугл? Но компилятору требуется точный ответ, а не отписка... Какой профит с этого? Наличие полученной по неизвестным для модели правилам RAG-выдачи в контексте как-то побуждает её серьезнее относиться к задаче, она будет меньше сочинять и выдумывать? Где эта ниша, где RAG -- непоколебимый король?
Да, такой подход работает для любого софта, который позволяет собрать себя из исходников или расширить плагинами. Если у инструмента есть API — внутренний, плагинный, какой угодно — этого достаточно, чтобы вытянуть из него нити управления наружу и сделать доступным для агента. По сути, это универсальный рецепт пульта дистанционного управления для чего угодно.
Да, с обычным CLI не нужно сочинять и расписывать все эти фильтрующие/лимитирующие параметры для каждой команды с теоретически большим выводом -- агенты обычно сами подстраховывают tail/head-ами. С CLI не нужен MCP Inspector и т.п. отладочные инструменты. CLI есть у докера, авс, сентри, гитхаба и т.д. --- и агенты с ними прекрасно ладят. Просто MCP создан для немного для другого уровня интеграции (когда у агента нет баша), а когда терминал есть -- то CLI-утилита/скрипт это более подходящий способ расширения функционала агента: нет проблем с раздутым описанием инструментов -- не рассказал агенту - он и не знает ничего, а когда задача требует навыка -- то просто используешь скилл, в котором описано, как пользоваться твоими CLI/скриптами. Все просто.
Буквально вчера, 19 февраля 2026, Anthropic официально обновила документацию и окончательно закрыла лазейки.
Что официально разрешено с подпиской Pro/Max (без API-ключа):
Claude.ai — веб, десктоп, мобилка. Без вопросов.
Claude Code (официальный CLI) — единственный инструмент разработки, который Anthropic официально включила в подписку. Это всё. Больше ничего официального нет.
Anthropic обновила документацию, уточнив, что использование OAuth-токенов с любыми сторонними инструментами нарушает условия использования. OAuth-токены из планов Free, Pro и Max предназначены исключительно для Claude Code и Claude.ai — использование этих токенов в любых других продуктах, инструментах или сервисах, включая Agent SDK, является нарушением условий.
Что раньше работало, а теперь заблокировано: Под удар попали: OpenCode, Cline (через OAuth), RooCode, Cursor (когда использовался как прокси для подписки). Cline и RooCode, которые использовали подписочные кредиты Claude, тоже сломались.
Этому товарищу бы лучше за своей кривой терминальной поделкой следить (6200+ issues на Github), а не по интервью ходить.
У Claude Code до сих пор все внутренние и внешние хуки живут в одном треде с UI event loop. Из-за этого всё хозяйство безбожно тормозит и клинит при любом параллельном запуске или объемном выводе, засыпая консоль react-эксепшенами из субагентов и выжирая 100% CPU на ровном месте.
Про отсутствие контроля над субагентами я вообще молчу: те часто игнорируют инструкции, залезают куда попало, там застревают в хуках (особенно Sonnet со своей любовью к баш-пайплайнам) -- и пока пользователь не нажмет "No", все остальные агенты в это время стоят в очереди. А ещё бесконтрольная компактификация. Она затирает историю и для агента, и для человека! Она трет контекст как захочет, включая и то, что было положено программистом в Claude.md. В итоге проще вообще не доводить диалог до компактификации, и вести разработку в своих собственных roadmap-файлах и своими ссылками на правила бутстрапить контекст.
Невозможно троттлить скорость работы субагентов, ставить на паузу или возобновлять работу. Некоторые вещи до сих пор проще и экономнее в старом Claude Desktop c голыми mcp сделать -- чем пытаться воевать с Claude Code. Их контекстые rules до сих не работают и затягиваются в контекст сразу все (и так же потом игнорируются компактификацией). Две разных системы хуков для главного агента и для субагентов. Субагенты живут в одной сессии с главным агентом. Без серьезных плясок с бубном в хуках невозможно отличить какой именно субагент вызывает сейчас инструмент, какой какой тип, айди у суб-агента.
Все это в совокупности убивает весь UX Claude Code. И если бы не принудительная привязка подписки к нему -- большинство бы уже давно перешло в другие агентные среды.
О том, что вирус разработан в Иране, может свидетельствовать то, что IP-адрес, с которого осуществляется атака на IoT-гаджеты, принадлежит иранскому провайдеру.
Darksend это такой же миксер как и миксеры Bitcoin. Он опциональный и на практике еще и очень медленный, у людей уходили дни чтобы смиксовать пару сотен долларов. Все это приправлено мастернодами, которые являются ни чем иным как MLM, Ponzi схемой для поднятия цены, не существует такой технологии как Proof of Service, все это snake-oil и подвержено Sybil-атакам. Иными словами, мастернода может получать награду с блоков просто отвечая на пинги и не делая нужной от нее работы (микширование, голосование и тд).
Про негативный баланс могу сказать, что это очень технические детали и надо смотреть whitepaper RingCT, но в XMR можно определить если произошла скрытая эмиссия из-за какого-нибудь бага, а вот в ZCash это невозможно. То есть сейчас можно точно сказать, что скрытой эмиссии нет, а про ZCash такое сказать нельзя.
Кстати, все коины на zerocash уже были похачены и хакеры понавыпускали себе бабла, но там был счетчик, а в zcash его нет из-за особенностей технологии, так что оно даже хуже zerocash.
Есть ещё неочевидный, ускользающий от внимания большинства момент про стоимость. Каждый tool call агента отправляет в API весь накопленный контекст -- все предыдущие запросы и ответы. Первый вызов -- 3k токенов, десятый -- уже 30k, двадцать пятый -- 65k. Это арифметическая прогрессия, сумма растёт квадратично от числа итераций.
Prompt caching снижает стоимость пересчёта, но за передачу кэшированных токенов всё равно нужно платить. Квадратичность остаётся. O(n²) живёт в протоколе, это следствие stateless HTTP-API и накопления контекста. Чем больше итераций нужно инструменту -- тем дороже каждый следующий шаг.
Забить итерациями до отсечки окно 200к Opus-a обходится примерно в 30 у.е., а сделать то же самое в 1M окне -- это уже 700 у.е.. Разница по бюджету ×23, а не ×5. Просто сейчас вендоры активно субсидируют расходы пользователей. Но эта щедрость не вечна и не бесконечна.
jdtls-lsp -- полезная вещь для автономных сценариев, когда агент работает один, без IDE, с чистого листа. Но в парной работе, когда Eclipse уже запущен и настроен -- форматтер, чекстайл, тест-лаунчер, свои чекеры, плагины -- всё под проект. Поднимать рядом ещё один headless Eclipse с отдельным индексом потом избыточно. Это как третья нога при ходьбе.
Всё, что даёт LSP-плагин (диагностика, навигация), в IDE уже есть и работает точнее, потому что это ваш настроенный workspace. JDT CLI Bridge просто выставляет это наружу.
К слову, про jdtls-lsp -- типичная ситуация: https://github.com/anthropics/claude-code/issues/17643 — на Windows плагин не работает из-за обратных слешей в file:// URI. Баг открыт, подтверждён множеством пользователей, воспроизводится до последней версии -- и тишина. Один из комментаторов https://github.com/anthropics/claude-code/issues/17643: "These are not edge cases, these are basic smoke test type defects." При 5500+ открытых issues в репозитории Claude Code ждать починки можно долго — проще сделать самому.
Лимитов по токенам хватило на задачу? Я так понимаю, там тариф 16 евро в месяц? А как делали? Всё в их облаке или есть какие-то CLI для неё? Первый раз про Figma Make слышу.. Простите, за нубские вопросы, просто раз это туториал, то может они уместны будут здесь.
В Claude Code несмотря на буквальную формулировку в его системном промте: "Do NOT use the Bash to run commands when a relevant dedicated tool is provided" - я регулярно вижу, как модель скатывается к sed, awk, echo >, cat <<EOF и разным самопальным python-скриптам, когда внезапно нарывается на проблемы со вставкой своих патчей или вопросы с кодировками/переносами строк. Это очень раздражает ещё и потому, что клод код тогда требует явного подтверждения действия от пользователя. А с его однопотончной хук моделью это означает, что и другие агенты в это время ждут в очереди, что бы продолжить работу. Из-за этого невозможно отойти от монитора даже на пару минут. Один запутавшийся агент блокирует всех остальных.
Плюсанул. Это движение в правильном направлении, особенно, когда речь идет про полную автономность агентов.
Но для парной работы в специализированных средах -- и, особенно, когда вокруг все LLM-вендоры борются с тем, что бы их подписку не использовали в "самопальных" решениях и конкурентах (Opencode, OpenClaw и т.д.), когда уже начата открытая война с создатеями альтернативных агентных сред (зачастую гораздо более качественных, чем тот же Антигравити или Клод Код) -- не получится придумать ничего более естественного, чем CLI-шлюз к процессу твоей программы.
И дело ещё в cвободе, неохота оказаться в ситуации, как с ремонтом тракторов John Deere/заправкой картриджей HP -- когда ты, купив вещь, становишься рабом её дилера. И не можешь там даже лампочку поменять, без риска потери гарантии.
Десятки всяких песочниц уже есть. Начиная с docker sandobx и gVisor (на которых облачный клод код работает) и заканчивая всякими менее распространенными вариантами.
Спасибо за отзыв. LSP (или любой другой отдельный вычислительный процесс на стороне) был отброшен на ранней стадии — он не подходил под задачу. Мне нужно было вытаскивать информацию из процесса именно моей IDE. Нужны были именно её маркеры компиляции, её чекстайл, её тест-лаунчер и так далее. Отдельный Language Server — это отдельный индекс, отдельный build state, и он неизбежно рассинхронизируется с тем, что вы видите в IDE.
LSP — слишком низкоуровневая вещь, заточенная под редактор. Это протокол не для людей и не для агентов. textDocument/references с позиционными координатами в JSON-RPC — попробуйте это отдебажить руками. Даже если вы его как-то подключите — не факт, что ваша модель захочет этим пользоваться и не соскочит на свои фолбэки после первой же неудачи. Кто хоть немного поработал с кодинг-агентами — тот сразу поймёт, о чём речь. Модель нужно ещё убедить, что данный инструмент лучше и полезнее, чем то, на чём её тренировали. Агент обучен на grep/find, он к ним тянется рефлекторно. CLI с понятными командами (jdt refs, jdt err) имеет куда больше шансов быть подхваченным моделью, чем LSP JSON-RPC.
Кажется, что в Anthropic всем навязали KPI на медиаприсутствие. Вместо того, что бы фиксить 5500+ багов в своем Claide Code (на самом деле их гораздо больше - просто они закрываются автоматически) -- их контора фокусируются на cоздании разных хелло-вордных MVP, лишь имитирующих развитие и дающих повод о себе напомнить.
Расскажите, зачем вообще нужен RAG в 2026 году? Получать ответ за одну итерацию инференса? Добивать промт от юзера релевантным мусором? Я просто хочу разобраться.. как это ПРАВИЛЬНО готовить? Поверх серч резалтов выполнять саммаризацию, как это делает гугл? Но компилятору требуется точный ответ, а не отписка... Какой профит с этого? Наличие полученной по неизвестным для модели правилам RAG-выдачи в контексте как-то побуждает её серьезнее относиться к задаче, она будет меньше сочинять и выдумывать? Где эта ниша, где RAG -- непоколебимый король?
Да, такой подход работает для любого софта, который позволяет собрать себя из исходников или расширить плагинами. Если у инструмента есть API — внутренний, плагинный, какой угодно — этого достаточно, чтобы вытянуть из него нити управления наружу и сделать доступным для агента. По сути, это универсальный рецепт пульта дистанционного управления для чего угодно.
Да, с обычным CLI не нужно сочинять и расписывать все эти фильтрующие/лимитирующие параметры для каждой команды с теоретически большим выводом -- агенты обычно сами подстраховывают tail/head-ами. С CLI не нужен MCP Inspector и т.п. отладочные инструменты. CLI есть у докера, авс, сентри, гитхаба и т.д. --- и агенты с ними прекрасно ладят. Просто MCP создан для немного для другого уровня интеграции (когда у агента нет баша), а когда терминал есть -- то CLI-утилита/скрипт это более подходящий способ расширения функционала агента: нет проблем с раздутым описанием инструментов -- не рассказал агенту - он и не знает ничего, а когда задача требует навыка -- то просто используешь скилл, в котором описано, как пользоваться твоими CLI/скриптами. Все просто.
Буквально вчера, 19 февраля 2026, Anthropic официально обновила документацию и окончательно закрыла лазейки.
Что официально разрешено с подпиской Pro/Max (без API-ключа):
Claude.ai — веб, десктоп, мобилка. Без вопросов.
Claude Code (официальный CLI) — единственный инструмент разработки, который Anthropic официально включила в подписку. Это всё. Больше ничего официального нет.
Anthropic обновила документацию, уточнив, что использование OAuth-токенов с любыми сторонними инструментами нарушает условия использования. OAuth-токены из планов Free, Pro и Max предназначены исключительно для Claude Code и Claude.ai — использование этих токенов в любых других продуктах, инструментах или сервисах, включая Agent SDK, является нарушением условий.
Что раньше работало, а теперь заблокировано:
Под удар попали: OpenCode, Cline (через OAuth), RooCode, Cursor (когда использовался как прокси для подписки). Cline и RooCode, которые использовали подписочные кредиты Claude, тоже сломались.
Этому товарищу бы лучше за своей кривой терминальной поделкой следить (6200+ issues на Github), а не по интервью ходить.
У Claude Code до сих пор все внутренние и внешние хуки живут в одном треде с UI event loop. Из-за этого всё хозяйство безбожно тормозит и клинит при любом параллельном запуске или объемном выводе, засыпая консоль react-эксепшенами из субагентов и выжирая 100% CPU на ровном месте.
Про отсутствие контроля над субагентами я вообще молчу: те часто игнорируют инструкции, залезают куда попало, там застревают в хуках (особенно Sonnet со своей любовью к баш-пайплайнам) -- и пока пользователь не нажмет "No", все остальные агенты в это время стоят в очереди. А ещё бесконтрольная компактификация. Она затирает историю и для агента, и для человека! Она трет контекст как захочет, включая и то, что было положено программистом в Claude.md. В итоге проще вообще не доводить диалог до компактификации, и вести разработку в своих собственных roadmap-файлах и своими ссылками на правила бутстрапить контекст.
Невозможно троттлить скорость работы субагентов, ставить на паузу или возобновлять работу. Некоторые вещи до сих пор проще и экономнее в старом Claude Desktop c голыми mcp сделать -- чем пытаться воевать с Claude Code. Их контекстые rules до сих не работают и затягиваются в контекст сразу все (и так же потом игнорируются компактификацией). Две разных системы хуков для главного агента и для субагентов. Субагенты живут в одной сессии с главным агентом. Без серьезных плясок с бубном в хуках невозможно отличить какой именно субагент вызывает сейчас инструмент, какой какой тип, айди у суб-агента.
Все это в совокупности убивает весь UX Claude Code. И если бы не принудительная привязка подписки к нему -- большинство бы уже давно перешло в другие агентные среды.
accept interfaces, return concrete types
Откуда информация такая?
Так себе доказательство, если честно..
А как фермеры и конвейеры связаны?
Кстати, все коины на zerocash уже были похачены и хакеры понавыпускали себе бабла, но там был счетчик, а в zcash его нет из-за особенностей технологии, так что оно даже хуже zerocash.