Vercel Labs викотили у відкритий доступ fx — консольного coding-агента вагою 6,39 мебібайта, написаного мовою Zig, який стартує за 10 мікросекунд і споживає лічені мегабайти оперативної пам'яті. Для порівняння: типовий npm-пакет із node_modules під сучасний CLI-агент важить у сотні разів більше, а холодний старт Node.js-рантайму вимірюється секундами, а не мікросекундами.

Питання напрошується саме зараз: навіщо у 2026 році, коли ринок coding-агентів рясніє TypeScript- та Electron-обгортками з розкішними терміналними інтерфейсами, комусь писати агента системною мовою без збирача сміття і без рантайму? Відповідь Vercel Labs проста й водночас показова для всієї індустрії — агенти перестають бути інструментом, яким людина користується годинами за терміналом, і стають процесом, який запускають та вбивають тисячі разів на день усередині чужих систем.

fx — не проєкт студента-ентузіаста, а внутрішній інструмент Vercel, компанії, що стоїть за Next.js і власним AI Gateway, який тепер відкрили під ліцензією Apache-2.0. Це має значення: Vercel вже продає продукти на кшталт Vercel Sandbox та шаблонів coding-agent platform для запуску агентів у ізольованих хмарних контейнерах, і fx виглядає радше як інфраструктурна деталь для цих продуктів, ніж як самостійна заявка на увагу розробників, що вибирають між Claude Code, Cursor чи Codex CLI.

Саме тому варто розібратися, що fx реально пропонує сьогодні, а що — поки лише обіцянка релізу v0.0.4 з офіційною позначкою «experimental, use at your own risk».

Звідки взявся fx і навіщо він Vercel?

fx почав життя як внутрішній дослідницький інструмент Vercel для вбудовування агентських можливостей у більші системи, і лише згодом команда вирішила відкрити його код. За даними HackerNews, обговорення релізу зібрало типову для нішевого системного проєкту реакцію: цікавість до вибору Zig і скепсис щодо зрілості v0.0.x.

Контекст важливий. Vercel вже має AI Gateway — єдину точку маршрутизації запитів до різних провайдерів моделей, і Vercel Sandbox — ізольовані обчислювальні середовища для запуску коду, згенерованого агентами. Якщо ви щодня піднімаєте sandbox під кожен pull request, кожен мегабайт образу і кожна мілісекунда холодного старту множаться на тисячі викликів і перетворюються на реальний рахунок в кінці місяця. Це зовсім інша економіка порівняно зі скаргою одного розробника на секунду затримки при запуску CLI на своєму ноутбуці.

Тому логіка Vercel зрозуміла: замість того, щоб тягнути повний Node.js-стек у кожен ефемерний контейнер, вигідніше мати мінімальний нативний бінарник, який виконує ту саму роботу — читає репозиторій, викликає інструменти, спілкується з моделлю — але не платить за це рантаймом.

Як fx влаштований під капотом?

fx — це один статичний бінарник, зібраний тулчейном Zig, без окремого рантайму і без garbage collector: уся логіка агента — системний промпт, виклик інструментів, керування дозволами, збереження сесій — вміщена у 6,39 МіБ за даними демо-сторінки fx.sh (у README на GitHub фігурує вже 7,8 МіБ, бо репозиторій встиг оновитися між релізами). Холодний старт — 10 мікросекунд, і до першого введення від користувача fx свідомо не робить жодного зайвого вводу-виводу.

Мінімалізм як архітектурний принцип

Розробники fx явно оптимізують не лише швидкість запуску, а й контекстну ефективність: маленький системний промпт і обмежений набір інструментів зменшують витрати на токени і скорочують час до першого токена відповіді (TTFT). Інтерфейс навмисно ближчий до Unix-шелу, ніж до «IDE в терміналі»: fx зберігає історію прокрутки за замовчуванням і мінімізує складний TUI-рендеринг, тоді як конкуренти на кшталт Claude Code чи opencode будують повноцінні екрани з панелями й перемальовуванням.

Модель дозволів у fx стартує в режимі auto: рутинні, зрозумілі дії агент виконує напряму, а нез'ясовані чутливі дії проходять одну обмежену автоматичну перевірку. Команда /permissions remember allow|deny <tool> <args> дозволяє зберегти точне правило без повторного запуску дії, а JSON- і quiet-режими залишаються неінтерактивними за замовчуванням — текст запиту на дозвіл іде в stderr, тож stdout лишається чистим для скриптів. Розширюваність побудована на трьох механізмах: skills (перевикористовувані інструкції), MCP-сервери для зовнішніх інструментів і subagents для делегування незалежної роботи, а також підтримка ACP (Agent Client Protocol) — протоколу, яким послуговуються редактори на кшталт Zed, щоб підключати змінні агентські бекенди замість жорсткої прив'язки до одного постачальника.

