Стаття містить глибокий технічний аналіз витікшого коду Claude Code (v2.1.88) від 31 березня 2026 року, розглядаючи його як цінний випадок, що розкриває архітектуру передових інженерних рішень для AI Agent.

Автор статті, джерело: Max

Сьогодні (31 березня 2026 року) Anthropic знову виставила повний фронтенд та вихідний код останньої версії Claude Code (v2.1.88) у сховищі npm через низькорівневу помилку у процесі пакування.

Користувач опублікував файл cli.js.map, який не був видалений, що дозволило відновити приблизно 1900 файлів і понад 510 тисяч рядків вихідного коду TypeScript.

Для Anthropic це ще одна серйозна порушення OpSec після витоку документації моделі Mythos кілька днів тому.

Але для розробників та галузевих дослідників, що працюють у сфері застосування великих моделей, цей вихідний код є повною, надзвичайно цінною біллою з інженерної архітектури передових AI Agent.

Поза межами спорів щодо відповідності та витоків даних, я витратив певний час на глибокий аналіз цього вихідного коду локально.

Якщо сприймати це не як чутки, а як випадок архітектури виробничого AI-асистента для програмування, тут міститься багато інженерних рішень, що виходять за межі традиційного мислення.

Ось детальний технічний розбір архітектури, механізмів планування, системи пам’яті та стратегій безпеки Claude Code з об’єктивної точки зору.

Стаття довга і підходить для фахівців, які працюють з AI Infra, розробкою агентів та цікавляться архітектурою застосункового рівня великих моделей.

ЧАСТИНА.01 Це не просто інструмент CLI

З структури каталогів (близько 40 первинних модулів у src/) видно, що складність Claude Code значно перевищує складність сучасних відкритих звичайних однорідних агентів на ринку.

Його вибір технічного стеку дуже практичний і зосереджений на досвіді взаємодії з користувачем:

Мова — TypeScript, середовище виконання — Bun з більш агресивною продуктивністю, CLI-фреймворк — Commander, а термінальний шар відображення — несподівано React + Ink.

Чому інструмент командного рядка використовує React?

Відповідь дає файл screens/REPL.tsx у вихідному коді (понад 5005 рядків).

У сценаріях потокового виведення великих моделей (Streaming) та паралельного виконання кількох інструментів управління станом інтерфейсу користувача стає надзвичайно складним (наприклад, одночасне відображення процесу міркувань, індикаторів прогресу виклику інструментів, попереднього перегляду коду Diff тощо).

Використання декларативного React у поєднанні з мінімалістичним налаштуванням власного Store за стилем Zustand (state/store.ts) — це найкраща інженерна практика для обробки таких частих локальних оновлень.

У режимі роботи система строго поділена на два типи:

Інтерактивний режим REPL: інтерфейс терміналу з використанням Ink, розроблений переважно для розробників-людей.

Режим без інтерфейсу/SDK (клас QueryEngine): повне видалення інтерфейсу, підтримка потокового виведення JSON. Це закладає основу для подальшого вбудовування його як нижчого рівня в IDE (наприклад, у формі, подібній до Cursor) або у процеси CI/CD.

Процес запуску системи також був оптимізований для максимальної паралельності.

У файлі main.tsx I/O-інтенсивні операції, такі як читання конфігурації (MDM Settings) та попереднє отримання ключів Keychain, виконуються у дочірніх процесах паралельно з завантаженням основного модуля тривалістю приблизно 135 мс. Ця вимога до мілісекундної оптимізації часу запуску пронизує весь кодовий базис.

ЧАСТИНА 02. Інженерія кешу підказок

Це найбільш технічно складна частина повного коду та основна перешкода, що відрізняє досвід Claude Code від звичайних застосунків з оболонкою.

Наразі інструменти Agent при обробці довгих контекстів часто просто та грубо конкатенують System Prompt та історію діалогу.

У файлі services/api/claude.ts (який містить 3419 рядків — основний модуль взаємодії) збір промптів виконується з байт-рівневою точністю.

Відомо, що механізм кешу запитів Anthropic використовує співпадіння префіксів (Prefix Matching).

Для максимізації частоти спрацьовування кешу Claude Code розробив детально продуману архітектуру сегментованого кешу:

Статичний розділ (глобально кешований): генерується за допомогою systemPromptSection(), містить опис ідентичності моделі («Ви — Claude Code...»), системні правила безпеки, обмеження стилю коду, базові рекомендації щодо використання інструментів тощо. Ця частина майже не змінюється протягом усього життєвого циклу сесії.

Динамічна межа: у вихідному коді жорстко закодовано спеціальний маркер SYSTEM_PROMPT_DYNAMIC_BOUNDARY.

