Дивні дива продовжують відбуватись у Anthropic навколо Claude.
Ви писали в чаті, а також в соцмережах пишуть, що ніби-то антропіки прибрали доступ до Claude Code з Pro тарифів.
Пишуть, що така дивна поведінка зачіпила ~2% НОВИХ користувачів сайту, а згодом все повернулось назад. Це точно банальне A/B тестування для користувачів.
Наразі всі доступи і тарифи на місці. Проте, це жжжжжж точно не просто так. Продовжуємо спостерігати. Явно щось буде змінюватись.
Добрий ранок! ☕️
Ви писали в чаті, а також в соцмережах пишуть, що ніби-то антропіки прибрали доступ до Claude Code з Pro тарифів.
Пишуть, що така дивна поведінка зачіпила ~2% НОВИХ користувачів сайту, а згодом все повернулось назад. Це точно банальне A/B тестування для користувачів.
Наразі всі доступи і тарифи на місці. Проте, це жжжжжж точно не просто так. Продовжуємо спостерігати. Явно щось буде змінюватись.
Добрий ранок! ☕️
🤬3😱1
Давайте під цим постом ділитись РЕАЛЬНИМИ кейсами розходу лімітів на різних тарифах у CC.
Спробуємо плюс-мінус реальну статистику зібрати вже на досить великому проміжку часу, коли така проблема зʼявилась.
Спробуємо плюс-мінус реальну статистику зібрати вже на досить великому проміжку часу, коли така проблема зʼявилась.
Ну і, власне, думка, якою я з вами постійно ділюсь.
Зазначу лише, що окрім навичок користування агентами на рівні хоча б більшого за запитати у чата погоду на завтра, потрібно мати хоча б базові навички і розуміння архітектури, патернів, клін коду в тому стеку, з яким ви працюєте.
Тому так, хто досі не погнав ці хвости підтягувати, буде дуже важко в майбутньому як мінімум.
Час коли знання мови і фреймворку були достатніми закінчується дуже стрімко.
Зазначу лише, що окрім навичок користування агентами на рівні хоча б більшого за запитати у чата погоду на завтра, потрібно мати хоча б базові навички і розуміння архітектури, патернів, клін коду в тому стеку, з яким ви працюєте.
Тому так, хто досі не погнав ці хвости підтягувати, буде дуже важко в майбутньому як мінімум.
Час коли знання мови і фреймворку були достатніми закінчується дуже стрімко.
1👍15🤬2🥴1🗿1
KRUHLYK 🇺🇦 pinned «Давайте під цим постом ділитись РЕАЛЬНИМИ кейсами розходу лімітів на різних тарифах у CC. Спробуємо плюс-мінус реальну статистику зібрати вже на досить великому проміжку часу, коли така проблема зʼявилась.»
KRUHLYK 🇺🇦
Сьогодні от прямо свято якесь. Ще й репозиторій з сетапом під Claude Code набрав першу сотню зірок. Це капець як мотивує!
Отже, я потестував сетапчик на реальних задачаї в РІЗНИХ проєктах з РІЗНОЮ складністю. Ділюсь звітом. Все що там написано являється планом для покращень і трансформацій 😎
Що ПРАЦЮЄ надійно:
1. Triage і перший dispatch.
Decision tree простий і конкретний: Bug → debugger, Feature → ba, Infra → devops. Модель (особливо Opus) це розуміє і виконує. Перший subagent dispatch відбувається в 9 з 10 випадків.
Чому 90%, а не 100%? Є edge cases:
- Задача на межі "trivial" і "feature" — модель може вирішити зробити сама
- Коли пишу "just quickly fix this CSS" — модель сприймає як trivial
- Довгий, складний промпт — модель починає "думати" замість dispatch
2. Orchestrator не чіпає код.
Це працює для Opus. Модель дійсно уникає відкривання project files в більшості випадків. Але це prompt-based обмеження, не enforcement. В settings.json deny list є тільки .env. Модель технічно МОЖЕ прочитати будь-який файл — вона просто "обіцяє" не робити цього. Тут, знаю при ці штуки, свідомо їх поки суворо не обмежував. Поінт на допрацювання.
3. Subagent dispatch (Agent tool)
Виклик конкретного агента через Agent({ subagent_type: "ba", prompt: "..." }) — це стандартна, стабільна функція Claude Code. Subagents працюють в ізольованому context window, отримують промпт від оркестратора, виконують роботу, повертають результат. Тут сюрпризів не побачив, але і стабільний відсоток спрацювання десь на рівні ~85%. Чи це повʼязано з тяжінням моделей до креатив, чи в принципі воно в мене так працює поки не зрозумів.
Що ФРАГІЛЬНЕ (працює іноді):
1. Передача контексту між фазами.
Pipeline передбачає:
BA → output → Developer → output → Quality Gate → output → Docs Writer
І тут я побачив проблему, коли output одного агента стає input наступного. Оркестратор має:
1. Отримати повний результат від BA
2. Зрозуміти його
3. Сформулювати промпт для Developer з урахуванням BA output
4. Передати цей промпт
На практиці, оркестратор часто "спрощує" при передачі. BA може видати 20 user stories з acceptance criteria, а оркестратор передасть developer'у стислий summary. І насправді це фундаментальна проблема LLM: модель "розуміє" задачу по-своєму і намагається бути helpful, замість того щоб точно ретранслювати output. Це чітко видно по тому аутпуту навіть якщо подивитись як агент "думає" на фоні і які "думки" видає.
Конкретний приклад, який я побачив: developer отримує: "Implement user registration with email verification" замість повного BA звіту з user stories, edge cases, і acceptance criteria.
2. Agent Teams (TeamCreate + паралельний Quality Gate).
Те, про що я казав. Agents Teams фіча експерементальна і ПОКИ ЩО працює дуже нестабільно для якісного стабільного результату. Надійно спрацьовує десь у половині випадків.
TeamCreate("qg-user-registration")
→ spawn tester, reviewer, security-scanner, qa
→ wait for all 4 to complete
→ collect reports
→ decide pass/fail
→ TeamDeleteОсь такий пайплайн для QA тіми.
Це 6+ кроків координації. В реальності:
- Один з 4 агентів може зависнути або вичерпати context
- Оркестратор може не дочекатись всіх і продовжити з частковими результатами
- TeamDelete може не відбутись при помилці
- Якщо Quality Gate фейлить → back to developer → re-run — це вже 2 цикли координації, де кожен може зламатись
Полазив по редіту, по форумах і от що накопав. Agent Teams працюють найкраще для "constrained, well-scoped scenarios" — 2-3 агенти з чіткими межами. 4 паралельні агенти в quality gate — це на межі того, що працює стабільно.
6. Devil's Advocate взаємодія.
Planning Team з devil, ba, ddd-architect в реальності:
- devil має чекати на SendMessage від ba/ddd-architect
- Потім challenge через SendMessage
- Потім чекати відповідь
- Потім вирішити: accept чи escalate
Це 4+ раунди асинхронного спілкування між 3 агентами. Кожен round — це можливість втратити контекст, отримати timeout, або отримати відповідь яку devil не може правильно оцінити. На практиці devil часто або мовчить (не отримує тригер), або челенжить все підряд без розбору. Тобто ідея кльова, але потребує великих допрацювань.
Що ПРАЦЮЄ надійно:
1. Triage і перший dispatch.
Decision tree простий і конкретний: Bug → debugger, Feature → ba, Infra → devops. Модель (особливо Opus) це розуміє і виконує. Перший subagent dispatch відбувається в 9 з 10 випадків.
Чому 90%, а не 100%? Є edge cases:
- Задача на межі "trivial" і "feature" — модель може вирішити зробити сама
- Коли пишу "just quickly fix this CSS" — модель сприймає як trivial
- Довгий, складний промпт — модель починає "думати" замість dispatch
2. Orchestrator не чіпає код.
Це працює для Opus. Модель дійсно уникає відкривання project files в більшості випадків. Але це prompt-based обмеження, не enforcement. В settings.json deny list є тільки .env. Модель технічно МОЖЕ прочитати будь-який файл — вона просто "обіцяє" не робити цього. Тут, знаю при ці штуки, свідомо їх поки суворо не обмежував. Поінт на допрацювання.
3. Subagent dispatch (Agent tool)
Виклик конкретного агента через Agent({ subagent_type: "ba", prompt: "..." }) — це стандартна, стабільна функція Claude Code. Subagents працюють в ізольованому context window, отримують промпт від оркестратора, виконують роботу, повертають результат. Тут сюрпризів не побачив, але і стабільний відсоток спрацювання десь на рівні ~85%. Чи це повʼязано з тяжінням моделей до креатив, чи в принципі воно в мене так працює поки не зрозумів.
Що ФРАГІЛЬНЕ (працює іноді):
1. Передача контексту між фазами.
Pipeline передбачає:
BA → output → Developer → output → Quality Gate → output → Docs Writer
І тут я побачив проблему, коли output одного агента стає input наступного. Оркестратор має:
1. Отримати повний результат від BA
2. Зрозуміти його
3. Сформулювати промпт для Developer з урахуванням BA output
4. Передати цей промпт
На практиці, оркестратор часто "спрощує" при передачі. BA може видати 20 user stories з acceptance criteria, а оркестратор передасть developer'у стислий summary. І насправді це фундаментальна проблема LLM: модель "розуміє" задачу по-своєму і намагається бути helpful, замість того щоб точно ретранслювати output. Це чітко видно по тому аутпуту навіть якщо подивитись як агент "думає" на фоні і які "думки" видає.
Конкретний приклад, який я побачив: developer отримує: "Implement user registration with email verification" замість повного BA звіту з user stories, edge cases, і acceptance criteria.
2. Agent Teams (TeamCreate + паралельний Quality Gate).
Те, про що я казав. Agents Teams фіча експерементальна і ПОКИ ЩО працює дуже нестабільно для якісного стабільного результату. Надійно спрацьовує десь у половині випадків.
TeamCreate("qg-user-registration")
→ spawn tester, reviewer, security-scanner, qa
→ wait for all 4 to complete
→ collect reports
→ decide pass/fail
→ TeamDeleteОсь такий пайплайн для QA тіми.
Це 6+ кроків координації. В реальності:
- Один з 4 агентів може зависнути або вичерпати context
- Оркестратор може не дочекатись всіх і продовжити з частковими результатами
- TeamDelete може не відбутись при помилці
- Якщо Quality Gate фейлить → back to developer → re-run — це вже 2 цикли координації, де кожен може зламатись
Полазив по редіту, по форумах і от що накопав. Agent Teams працюють найкраще для "constrained, well-scoped scenarios" — 2-3 агенти з чіткими межами. 4 паралельні агенти в quality gate — це на межі того, що працює стабільно.
6. Devil's Advocate взаємодія.
Planning Team з devil, ba, ddd-architect в реальності:
- devil має чекати на SendMessage від ba/ddd-architect
- Потім challenge через SendMessage
- Потім чекати відповідь
- Потім вирішити: accept чи escalate
Це 4+ раунди асинхронного спілкування між 3 агентами. Кожен round — це можливість втратити контекст, отримати timeout, або отримати відповідь яку devil не може правильно оцінити. На практиці devil часто або мовчить (не отримує тригер), або челенжить все підряд без розбору. Тобто ідея кльова, але потребує великих допрацювань.
👍11❤6
KRUHLYK 🇺🇦
Ну і, власне, думка, якою я з вами постійно ділюсь. Зазначу лише, що окрім навичок користування агентами на рівні хоча б більшого за запитати у чата погоду на завтра, потрібно мати хоча б базові навички і розуміння архітектури, патернів, клін коду в тому…
Читаючи вакансію, яку мені надіслали рекрутери 💁♂️
🤣7
Pavilas Korop зробив невелике опитування серед своїх підписників. Ось вам середні зарплати розробників в Литві.
Оригінальний пост тут
Оригінальний пост тут
👍11😢5
Claude Managed Agents тепер мають вбудовану пам'ять
Anthropic випустили оновлення, яке серйозно змінює підхід до роботи з агентами: тепер вони вміють зберігати контекст між різними сесіями. Це фактично вирішує проблему «чистого аркуша», коли кожну нову розмову доводилося починати з довгих інструкцій.
Функція наразі перебуває у статусі публічного бета-тестування, але вже зараз демонструє потенціал для серйозної автоматизації.
Головні переваги:
1. Не потрібно повторюватися. Ви один раз пояснюєте агенту правила неймінгу, структуру проєкту або свої вподобання в архітектурі, і він записує це у свою пам'ять (директорія /memories). У наступних сесіях він уже знає, що робити.
2. Безперервне навчання. Агент може фіксувати свої помилки або успішні рішення. Якщо він один раз зрозумів, як працює ваш специфічний API, він не забуде про це наступного разу.
3. Повний контроль. Усі «спогади» — це текстові файли. Ви можете переглядати їх через audit logs, редагувати, видаляти або встановлювати режим «лише для читання», щоб агент випадково нічого не змінив.
Додаткова фішка в тому, що цю пам’ять можна шерити з командою.
Це перетворює Claude Managed Agents на повноцінних цифрових співробітників, які накопичують досвід і стають ефективнішими з кожним виконаним завданням.
Оригінальна стаття
Anthropic випустили оновлення, яке серйозно змінює підхід до роботи з агентами: тепер вони вміють зберігати контекст між різними сесіями. Це фактично вирішує проблему «чистого аркуша», коли кожну нову розмову доводилося починати з довгих інструкцій.
Функція наразі перебуває у статусі публічного бета-тестування, але вже зараз демонструє потенціал для серйозної автоматизації.
Головні переваги:
1. Не потрібно повторюватися. Ви один раз пояснюєте агенту правила неймінгу, структуру проєкту або свої вподобання в архітектурі, і він записує це у свою пам'ять (директорія /memories). У наступних сесіях він уже знає, що робити.
2. Безперервне навчання. Агент може фіксувати свої помилки або успішні рішення. Якщо він один раз зрозумів, як працює ваш специфічний API, він не забуде про це наступного разу.
3. Повний контроль. Усі «спогади» — це текстові файли. Ви можете переглядати їх через audit logs, редагувати, видаляти або встановлювати режим «лише для читання», щоб агент випадково нічого не змінив.
Додаткова фішка в тому, що цю пам’ять можна шерити з командою.
Це перетворює Claude Managed Agents на повноцінних цифрових співробітників, які накопичують досвід і стають ефективнішими з кожним виконаним завданням.
Оригінальна стаття
👍16🔥5❤2
Claude Code: Офіційне визнання деградації
Якщо останнім часом у вас виникало бажання посперечатися з Claude Code через його раптову лінь та космічні рахунки за токени — видихніть. Виявилося, що це не ви стали гірше ставити технічні завдання, а система справді працювала з помилками. Anthropic опублікували технічний розбір, де підтвердили три критичні баги.
На початку березня компанія вирішила пришвидшити роботу Claude Code, перевівши його з режиму глибоких міркувань (High reasoning) на середній рівень (Medium). На практиці це вилилося в те, що модель почала на 70% менше заглиблюватися в контекст файлів. Claude почав видавати поверхневі рішення, використовувати криптичні імена змінних та впевнено звітувати про виконання завдань, які насправді навіть не починав.
2. Дорога розмова про гроші
Найбільш іронічний баг стосувався обробки запитів. Через помилку в середовищі Bun, будь-яка згадка термінів, пов'язаних з оплатою або лімітами в історії чату, ламала механізм кешування. Як результат — кожен наступний запит оброблявся як абсолютно новий, що збільшувало витрати токенів у 10–20 разів. Фактично, спроба зекономити призводила до ще більших витрат.
3. Ефект перемішування
Ще одна технічна проблема виникала під час відновлення сесій за допомогою прапорців
Що робити?
Розробники запевняють, що самі моделі не «тупішали» — проблема була лише в інфраструктурі. Наразі всі баги виправлено у версії 2.1.116. Користувачам, чиї токени зникли через ці помилки, обіцяють скинути ліміти використання.
Якщо ви відкладали Claude Code через його раптову неадекватність, зараз найкращий час оновитися та дати йому ще один шанс. Принаймні тепер він знову має почати читати ваш код перед тим, як його ламати.
Якщо останнім часом у вас виникало бажання посперечатися з Claude Code через його раптову лінь та космічні рахунки за токени — видихніть. Виявилося, що це не ви стали гірше ставити технічні завдання, а система справді працювала з помилками. Anthropic опублікували технічний розбір, де підтвердили три критичні баги.
На початку березня компанія вирішила пришвидшити роботу Claude Code, перевівши його з режиму глибоких міркувань (High reasoning) на середній рівень (Medium). На практиці це вилилося в те, що модель почала на 70% менше заглиблюватися в контекст файлів. Claude почав видавати поверхневі рішення, використовувати криптичні імена змінних та впевнено звітувати про виконання завдань, які насправді навіть не починав.
2. Дорога розмова про гроші
Найбільш іронічний баг стосувався обробки запитів. Через помилку в середовищі Bun, будь-яка згадка термінів, пов'язаних з оплатою або лімітами в історії чату, ламала механізм кешування. Як результат — кожен наступний запит оброблявся як абсолютно новий, що збільшувало витрати токенів у 10–20 разів. Фактично, спроба зекономити призводила до ще більших витрат.
3. Ефект перемішування
Ще одна технічна проблема виникала під час відновлення сесій за допомогою прапорців
--resume або --continue. Через помилку в SDK порядок інструментів у запиті змінювався, що автоматично анулювало кеш. Для великих проєктів це означало постійне перечитування всього обсягу коду «з нуля» на кожному кроці, що миттєво спалювало ліміти.Що робити?
Розробники запевняють, що самі моделі не «тупішали» — проблема була лише в інфраструктурі. Наразі всі баги виправлено у версії 2.1.116. Користувачам, чиї токени зникли через ці помилки, обіцяють скинути ліміти використання.
Якщо ви відкладали Claude Code через його раптову неадекватність, зараз найкращий час оновитися та дати йому ще один шанс. Принаймні тепер він знову має почати читати ваш код перед тим, як його ламати.
🥴6😁4🤣2