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
KRUHLYK 🇺🇦
Релізнули GPT-5.5 Шо там: краще працює з кодом і задачами, потребує менше пояснень, ефективний як AI-агент. Тести: GPT-5.5 — 82.7% Claude — 69.4% Mythos — 82.0% (не публічний) Хто на Codex, відпишіться що там на практиці і в реальності, якщо є можливість…
Хто там хотів бенчмарків і порявнянь з клодом (я хотів).
Ось вам порівняння Codex на GPT5.5 і Claude Code на Opus 4.7. Задачі не реальні в житті і притягнуто за вуха, але висновки робіть самі.
Ось вам порівняння Codex на GPT5.5 і Claude Code на Opus 4.7. Задачі не реальні в житті і притягнуто за вуха, але висновки робіть самі.
X (formerly Twitter)
Nate Herk (@nateherk) on X
I Tested GPT 5.5 vs Opus 4.7: What You Need to Know
Кому нести свої гроші?
Вже декілька місяців я пробую знайти максимально підходящого для всіх моїх щоденних потреб вендора AI інструментів. Задача в цьому максимально проста — мати одну підписку і не розкидатись грошима всім навколо, тим більше підписки не такі вже дешеві, погодьтесь. Такий собі добровільний Vendor Lock 💁♂️
Потреби в мене наступні:
1. Робота з чат ботом в багатьох побутових питаннях
2. Робота агентів з кодом
3. Робота з YouTube
4. Робота з зображеннями
5. Наявність можливості формувати спеціалізованих ботів для специфічних завдань (читай можливість записати системний промпт для чат бота щоб не дублювати його постійно)
Так вже ринок формується, що найпростіше в цих вимогах обирати між великою трійкою гравців на ринку: OpenAI, Anthropic, Google.
OpenAI: ChatGPT, Codex
Я вже десь приблизно півроку не користуюсь продуктами OpenAI. Чому? По-перше, якість того, що мені почав видавати чат-бот на топових моделях мене геть не влаштовувало. Там був реально низькоякісний нейрослоп відверто, як на мене. Але там були GPTs. Заточені під специфічні задачі чат-боти з відповідними для них системними промптами. Було непогано, але моделі стали працювати гірше.
Codex. Востаннє я пробував з ним працювати ще на моделі GPT-5.3. На той момент він мені здався таким стронг мідлом, який гарно виконує поставлену задачу, але зі складними архітектурними чи аналітичними завданнями справлявся на відповідному рівні.
З того часу, за вашими відгуками, багато чого змінилось. А особливо з виходом GPT 5.5. Це треба тестити, але ж це +1 підписка за 20 баксів 🙄
Google Gemini
Після того як я відмовився від ChatGPT я вирішив спробувати Gemini. Особливо з огляду, що на той момент він вже був досить непоганим в плані якості роботи і можливостей. Плюс вбудовані інструменти для роботи з екосистемою Google (документи, диск, календар, YouTube) дуже підкуповували. А я людина, яка сьогодні працює на iPhone, а завтра може і на якомусь Android (мені не принципово насправді) і частіше за все на сервісах від гугла багато чого завʼязано і залишатись на одній кросплатформеній екосистемі зручніше в рази.
Але коли я почав юзати Gemini там не було чогось подібного до GTPs. Допоки не зʼявились Gems. Аналогічна GPTs річ. Робота із зображенями в Nano Banana 2 топова і поки що найкраща для менe. Нативна робота з YouTube, парсинг відео, доступ до інструментарію з відео.
І тут я такий "ОСЬ ВОНО!" Все, що мені потрібно для щоденної роботи, ще й Gemini CLI для роботи з кодом (про це далі). Та ще й підписку можна шерити з родиною і всі домочадці можуть юзати свої акаунти і свої ліміти в цьому. "КАЄФ!" — подумав я, але...
Gemini CLI
Агент для роботи з кодом і файловою системою в принципі. Наче виглядає як альтернатива Claude Code, до якого ще повернемось. Але дико не вистачало (не вистачає і зараз) всього того, що дає в плані інструментарію Claude. Та й результат моделі гугла дають дещо не такий, на який я звик у Anthropic 🤷♂️
Чи юзаю я його для роботи? Так, безперечно! Часто і досить активно. Чи можу я повністю на нього пересісти як на основне рішення? Точно ні.
Anthropic Claude
І ось він. Диявол, який все ламає.
Claude — це вже не про чат бота чи просто агента. Це ціла екосистема рішень, які в абсолютно різних сферах життя і роботи дають максимально класний результат... якщо тільки це не творчість. Але тут, скоріше за все, я користуюсь тим всім, як клешнями.
Однак, скільки б я не ганяв Calude для генерації текстів, ідей, всякої такої роботи, він все одно це робить гірше за той самий Gemini, як не крути. Принаймні у мене. Я вже мовчу за генерацію зображень. Вона класна на рівні малювання графіків, аналітики і всякого такого. Для чогось креативного — абсолютнашляпа капелюх. Знову ж таки суто для мене і того як я юзаю.
І знову але... мої потреби мати хорошу роботу з YouTube? А тут ніяк з тим, Claude не може нормально відео розпарсити і з нього дістати корисну інформацію.
Продовження далі 👇
Вже декілька місяців я пробую знайти максимально підходящого для всіх моїх щоденних потреб вендора AI інструментів. Задача в цьому максимально проста — мати одну підписку і не розкидатись грошима всім навколо, тим більше підписки не такі вже дешеві, погодьтесь. Такий собі добровільний Vendor Lock 💁♂️
Потреби в мене наступні:
1. Робота з чат ботом в багатьох побутових питаннях
2. Робота агентів з кодом
3. Робота з YouTube
4. Робота з зображеннями
5. Наявність можливості формувати спеціалізованих ботів для специфічних завдань (читай можливість записати системний промпт для чат бота щоб не дублювати його постійно)
Так вже ринок формується, що найпростіше в цих вимогах обирати між великою трійкою гравців на ринку: OpenAI, Anthropic, Google.
OpenAI: ChatGPT, Codex
Я вже десь приблизно півроку не користуюсь продуктами OpenAI. Чому? По-перше, якість того, що мені почав видавати чат-бот на топових моделях мене геть не влаштовувало. Там був реально низькоякісний нейрослоп відверто, як на мене. Але там були GPTs. Заточені під специфічні задачі чат-боти з відповідними для них системними промптами. Було непогано, але моделі стали працювати гірше.
Codex. Востаннє я пробував з ним працювати ще на моделі GPT-5.3. На той момент він мені здався таким стронг мідлом, який гарно виконує поставлену задачу, але зі складними архітектурними чи аналітичними завданнями справлявся на відповідному рівні.
З того часу, за вашими відгуками, багато чого змінилось. А особливо з виходом GPT 5.5. Це треба тестити, але ж це +1 підписка за 20 баксів 🙄
Google Gemini
Після того як я відмовився від ChatGPT я вирішив спробувати Gemini. Особливо з огляду, що на той момент він вже був досить непоганим в плані якості роботи і можливостей. Плюс вбудовані інструменти для роботи з екосистемою Google (документи, диск, календар, YouTube) дуже підкуповували. А я людина, яка сьогодні працює на iPhone, а завтра може і на якомусь Android (мені не принципово насправді) і частіше за все на сервісах від гугла багато чого завʼязано і залишатись на одній кросплатформеній екосистемі зручніше в рази.
Але коли я почав юзати Gemini там не було чогось подібного до GTPs. Допоки не зʼявились Gems. Аналогічна GPTs річ. Робота із зображенями в Nano Banana 2 топова і поки що найкраща для менe. Нативна робота з YouTube, парсинг відео, доступ до інструментарію з відео.
І тут я такий "ОСЬ ВОНО!" Все, що мені потрібно для щоденної роботи, ще й Gemini CLI для роботи з кодом (про це далі). Та ще й підписку можна шерити з родиною і всі домочадці можуть юзати свої акаунти і свої ліміти в цьому. "КАЄФ!" — подумав я, але...
Gemini CLI
Агент для роботи з кодом і файловою системою в принципі. Наче виглядає як альтернатива Claude Code, до якого ще повернемось. Але дико не вистачало (не вистачає і зараз) всього того, що дає в плані інструментарію Claude. Та й результат моделі гугла дають дещо не такий, на який я звик у Anthropic 🤷♂️
Чи юзаю я його для роботи? Так, безперечно! Часто і досить активно. Чи можу я повністю на нього пересісти як на основне рішення? Точно ні.
Anthropic Claude
І ось він. Диявол, який все ламає.
Claude — це вже не про чат бота чи просто агента. Це ціла екосистема рішень, які в абсолютно різних сферах життя і роботи дають максимально класний результат... якщо тільки це не творчість. Але тут, скоріше за все, я користуюсь тим всім, як клешнями.
Однак, скільки б я не ганяв Calude для генерації текстів, ідей, всякої такої роботи, він все одно це робить гірше за той самий Gemini, як не крути. Принаймні у мене. Я вже мовчу за генерацію зображень. Вона класна на рівні малювання графіків, аналітики і всякого такого. Для чогось креативного — абсолютна
І знову але... мої потреби мати хорошу роботу з YouTube? А тут ніяк з тим, Claude не може нормально відео розпарсити і з нього дістати корисну інформацію.
Продовження далі 👇
👍6
👆Продовження
GPTs, Gems або щось таке в Claude? А тут непевно зовсім. Є режим Projects, але це не зовсім те, що я очікував. Дуже схоже, дуже відповідно наче працює, але в самого Claude логіка в цьому режимі зовсім інша. Логіка роботи в цьому режимі не така, як мені потрібно.
Claude Cowork
Досить цікава фіча, і наразі я пробую її запровадити в свій робочий workflow. Та чи на стільки він корисний, що я без нього жити не можу — точно можу обійтись.
А от без чого я не можу обійтись — Claude Code.
Вся система тулзів, навколо яких побудований агентний режим, те як агент працює з ними, які моделі йому доступні і як вони відпрацьовують в якості мозку агента — це найкраще для мого робочого workflow і того, що я отримую на виході. Глибоко думаючий Opus, робочі руки у вигляді Sonnet, швидкий писака текстів Haiku... Всі ці хлопці дають мені топові результати в роботі. Плюс робоча корпоративна підписка для робочих проєктів та особиста підписка для моїх власних проєктів в додачу.
Тому вся оця двіжуха не дає мені можливості відмовитись від них на користь того ж Gemini. Ніяк. Поки що. На жаль. А я був би не проти, якби Gemini давав мені таке саме 🚬
І от, власне от і виходить, що мені доводиться платити двом вендорам за інструментарій, які мають одні або не мають інші.
І це мене дуже виморажує насправді. Я не хочу дохріна витрачати бабла на схожі інструменти. Я хочу використовувати те, що мені потрібно від кожного!
І тут моє ниття закінчується і виникає наступне питання до вас.
А як у вас в цьому плані? Чи маєте ви такі самі чи схожі проблеми? Давайте обговоримо це в коментарях, мені дійсно цікаво! 👇
GPTs, Gems або щось таке в Claude? А тут непевно зовсім. Є режим Projects, але це не зовсім те, що я очікував. Дуже схоже, дуже відповідно наче працює, але в самого Claude логіка в цьому режимі зовсім інша. Логіка роботи в цьому режимі не така, як мені потрібно.
Claude Cowork
Досить цікава фіча, і наразі я пробую її запровадити в свій робочий workflow. Та чи на стільки він корисний, що я без нього жити не можу — точно можу обійтись.
А от без чого я не можу обійтись — Claude Code.
Вся система тулзів, навколо яких побудований агентний режим, те як агент працює з ними, які моделі йому доступні і як вони відпрацьовують в якості мозку агента — це найкраще для мого робочого workflow і того, що я отримую на виході. Глибоко думаючий Opus, робочі руки у вигляді Sonnet, швидкий писака текстів Haiku... Всі ці хлопці дають мені топові результати в роботі. Плюс робоча корпоративна підписка для робочих проєктів та особиста підписка для моїх власних проєктів в додачу.
Тому вся оця двіжуха не дає мені можливості відмовитись від них на користь того ж Gemini. Ніяк. Поки що. На жаль. А я був би не проти, якби Gemini давав мені таке саме 🚬
І от, власне от і виходить, що мені доводиться платити двом вендорам за інструментарій, які мають одні або не мають інші.
І це мене дуже виморажує насправді. Я не хочу дохріна витрачати бабла на схожі інструменти. Я хочу використовувати те, що мені потрібно від кожного!
І тут моє ниття закінчується і виникає наступне питання до вас.
А як у вас в цьому плані? Чи маєте ви такі самі чи схожі проблеми? Давайте обговоримо це в коментарях, мені дійсно цікаво! 👇
👍4💯4