← всі звіти · competitor-stack-analysis-v2-2026-05-12.md

type: analysis title: OpenCode + Claude Code + Hermes — Wins/Losses таблиці для запозичення date: 2026-05-12 author: VPS Claude trigger: Сергій 2026-05-12 voice — «людською мовою, що ми можемо зробити і що це може дати» ref: competitor-stack-analysis-2026-05-12.md (v1, технічне порівняння)

Що ми можемо запозичити — людською мовою з Wins/Losses

Розшифровка термінів (за результатами web search)

Whisper транскрипція трохи поплутала імена:

Як прозвучало	Насправді	Що це
«OpenClaw»	OpenCode (sst opencode.ai)	Open-source AI coding agent на TypeScript/Bun. Має SDK для Node.js, агенти (Build + Plan), terminal-native.
«Cot Cloud»	Claude Code (Anthropic)	Той самий рантайм що у нас
«Hermes»	Hermes Agent (Nous Research)	Provider-agnostic agent з persistent memory. SQLite + FTS5 + LLM summarization. 110k stars за 10 тижнів — найшвидше зростаючий agent framework 2026.

Архітектура колеги: 3 агенти (OpenCode + Claude Code + Hermes) читають/пишуть ОДНУ markdown папку. Це federation pattern — те, що ми реалізували через outbox/inbox + Federation Broker, але «слабше» (event-based, не shared filesystem state).

Multi-agent на shared memory — наш великий «loose»

	Колега	Ми
Архітектура	3 агенти ↔ одна папка	2 інстанси Claude Code (VPS + Desktop) + outbox/inbox
Кожен агент бачить state	Так, миттєво (filesystem)	Тільки після перенесення файла через outbox
Конфлікти (race condition)	Можливі — два агенти пишуть одночасно	Виключено — кожен має свою копію
Specialization	OpenCode — кодинг, Hermes — пам'ять, Claude Code — orchestration	Лише Claude Opus + sub-agents (PM-agent, dev-crew via Gemini)
Resilience	Якщо один впав — інші тримають state	Якщо VPS впав — Desktop sync via git, але delay

Що це нам дає якщо перейдемо на multi-agent shared memory:

✅ Якщо я (Claude Code на VPS) тимчасово недоступний — Hermes продовжує писати у memory
✅ Спеціалізація: OpenCode для коду, Hermes для довгої пам'яті, Claude Code для orchestration
✅ Швидший recovery — state на диску, не у конкретному процесі

Що це ускладнить:

❌ Race conditions: два агенти пишуть decisions_log.md одночасно → merge conflict
❌ Втрата фокусу: «один Claude Opus з повним контекстом» vs «3 агенти що не повністю розуміють один одного»
❌ Setup complexity: 3× config, 3× API keys, 3× memory model
❌ Cost: Hermes free якщо local LLM, але quality нижча; з cloud-моделями = 3× плата

Vердикт: NOT YET worth it для нас. Ми multi-host (VPS + Desktop), не multi-agent. Це дві різні стратегії resilience. Шукаємо «один великий мозок» з durable state — у нас вже є через git/wiki/memory.

Wins/Losses по конкретним рекомендаціям

Рекомендація 1: JSON-індекс над wiki

Що зробити: скрипт що сканить YAML frontmatter всіх index.md файлів у /srv/wiki/ і робить один .index.json — швидкий lookup без grep.

Як це працює зараз у нас: коли я хочу знайти «що знаємо про Menopace» — гоню grep -r menopace /srv/wiki/ або викликаю AgentDB semantic search (~150ms). Жодного індексу немає.

Wins:

⚡ Lookup O(1) замість O(n) grep — миттєво
🎯 Точніше за semantic search для «структурних» запитів (продукт X має ціну Y? Хто owner?)
📊 Можна збудувати dashboard «всі продукти з readiness <50%» через jq на JSON
🤖 PM-agent зможе швидше працювати — індекс готовий

Losses:

🔄 Треба cron щохвилини / щогодини щоб освіжати — інакше stale
🐛 Якщо frontmatter поламаний — JSON ламається теж (треба validation)
💾 +1 MB на диску
🧠 Ще один файл який треба пам'ятати про оновлення

Effort: 1 година (Python script + cron) ROI: ⭐⭐⭐⭐⭐ (high impact, low cost) Verdict: ✅ Робимо першим

Рекомендація 2: WAL session state

Що зробити: файл current-session-state.md (~2KB) куди я пишу «зараз роблю Х» ДО того як зробити. Якщо crash між дією і записом результату — наступна сесія знає де перервалось.

Як зараз: decisions_log пишеться ПІСЛЯ значущих дій (часто наприкінці сесії). Якщо Claude crash під час 5-годинного marathon — все що зробив за останню годину губиться.

Wins:

🛡 Crash-safety — VPS перезавантажується, network drop, мій timeout → state збережено
🔍 Visibility: «що Claude робить ПРЯМО зараз» — Сергій може зайти у memory і подивитись
📜 Audit trail — корисно для відлагодження «чому я зробив X»
🤝 Multi-agent ready — якщо колись додамо ще один runtime, він прочитає current-session-state