Динамічний блок (кешування на рівні сесії/без кешування): містить дані з високою частотою змін, такі як інформація про поточний каталог роботи (CWD), стан Git, інструкції MCP (Model Context Protocol) та користувацькі налаштування.

А щоб запобігти проникненню кешу через незначні зміни в запиті, система виконала велику кількість на перший погляд складних заходів щодо забезпечення відмовостійкості:

Визначений порядок: описи інструментів, переданих великою моделлю, строго сортується за алфавітом за допомогою вбудованого префікса інструменту + суфікса MCP.
Хеш-відображення шляхів: шлях до профілю не використовує випадкові UUID, а використовує хеш на основі вмісту, щоб уникнути знищення кешу через зміну шляху при кожній ін'єкції.
Статус зовнішній: навіть список поточних доступних агентів було видалено з описів інструментів і переміщено до додатків повідомлення (Attachments). Згідно з коментарями у вихідному коді, лише ця зміна зменшила споживання токенів для створення кешу приблизно на 10,2%.

Все це свідчить про поточний стан галузі: на цьому етапі видатна розробка додатків ШІ суттєво полягає у жадібному й досконалому витискуванні вартості систем кешування API.

ЧАСТИНА.03 Інструменти та потокове паралельне виконання

Claude Code містить понад 40 інструментів (включаючи читання та запис файлів, виконання Bash, веб-скрапінг тощо), а архітектура системи інструментів використовує високомодульний шаблон фабрики (Factory Pattern).

Кожен інструмент успадковує базовий інтерфейс Tool і повинен реалізовувати методи, такі як checkPermissions(), validateInput() та isConcurrencySafe() (чи безпечний для паралельного виконання).

Механізм ToolSearch із завантаженням за потребою: коли кількість інструментів перевищує певний поріг, включення описів усіх інструментів у Prompt призведе до неприйнятних витрат на Token.

У вихідному коді показано елегантну стратегію під назвою ToolSearch: неключові інструменти (наприклад, певні аналітичні плагіни) позначені як defer_loading: true.

Модель не бачить конкретних визначень цих інструментів у поточному запиті, а лише знає про наявність інструменту ToolSearch. Коли модель вважає, що їй потрібні додаткові можливості, вона повинна спочатку викликати ToolSearch для динамічного завантаження відповідних конфігурацій інструментів.

StreamingToolExecutor (стрімінговий виконавець інструментів): для підвищення ефективності виконання система підтримує паралельний виклик інструментів.

Оркестратор (toolOrchestration.ts) розподіляє запити на виклик інструментів, повернені великою моделлю, на паралельні та послідовні пакети.

Інструменти, безпечні для паралельного виконання (наприклад, одночасне читання кількох незалежних файлів, паралельний пошук у мережі), будуть запущені паралельно, тоді як інструменти, що не є безпечними для паралельного виконання (наприклад, послідовне змінення одного й того ж файлу коду), будуть виконуватися строго послідовно.

Інструменти для великих наборів результатів (наприклад, повний пошук за допомогою grep) мають ліміт maxResultSizeChars; вміст, що перевищує цей ліміт, обрізається та зберігається у локальному тимчасовому файлі, а LLM отримує лише попередній огляд.

ЧАСТИНА 04. Механізм Fork для вирішення забруднення контексту

Поточний монолітний агент має смертельний недолік:

Під час виконання складних завдань (наприклад, виправлення помилок між файлами) модель може повторно читати неправильні файли, спробувати неправильні команди; цей процес проб і помилок створює велику кількість сміттєвого контексту, який швидко забруднює основний діалог, що призводить до розщеплення свідомості або забуття початкової мети моделлю у подальших міркуваннях.

Claude Code впровадив складний механізм координатора (Coordinator Mode) і Fork Subagent (підагент-форк) для вирішення цієї проблеми.

Після увімкнення режиму координатора через змінні середовища система буде перебудована в архітектуру Coordinator-Workers:

Координатор: втрачений доступ до прямих операцій з файлами, зберігаються лише інструменти Agent, SendMessage та TaskStop. Його єдина задача — планування робочого процесу (Дослідження → Синтез → Реалізація → Верифікація).
Робітники (виконавці): із них виводяться конкретні описи інструментів.

Найбільш варто відзначити його механізм успадкування форку.

Коли потрібно провести масштабне дослідження коду, Coordinator створює Fork Explore Agent.

Цей під-агент успадковує кеш батьківського діалогу (спільний кеш Prompt для зменшення витрат), але його подальші дії дослідження та читання сміттєвих файлів виконуються повністю в ізольованому контексті.