Окремо fx збирається у WebAssembly: модулі fx-core.wasm і fx-term.wasm, доступні через createFxAgent() і createFxTerminal() для JS-хостів, — саме на цьому працює браузерне демо на fx.sh/try, де агент виконується прямо в пісочниці just-bash без встановлення на диск. З приватності — fx не збирає телеметрію продукту за замовчуванням, сесії й дані використання лишаються локально, а за бажання інструмент можна запустити повністю герметично: локальна модель інференсу плюс вимкнені автооновлення.

Дистрибуція: curl | bash без перевірки підпису

Встановлюється fx однорядковим curl -fsSL https://fx.sh/setup.sh | bash, який визначає платформу, тягне останній опублікований реліз із сховища Vercel і опційно дописує PATH у профіль шелу. Офіційна документація чесно попереджає: скрипт не перевіряє підпис чи опубліковану контрольну суму, тож для аудиту потрібно самостійно прочитати інсталятор і звірити завантажений артефакт. До цього пункту ми ще повернемось у розділі про ризики.

Чим fx відрізняється від Claude Code, Codex CLI та opencode?

Claude Code від Anthropic — це Node.js/TypeScript CLI, що встановлюється через npm і будує багатий термінальний інтерфейс на базі ink-рендерингу; за формою це справді ближче до «IDE в терміналі», ніж до шелу, а вага інсталяції та час холодного старту визначаються насамперед вагою самого Node-рантайму та графа модулів.

Показовіший приклад — OpenAI Codex CLI, який пройшов практично той самий шлях мислення, що і fx, тільки трохи раніше. Спочатку написаний на TypeScript, Codex CLI був переписаний на Rust (ядро codex-rs), і на початку 2026 року Rust становить близько 95% кодової бази проєкту — саме для того, щоб позбутися залежності від Node.js, знизити споживання пам'яті, прибрати паузи збирача сміття і отримати прямий доступ до платформного пісочничення без накладних витрат FFI. Результат — самодостатній бінарник із холодним стартом у долях секунди. Це підтверджує правильність інстинкту, на якому побудований fx, але fx йде ще далі: 10 мікросекунд проти «долей секунди» в Codex CLI, і бінарник у кілька мебібайтів проти типово десятків мебібайтів статичних Rust-збірок.

opencode від SST обрав інший архітектурний заклад: постійний TypeScript/Bun-сервер на фреймворку Hono плюс окремий TUI-клієнт, написаний на Go. Під час запуску opencode піднімає одразу два процеси — сервер бере на себе спілкування з моделлю, файлові операції та виконання команд, а TUI лише малює інтерфейс; сесія переживає розрив SSH чи сон машини, бо стан живе на сервері. Для одного розробника, що тримає довгу сесію на робочій станції, це реальна перевага. Але модель «завжди активний сервер» погано лягає на сценарій «підняти свіжий інстанс на кожен CI-джоб і викинути його за секунди» — саме той сценарій, під який заточений fx. При цьому opencode вже має понад 95 тисяч зірок на GitHub і підтримку 75+ провайдерів моделей — екосистему, якої у fx на стадії v0.0.4 просто ще немає.

Підсумок позиціонування такий: fx не змагається за красу інтерфейсу чи широту екосистеми — він змагається за звання найменшої й найшвидшої речі, яка все ще залишається повноцінним coding-агентом, спеціально для сценаріїв, де таких агентів запускають десятками чи тисячами одночасно.

Що це дає тим, хто будує на цьому зараз?

Перший практичний сценарій — CI-бот на кожен pull request у контейнері. Замість того, щоб піднімати Node-агента із сотнями мегабайтів образу й секундами холодного старту на кожен запуск лінтера чи автоматичного рев'ю, можна тримати fx у мінімальному sandbox-образі й ганяти перевірки практично без накладних витрат на старт процесу — різниця відчутна саме на масштабі сотень запусків на день.

Другий сценарій — вбудований агент прямо у власний продукт через fx-core.wasm. Команда, що будує внутрішню платформу розробника чи web-IDE, може підключити агентські можливості безпосередньо в браузер або edge-функцію, не розгортаючи окремий важкий backend-сервіс на кожного користувача, — саме так влаштоване офіційне демо на fx.sh/try, де агент працює в браузерній пісочниці just-bash без жодної інсталяції.

Третій сценарій — інтеграція в редактор через ACP. Команди, які не хочуть прив'язуватись до конкретного TUI одного постачальника, можуть підключити fx як бекенд до будь-якого ACP-сумісного редактора й зберегти собі свободу пізніше змінити модель чи агента, не переучуючи всю команду новому інтерфейсу.

Четвертий, менш очевидний випадок — команди, що вже сидять на Vercel AI Gateway. Команда fx login одразу дає доступ до gateway-маршрутизації між провайдерами через акаунт Vercel, а fx setup — альтернатива для тих, хто хоче підключити власний API-ключ чи локальну модель напряму, без прив'язки до конкретної платформи.

Чого тут бракує і що може піти не так?