Losses:

✍️ Кожна значуща дія = file write (overhead 5-10ms)
🌀 Якщо забудеш почистити після session end → stale state у наступну сесію
📁 Ще один файл у memory що треба читати на старті

Effort: 1 година ROI: ⭐⭐⭐⭐ (medium-high — крах не часто, але коли стається — критично) Verdict: ✅ Робимо другим

Рекомендація 3: Soul файл (виокремити філософію з rules.md)

Що зробити: з rules.md (зараз 17 пунктів змішаних правил) виокремити «hard-baked цінності» (хто я, стиль, межі) у core/soul.md. Tactical правила лишаються у rules.md.

Як зараз: rules.md — і філософія («завжди українською», «MVP-first», «короткі чіткі відповіді») і tactical («якщо задача не завершена → open-tasks.md»). Все в одному.

Wins:

🧘 Менше cognitive load: soul читається рідше (стабільне), rules — частіше (живі)
🔄 Tactical rules можна змінювати без боязні зачепити «душу»
📜 Якщо новий агент (наприклад OpenCode) приєднається — він read только soul, без tactical noise

Losses:

🗂 Ще один файл (тоді SessionStart hook читає 2 файли замість 1)
🤔 Грань між «філософія» і «правило» нечітка — буде сваритись з самим собою куди писати
⏰ 30 хв роботи + регулярна підтримка двох файлів

Effort: 30 хв ROI: ⭐⭐ (cosmetic, не критично) Verdict: 🟡 Опціонально — якщо буде час

Рекомендація 4: JSONL auto-compaction

Що зробити: скрипт що моніторить JSONL транскрипти. При перетині threshold (наприклад 50K рядків або 100KB) робить Claude summary call → старі повідомлення замінюються summary + .checkpoint.jsonl зберігає original.

Як зараз: JSONL ростуть лінійно. Marathon-сесія 5 годин = JSONL ~1-5 MB. SessionStart hook читає тільки tail, не повний файл. Але токени контексту при resume — повний JSONL.

Wins:

💰 Економія токенів — на довгих сесіях $$$
⚡ Швидший resume — менше тексту читати
🧠 Concentration: summary краще ніж 100 turn-ів сирого контексту

Losses:

🤖 Один extra Claude call per compaction (~$0.10-0.30)
🐛 Summary може втратити нюанси — «забути» важливе
🔧 Складність: треба правильно вибирати threshold + summary prompt
📦 Дiск-spend на checkpoint файли (хоча їх можна архівувати)

Effort: 2 години ROI: ⭐⭐⭐ (medium — у нас сесії <5 год, рідко перевищують contextWindow) Verdict: 🟡 Робимо коли почнуть бути 10+ годинні sessions

Рекомендація 5: Team State runtime (агенти пишуть статуси)

Що зробити: team-state.md (~6KB) де кожен агент (VPS Claude, Desktop Claude, PM-agent, dev-crew, agent-db) пише секцію зі статусом, last task, блокерами. SessionStart читає першим.

Як зараз: agents_inventory.md — статичний реєстр («хто існує»). Runtime state — нема. Я не знаю чи PM-agent щойно щось зробив, чи Desktop Claude дописав до wiki за останні 5 хв.

Wins:

👀 Visibility multi-agent — я знаю що Desktop робить ПРЯМО зараз
🤝 Coordination — VPS Claude не повторює роботу яку щойно зробив Desktop
🚨 Блокери одразу видно — «PM-agent чекає Сергія approve»
🧰 Federation Broker integration ready

Losses:

📝 Кожен агент має писати у файл — треба добавити lockwise чи append-only
🌀 Стале state — якщо агент впав, його секція виглядає актуальною (потрібен heartbeat timestamp)
🔧 Federation Broker треба налаштувати щоб всі агенти знали де файл
👻 «Phantom agents» — секція яка ніколи не оновлюється

Effort: 3 години (core + Federation Broker integration) ROI: ⭐⭐⭐⭐ (важливо для multi-agent, але у нас все ще mostly single-agent) Verdict: 🟡 Робимо коли Federation Broker буде у production

Рекомендація 6: Curated business data folder + analyst agent

Що зробити: /srv/wiki/business/{clients,brands,people}/ з картками. Окремий agent (PM-agent extension чи новий cron) раз/тиждень оновлює план/факт з BQ, дебіторку з Creatio CRM.

Як зараз: business data розкидана: delta-medical/products-brands.md, deltamedical_brands_full.md (в memory), Looker Studio дашборди, BQ datasets. Жодного єдиного «гарного» місця.

Wins:

🎯 Single source curated business state — «де ми по плану на Menopace?» = 1 файл
🤖 PM-agent extension auto-updates — не треба руками тримати актуальним
📊 Reports Hub може робити dashboard «всі бренди + readiness» з цього
🧠 Я можу швидше відповідати на бізнес-питання (не питати Сергія)

Losses:

🔌 Залежність від BQ + Creatio API — якщо вони впали, дані stale
🏗 Багато роботи: ~16 брендів × 3 виміри (план/факт/дебіторка) = щотижня 50+ updates
🔒 Sensitivity — business data чутливі, треба під auth (internal subdomain)
🤖 Новий агент = новий тех-долг

Effort: 4 години (структура) + 4 години (agent integration) = ~8 годин ROI: ⭐⭐⭐⭐⭐ (long-term, але big payoff) Verdict: 🟢 Великий wins, але це окремий проєкт. SPARC-методологія підходить.

Multi-agent setup (OpenCode + Hermes + Claude Code)

Тут окремо — це фундаментальне архітектурне рішення.

Аспект	Wins (плюси)	Losses (мінуси)
Resilience	✅ Якщо один runtime crashes — інші продовжують	❌ Race conditions при write
Specialization	✅ Кожен tool для свого: OpenCode-кодинг, Hermes-пам'ять, Claude Code-orchestration	❌ Розмиття фокусу — «хто головний?»
Cost	🟡 Hermes можна на local Ollama (free)	❌ 3× API ключі + 3× tracking витрат
Setup	—	❌ 3× config, 3× system prompts, 3× memory model
Memory	✅ Спільна папка — миттєвий sync	❌ Локі / семафори / merge conflicts
Vendor lock	✅ Provider-agnostic (Hermes може на OpenAI / Claude / local)	—
Quality	🟡 Найкращий tool для кожної задачі	❌ Quality fragmentation — один tool gives 9/10, інший 7/10
Learning curve	—	❌ Сергій має пам'ятати 3 різних UX

Альтернативи для нас:

Альтернатива	Що дає	Що ускладнить
Status quo: Claude Code + sub-agents (PM-agent, dev-crew Gemini)	Простота, один primary	Single point of failure (якщо Claude API down — все стоїть)
Додати Hermes для пам'яті	Persistent memory + FTS5 search = AgentDB++	Setup Ollama, новий runtime, +API key якщо cloud
Додати OpenCode для кодингу	Спеціалізований coding agent	Дублюємо Claude Code функції; коли використовувати який?
Full multi-agent (3 runtime)	Як у колеги, max resilience	Складно maintain. Worth it якщо команда >5 людей.

Vердикт: NOT YET для нас. Ми все ще «1 Сергій + 2 Claude'и» (VPS + Desktop). Multi-agent має сенс коли:

5+ людей працює з однією memory
Specialization платить (наприклад дев-команда + sales + PM)
Не вистачає resilience поточного setup

Натомість варто розглянути Hermes як замінник AgentDB — їх FTS5 + LLM summarization кращі за наш paraphrase-MiniLM. Це 1 agent додаткова, не 3.

Зведена пріоритизація

#	Що	Effort	ROI	Wins	Losses	Verdict
1	JSON-індекс wiki	1 год	⭐⭐⭐⭐⭐	швидкий lookup, jq queries	stale ризик	✅ Робимо першим
2	WAL session state	1 год	⭐⭐⭐⭐	crash-safe, visibility	overhead на write	✅ Робимо другим
3	Soul файл	30 хв	⭐⭐	clear separation	додатковий файл	🟡 Якщо буде час
4	JSONL compaction	2 год	⭐⭐⭐	економія токенів	summary втрачає нюанси	🟡 Коли сесії 10+ год
5	Team State runtime	3 год	⭐⭐⭐⭐	multi-agent visibility	stale state, locks	🟡 Після Federation Broker prod
6	Business folder + analyst	8 год	⭐⭐⭐⭐⭐	single source bus data	API залежність	🟢 Окремий SPARC-проект
7	Hermes як replacement AgentDB	4 год	⭐⭐⭐	FTS5 + LLM summary > MiniLM	новий runtime	🟡 Експеримент потім
8	Full multi-agent setup	20+ год	⭐⭐	max resilience	складно maintain	🔴 NOT yet for us

Що рекомендую робити прямо зараз

Швидкий wins блок (2 години):

JSON-індекс wiki (Sprint 1)
WAL session state (Sprint 2)

Це закриває 2 з 8 рекомендацій з максимальним ROI. Без міняння архітектури.

Експеримент на потім:

Hermes Agent paralelno з нашим AgentDB. Замінити якщо кращий.
Multi-agent setup — оглядати знову коли команда зросте до 5+ людей.

SPARC-проект:

Curated business folder з analyst-agent (8 годин, потребує business stakeholder buy-in від Сергія).

Skip:

Full multi-agent на shared memory — не варто для нашого scale.
Soul файл — cosmetic, не критично.
LightRAG — overkill для нашого корпусу.

Sources

OpenCode (sst opencode.ai) — open-source AI coding agent, TypeScript/Bun
Hermes Agent (Nous Research GitHub) — persistent memory + SQLite FTS5
Hermes Agent vs Claude Code — порівняння для нашого case
The New Stack: persistent-ai-agents-compared — multi-agent context
Vellum: Hermes Agent alternatives 2026 — 10 best alternatives