Після завершення дослідження під-Agentу достатньо передати відфільтровані ключові висновки (Synthesis) назад до головного контексту Coordinator у визначеному XML-форматі .

Цей дизайн, який використовується один раз і залишає лише висновки, є однією з найкращих практик у галузі для обробки складної довготривалої співпраці між багатьма агентами.

ЧАСТИНА 05. Прорив у паралельному механізмі агентного рою

Крім послідовного механізму Fork, призначеного для вирішення забруднення контексту, код також демонструє більш амбітну конкурентну архітектуру багатоагентної системи — кластер Swarm (Teammate).

Ця логіка головним чином прихована в каталогах utils/swarm/ і tasks/.

Система підтримує тип завдання під назвою in_process_teammate.

У цій архітектурі основний процес може одночасно прокидати кілька агентів (названих Teammate), щоб вони виконували різні завдання.

Але в середовищі термінального CLI при одночасній роботі кількох агентів виникають дві критичні інженерні проблеми: конфлікти вікон дозволів та хаотичне відображення інтерфейсу.

Рішення Anthropic надзвичайно елегантне:

Права лідера (permissionSync.ts): усі дочірні процеси Teammate не мають права безпосередньо відображати вікна запитів на дозволи користувачеві. Вони пересилають запити на дозволи через внутрішній канал до головного процесу Leader Agent, який єдиний здійснює безпечне блокування та підтвердження користувачем у головному терміналі.
Автоматизація розташування терміналу: Щоб користувачі могли чітко моніторити статус роботи кількох паралельних агентів, у вихідний код безпосередньо інтегровано AppleScript-команди для iTerm2 та Terminal.app. При створенні нового Teammate система автоматично розбиває панелі терміналу (Split Pane) та виділяє окремий вікно виводу для кожного під-Agenta.

Це означає, що ІІ перехід від «одиночного мислення» до «кластерної паралельної співпраці».

ЧАСТИНА.06 Dream (Сон) архітектура пам’яті

Сьогодні, коли RAG (пошуково-підсилене генерування) набуває великої популярності, майже всі AI-продукти інтегрують векторні бази даних (Vector DB).

Але дивно, що система пам’яті Claude Code (memdir/ модуль) надзвичайно ретро та практична — вона повністю базується на локальній файловій системі.

Його архітектура складається з центрального файлу MEMORY.md (як високорівневого індексу, обмеженого максимум 200 рядками/25 КБ) та кількох тематичних файлів у форматі Frontmatter.

Пам’ять докладно розділена на чотири категорії: User, Feedback, Project, Reference.

Цікавіше те, що прихований режим допоміжника KAIROS у вихідному коді.

Це режим тривалого виконання (Daemon), який ще не був офіційно випущений.

У режимі KAIROS система пам’яті більше не є просто оновленням індексів, а використовує додавальний підхід, подібний до людського журналу (запис у logs/YYYY/MM/YYYY-MM-DD.md).

У нічний час або під час простою фоновий агент завдань під назвою Dream (мріяти) активується.

Обов’язком цього агента є підсумовування та відфільтровування щоденних журналів за день, а потім витягування та збереження їх у структурованих довгострокових тематичних файлах.

Цей асинхронний механізм інтеграції від короткострокових журналів до довгострокової пам’яті не лише обходить проблему повноти пошуку векторів, але й вказує на чіткий напрямок розвитку AI-асистентів на пристрої: постійну доступність і неперервне навчання.

ЧАСТИНА 07. Звуження прав та безпека

Надання штучному інтелекту дозволу на виконання локальних команд оболонки та зміну файлів — це двосторонній меч.

Часті вікна з запитом на підтвердження повністю зруйнують досвід автоматизації, а безобмежена автоматична виконання може призвести до збоїв у системі (наприклад, випадкове виконання rm -rf).

Claude Code використовує багаторівневу архітектуру збіжності дозволів:

Від базового файлового/мережевого пісочниці на основі @anthropic-ai/sandbox-runtime, до жорстко закодованих блокувань для специфічних небезпечних операцій (наприклад, git push --force), до перевірок на рівні інструментів.

Але найбільш захоплюючим є його компонент під назвою Auto Mode Classifier (yoloClassifier.ts).

Коли користувач увімкнув автоматичний режим, система не використовує жорсткі регулярні вирази для оцінки небезпеки команд, а замість цього застосовує механізм бічного запиту (Side Query).

Система у тилі тихо викликає менший і дешевший LLM, надаючи йому скорочений транскрипт поточного діалогу та майбутню команду Bash, щоб цей побічний модуль вирішив — Allow чи Deny.