Найбільший ризик прописаний прямо на сторінці проєкту: статус experimental, версія v0.0.4, і попередження, що команда вноситиме часті зміни. Для CI-конвеєра це не формальність — формат сесій, поведінка дозволів чи навіть аргументи команд можуть змінитися між релізами без гарантій зворотної сумісності.

Другий ризик — ланцюжок постачання. Інсталятор curl | bash за замовчуванням не перевіряє підпис чи контрольну суму завантаженого архіву; сама документація fx радить читати скрипт і звіряти артефакт вручну, якщо цього вимагає політика безпеки. Навесні 2026 дослідники безпеки описували кампанію GlassWorm, у якій зловмисники ховали дроппери саме у Zig-бінарниках, щоб заражати середовища розробників — це не звинувачення на адресу fx, а нагадування, що нативні бінарники з мов на кшталт Zig поки що отримують менше автоматичного сканування, ніж звичні npm-пакети, тож команди, які автоматизують встановлення fx у CI, мають пінити конкретну версію й рахувати контрольну суму самостійно, а не покладатися на дефолтну поведінку інсталятора.

Третій ризик — незрілість екосистеми. Порівняно з маркетплейсом скілів Claude Code чи усталеним плагінним шаром opencode з 95 тисячами зірок на GitHub, спільнота навколо fx лише формується: MCP і subagents технічно підтримані, але готових інтеграцій під конкретні стеки поки обмаль.

Четвертий — сама мова Zig ще не досягла версії 1.0 і час від часу ламає сумісність між мінорними релізами, а це додатковий ризик і для самого fx, і для будь-кого, хто форкне чи розширить його з вихідного коду.

І нарешті — недоведена гіпотеза якості. Мінімальний системний промпт і обмежений набір інструментів звучать переконливо з погляду вартості токенів і TTFT, але жодних публічних бенчмарків на кшталт SWE-bench, які показали б, як мінімалізм fx відображається на успішності складних багатокрокових рефакторингів порівняно з ретельно тюненими промптами Claude Code чи Codex CLI, поки що немає. Швидкість тут доведена цифрами, якість — ще ні.

Висновок AiiN

fx не претендує замінити Claude Code чи Cursor на робочому столі окремого розробника — це ставка Vercel на інший сегмент ринку: агент як інфраструктурний примітив, який запускають сотнями екземплярів у CI-конвеєрах, sandbox-ах і вбудованих продуктах, а не як застосунок, у якому людина проводить години щодня. Паралель із переписуванням Codex CLI на Rust показує, що це не одинична забаганка Vercel, а тихе, галузеве перепозиціонування: coding-агенти масово мігрують з Node.js/Electron-стеків до нативних бінарників саме тому, що змінюється сам спосіб їх виклику — з «інструмент, який запускає людина» на «процес, яким керує інше програмне забезпечення».

Наш прогноз на найближчі 6–12 місяців: варто стежити за трьома сигналами. По-перше, чи зніме Vercel позначку experimental і чи з'являться підписані або звірені контрольними сумами релізи — без цього серйозне корпоративне впровадження в CI малоймовірне. По-друге, чи вмонтує Vercel fx як дефолтний рушій усередині власних продуктів на кшталт Vercel Sandbox чи Coding Agent Template — якщо так, fx стане «сантехнікою», яку більшість розробників ніколи не викликатимуть напряму, подібно до того, як частину внутрішньої інфраструктури великих платформ користувачі просто не помічають. По-третє, чи з'явиться публічний бенчмарк якості проти Claude Code й Codex CLI, який покаже, чи коштує мінімалізм промпта fx втраченої точності на складних задачах.

Практична порада для тих, хто будує на цьому зараз: варто спробувати fx уже сьогодні для сценаріїв embedding, CI та sandbox, де вага бінарника й швидкість холодного старту рахуються буквально в доларах на мільйон запусків. Але переводити на нього щоденний робочий процес замість Claude Code чи Cursor поки зарано — проєкт відкрито відзначений як experimental, і перше, що варто зробити перед будь-яким production-використанням, — самостійно перевірити встановлювальний скрипт і зафіксувати версію.

Скільки коштує fx?

Сам fx безкоштовний і відкритий за ліцензією Apache-2.0 — платите ви лише за інференс: через власний API-ключ провайдера, локальну модель або підписку й Vercel AI Gateway при вході через fx login.

Чи можна користуватися fx без акаунта Vercel?

Так. Команда fx setup дозволяє підключити ключ будь-якого сумісного провайдера чи локальну модель напряму, без прив'язки до платформи Vercel.

Чи готовий fx для продакшн CI просто зараз?

Офіційний статус проєкту — experimental (версія v0.0.4), а інсталятор не перевіряє підпис артефакту за замовчуванням. Для CI варто пінити конкретну версію і звіряти завантажений бінарник вручну, а не покладатися на стандартну поведінку встановлювального скрипта.