Крім того, у системі присутній пороговий Denial Tracking (відстеження відмов), який при частих відмовах автоматичних інструментів плавно переходить у режим Prompting для залучення людини.

Ця динамічна система прав доступу, де малий AI регулює великий AI, набагато гнучкіша, ніж традиційні статичні правила блокування.

ЧАСТИНА.08 Декілька невеликих сюрпризів

Нарешті, наявність великої кількості флагів функцій у вихідному коді (наприклад, VOICE_MODE, SSH_REMOTE) та перевірки змінних оточення process.env.USER_TYPE === 'ant' демонструють подвійні стандарти великих компаній під час внутрішнього тестування та зовнішнього випуску.

Для внутрішніх співробітників Anthropic (тільки Ant), вимоги до коду є надзвичайно суворими, навіть параноїкальними:

Не додавайте функції без потреби, якщо вимоги не згадують — не рефакторійте, три схожі рядки коду краще, ніж передчасна абстракція, за замовчуванням не пишіть жодних коментарів, якщо WHY не очевидний, якщо тести провалені — повідомляйте чесно.

А для зовнішніх публічних збірок системні підказки значно пом’якшені: одразу переходьте до суті, спробуйте найпростіший підхід і намагайтеся бути стислими.

Ця протилежність свідчить про те, що межі поведінки великих моделей у значній мірі залежать від жорстко закодованих інструкцій.

Варто зазначити, що в коді містяться два цікаві модулі.

Режим підприємця (Undercover Mode):

Це функція, яка викликає суперечки в безпековій спільноті.

У сценарії, коли працівники працюють з відкритими або загальнодоступними сховищами, цей режим за замовчуванням увімкнено і не може бути примусово вимкнено. У цьому режимі в запиті моделі чітко вимагається: Do not blow your cover (не розкривайте свій ідентичність), а також примусово видаляються всі застереження або сліди, згенеровані ШІ.

З публічних міркувань це може виглядати як недостатня прозорість, але це непрямо підтверджує абсолютний контроль виробника над ролевим моделюванням та втручанням у вивід.

Buddy System (електронна тваринка) схований елемент:

У вихідному коді міститься прихована система віртуального домашнього улюбленця (генерує качок, сов тощо).

Для забезпечення випадковості та визначеності генерації тваринок інженери використали ID користувача разом із алгоритмом псевдовипадкових чисел Mulberry32.

typescript

// 18 видів: качка, гуска, блоб, кіт, дракон, восьминіг, сова, пінгвін, ...

5 рівнів рідкісності: звичайний (60%), нечастий (25%), рідкісний (10%), епічний (4%), легендарний (1%)

// Атрибути: НАЛАШТУВАННЯ, ТЕРПІННЯ, ХАОС, МУДРІСТЬ, САРКАЗМ

// Аксесуари: корона, високий капелюх, гвинт, ореол, чарівник, шапочка, крихітна качечка

// Особливо: 1% ймовірність shiny

Найбільш смішним деталем є те, що англійська назва певного виду тварини збігається з надзвичайно секретним внутрішнім кодовим ім’ям Anthropic (можливо, це найпотужніший Claude-капібара, що втекла вчора).

Щоб обійти перевірку заборонених слів у сканері коду відповідності, інженери використали String.fromCharCode(), щоб динамічно збирати це слово.

Цей іронічний підхід, властивий гікам, виглядає неординарно на тлі надзвичайно серйозного коду інфраструктури.

ЧАСТИНА.09 Що ми можемо вивчити?

За короткий час відбулося дві витіки: технічна документація основної моделі та вихідний код основного застосунку. Anthropic дійсно повинна глибоко проаналізувати свої внутрішні процеси контролю. Але технологія ні в чому не винна — цей код обсягом 510 000 рядків є чудовим навчальним посібником для галузі.

З нижнього рівня дизайну Claude Code видно, що ера стартапів у сфері застосунків великих моделей, що базувалися лише на збиранні промптів, накопиченні векторних баз даних та оболонці простого циклу, закінчилася.

Справжні бар’єри створені на основі екстремальної економії витрат на токени (оптимізація Prompt Cache), потокового планування взаємодії багатьох станів (механізми Coordinator та Fork), балансу між виявленням намірів користувача та безпечним втручанням (YOLO Classifier), а також глибокої інтеграції з файловими потоками операційної системи-господаря.

Зараз репозиторії, які форкнули цей код на GitHub, піддаються ризику видалення за запитом DMCA.

Але будь-яким чином, рівень інженерії, продемонстрований Claude Code, встановив новий технічний стандарт для продуктів AI-асистентів 2026 року.

Професіоналам слід скористатися цією можливістю, щоб уважно проаналізувати та впровадити найкращі інженерні практики.