CodeWithLLM-Updates
-

Схоже, Китай все активніше йде не тільки в моделі, а й у повні coding harness / agent app.

Kimi K2.7 і у Github Copilot
https://github.blog/changelog/2026-07-01-kimi-k2-7-is-now-available-in-github-copilot/
GitHub додав Kimi K2.7 Code у Copilot. Це перша open-weight модель, яку можна обрати у Copilot. Хоститься на Microsoft Azure.

MiMo-Code CLI від Xiaomi
https://mimo.xiaomi.com/mimocode
https://mimo.xiaomi.com/blog/mimo-code-long-horizon
https://github.com/XiaomiMiMo/MiMo-Code
Xiaomi розробляє свій open-source CLI MiMoCode. Вміє працювати з Git, checkpoint-и, task tree, subagents, compose mode, voice input. Має persistent memory на SQLite FTS5 та команди, /dream і /distill для витягування знань та повторюваних workflow у skills.

Цікаво, що це не просто "ще один CLI", а спроба зробити Codex/Claude Code-подібний агент із власною пам'яттю й режимами роботи. Є безкоштовний на старті MiMo Auto, OAuth через Xiaomi MiMo Platform, підтримка OpenAI-сумісних провайдерів.

ZCode застосунок v3 від Z.ai
https://zcode.z.ai/en
ZCode — desktop застосунок на MacOS/Windows/Linux під топову модель GLM-5.2, Z.ai з v3 оптимізує цілий agent harness саме під свою модель та тарифні плани. Виглядає як пряма копія Codex app.

Має керування плагінами, відкат файлів (file rewind) із безпековим саммарі (safety summary), покращені пропозиції команд для промптів, планування, рев'ю, деплой, завдання робочого простору (workspace tasks), навички (skills) та мультиагентну взаємодію. Можна керувати агентом через чат у WeChat, Feishu чи Telegram.

Обговорення
https://news.ycombinator.com/item?id=48753715
На HN головний нерв — довіра. ZCode не є open-source, на відміну від MiMoCode, тому люди питають про telemetry, sandboxing і чи запускати desktop agent на основній машині взагалі безпечно. Багато коментарів зводяться до практики: агентів краще запускати у VM/containers, давати їм окремі worktree, окремі GitHub deploy keys і мінімальний доступ до секретів.

Sonnet 5 - довше й дорожче
https://www.anthropic.com/news/claude-sonnet-5
Anthropic випустила Claude Sonnet 5. Позиціонування: найагентніший Sonnet, ближчий до Opus 4.8, але дешевший. Доступний у Claude, Claude Code і API як claude-sonnet-5. До 31 серпня 2026 ціна знижена до $2/$10 за млн input/output токенів, потім буде $3/$15. Opus 4.8 для порівняння — $5/$25.

Додатковий нюанс: новий tokenizer може рахувати той самий текст як 1.0-1.35x більше токенів залежно від контенту. Тобто "дешевший Sonnet" не завжди автоматично дешевший у реальному рахунку. Модель не така розумна, але показує кращі результати бо наполегливіша. Тому й токенів може дуже багато витрачати.

Обговорення
https://news.ycombinator.com/item?id=48736605
HN зустрів Sonnet 5 скептично. Багато хто питає, навіщо брати Sonnet 5 на high effort, якщо Opus 4.8 low/medium іноді дає кращий результат за долар. Інша претензія — моделі стають більш "агентними", але іноді переускладнюють прості задачі й самі генерують зайву роботу.

Cursor провів Compile 26 — свій день "розробника" про майбутнє програмування.

https://www.marketwatch.com/story/social-media-declared-cursor-dead-then-spacex-handed-the-ai-startup-a-60-billion-lifeline-50454e29
Michael Truell на Compile показував новий Composer — вже власну модель на 1.5T параметрів, яку Cursor тренував з нуля на більш ніж 100k Nvidia GPU від SpaceX/xAI. На його думку Cursor більше не просто "кращий VS Code з чатиком", а платформа для агентного програмування.

Можливо модель буде доступна й в Grok Build.

https://www.youtube.com/watch?v=fWa7uxyhVDE

https://www.youtube.com/@cursor_ai/videos
На офіційному YouTube-каналі потрохи викладають записи виступів. Короткі доповіді по 10-25 хвилин, багато розмов не про "AI замінить програмістів", а про те, як змінюється сама робота: пам'ять агентів, інфраструктура для паралельних агентів, роль PM, роль senior engineer, навчання, контроль якості.

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

Origin — GitHub для агентів
https://cursor.com/origin
Окремо найцікавіший анонс це Origin, нова Git-платформа від Cursor. На сайті вони називають її гіт для агентів. У виступі Origin прямо представили як agent-native Git platform, а в кінці підсумували це як початок конкуренції з GitHub.

Агенти тут можуть працювати з репозиторієм, створювати й обробляти PR, відповідати на коментарі, фіксити CI failures, розв'язувати merge conflicts і тегати людину тільки коли справді треба.

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

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

Loop Engineering (інженерія циклів) - спосіб будувати роботу з агентами так, щоб агент не просто відповідав на один запит, а багато разів проходив цикл: зрозуміти завдання, зібрати контекст, зробити малу дію, перевірити результат, виправити помилку і зупинитися за явним правилом.

Промпт-інженерія намагається покращити одну відповідь моделі. Інженерія циклів намагається покращити весь процес доведення роботи до перевіреного результату.

Що таке інженерія циклів
https://kilo.ai/articles/what-is-loop-engineering
Цей матеріал дає основу. Сила не в одному кроці, а в замиканні циклу коли будь-яка помилка тесту, помилка коду - це не просто невдача, а новий контекст. Але добрий розроблений цикл не повинен працювати безмежно, потрібно явно задавати ціль, контекст, перевірку і правила зупинки. Також розглядаються ризики такої небезпечної автономності.

Базовий цикл виглядає так:

  1. Намір. Людина або система задає конкретний результат.
  2. Контекст. Агент читає код, документацію, помилки, журнали, вимоги, правила проєкту.
  3. Дія. Агент змінює код, запускає команду, викликає інструмент або готує план.
  4. Спостереження. Система отримує тести, помилки компілятора, результат збірки, журнал, скриншот, коментар рев'ю.
  5. Корекція. Агент змінює план і повторює цикл.
  6. Зупинка. Цикл завершується, коли є доказ виконання, або коли з'явився блокер.

Звідки популярність терміну
https://addyosmani.com/blog/loop-engineering/
Addy Osmani посилається на думки Peter Steinberger і Boris Cherny та популяризував формулювання. Замість того щоб самому кожного разу підказувати агенту наступний крок, ми будуємо систему, яка підказує агенту за нас. Вчимося проєктувати контур перевірки, пам'яті, доступів і закінчення роботи.

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

https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/
Lushbinary багато в чому переказує Addy, але додає практичніші деталі: цикл Ralph, як виглядають автоматизації, окремі робочі дерева, навички, підключення, під-агенти і пам'ять у сучасних інструментах.

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

Чотири рівні циклів
https://www.langchain.com/blog/the-art-of-loop-engineering
LangChain намагається нам продати свій стек та прямо визнає компроміс: перевірки збільшують вартість і затримку, але для якості потрібні. Вони пропронують розгядати чотири цикла:

  1. Цикл агента. Модель викликає інструменти, доки задача не завершена.
  2. Цикл перевірки. Окремий агент-оцінювач перевіряє результат за правилами і повертає агенту-виконавцю зворотний зв'язок.
  3. Цикл подій. Запуск відбувається не вручну, а через події: розклад, зовнішній сигнал, повідомлення, новий документ.
  4. Цикл покращення. Логи запусків аналізуються, щоб покращити налаштування, інструменти або промпти.

Відео Matthew Berman
https://www.youtube.com/watch?v=dMrm2jAyrKM

Відео "Only the best are using them..." подає тему як нову "мету" для кодування. Там є сильний хайповий тон: "майбутнє програмної інженерії", "лише небагато людей знають, як це робити", "найкращі вже використовують". Воно добре пояснює ідею для широкої аудиторії, але найбільше підсилює хайп.

Критика терміна
https://iii.dev/blog/loop-engineering-is-just-software-engineering/
У багатьох текстах "Loop Engineering" звучить так, ніби з'явилась нова парадигма. Частина авторів подає це як майбутнє всієї розробки, хоча багато складників давно відомі як нормальна інженерія: тести, черги, планувальники, журналювання, контроль доступів, повторні спроби, перевірка людиною.

Переклад термінів:

  • автоматизації за розкладом - планувальник;
  • пам'ять поза розмовою - сховище стану;
  • перевірник - окремий споживач результату з логікою повтору;
  • застряглі задачі - черга помилок;
  • підключення до зовнішніх сервісів - зовнішні сигнали та інтеграції.

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

Нарешті відповідь на Claude Code і Codex від команди Елона Маска.

Grok 4.5 — швидше й дешевше за Opus-клас
https://x.ai/news/grok-4-5
https://cursor.com/blog/grok-4-5
8 липня 2026 SpaceXAI презентувала модель Grok 4.5 — зроблена під генерацію коду, автономну роботу з інструментами й «офісні» задачі. Тренували разом із Cursor на десятках тисяч GPU. У даних — трильйони токенів реальних Cursor-сесій: як люди працюють з репозиторіями, агентами й інструментами, плюс STEM і знання, не лише «чистий» кодинг як у Composer 2.5. Модель бачила як реально виглядає робота в Cursor людей, які у налаштування дозволили це.

У бенчмарках модель не перша скрізь — між GPT 5.5 (а 5.6 вже не за горами) і Opus/Fable — ставка саме на розумність за свою вартість. В порівняні з GLM-5.2 у Grok є можливість приймати на вхід зображення.

На SWE Bench Pro модель витрачає приблизно в 4 рази менше вихідних токенів, ніж Opus 4.8 на максимальних налаштуваннях, і видає близько 80 токенів на секунду. На довгих задачах Grok менше ускладнює відповіді, ніж Sonnet 5 чи Opus, і через це реальний рахунок часто виходить вигіднішим, ніж підказує порівняння цін за токен. API коштує $2/$6 за млн вхідних/вихідних токенів; якщо контекст перевищує 200k (максимум 500k) — ціна подвоюється.

Grok Build CLI для всіх
https://x.ai/cli
https://x.ai/news/grok-build-cli
Тепер дефолтом встановили Grok 4.5 з вікном 500k. Grok Build — terminal-native coding agent (CLI на Rust, з травня 2026 у beta). Це не чат у браузері, а агент у командному рядку. Є все що потрібно - паралельні subagents (у т.ч. у окремих git worktree), skills / plugins / hooks / MCP / AGENTS.md. На старті свідомо підхоплює налаштування з Claude Code (skills з ~/.claude/, частина permissions). Є headless (grok -p) для скриптів і CI, voice, image/video tools, /goal для довгих цілей.

Grok Build робить ставку на швидкість та паралельність (кілька агентів одночасно). Зараз в нього гарний чистий terminal UX, сумісність зі форкфлоу з Claude-екосистеми. Плюс на обмежений час безкоштовний ліміт у Grok Build і Cursor (у Cursor — на всіх планах, перший тиждень з double usage). В ЄС 4.5 поки немає (обіцяють середину липня).

Зараз в інтерфейсі багато нагадувань "заплати за підписку". За замовчуванням після встановлення збір даних для тренування включений - треба заходити в налаштування та відмовлятися. В моєму порівняльному тестуванні ZCode (теж порівняно недорога GLM-5.2) vs Grok Build мені більше сподобалися результати від Grok.

https://www.youtube.com/watch?v=RGXRUH3oK6U

На думку автора відео Grok створив гарнішу версію (краща кольорова палітра, зручніший дизайн) презентації. Grok створив набагато кращий результат симуляція Сонячної системи. Для створення веб-сторінки з фото результати приблизно однакові. Головна перевага — ціна, вона в 5–6 разів дешевше за Claude Code.

Обговорення
https://news.ycombinator.com/item?id=48835111
На HN дискусія крутиться навколо ціни, швидкості й того, скільки токенів реально з’їдає задача. Перші відгуки: дуже швидка, рівень близько нижньої частини Opus / GLM 5.2, і якщо платити за API — часто дешевше за GPT і Opus. Інтерфейс Grok Build хвалять — «зроблено добре», особливо на тлі все більшого погіршення Claude Code.

Скепсис теж є. Перестає виглядати дешево, коли контекст >200k; хтось лишає лише для коротких review. Є скарги, що на простих правках (inline helpers) модель переписує пів модуля замість десяти рядків. Репутація Grok (старі скандали з safety) досі згадують як причину не використовувати модель.

Дані Cursor і тренування на важких середовищах — сильна сторона; Grok 4.5 + Grok Build виглядають як гарний кандидат спробувати на різних свої завдання якщо репозиторії не великі.

Нарешті анонси моделей які роблять суттєвий крок уперед.

Величезна Kimi K3
https://www.kimi.com/blog/kimi-k3
Moonshot випустила Kimi K3 — open frontier дуже велику модель на 2.8T параметрів (MoE: активує 16 з 896 experts), з 1M контекстом і нативним розумінням зображень. Це перша open-модель класу ~3T. Налаштована для довгої агентної роботи, в презентації роблять акцент на генерацію простих 3д ігор.

Також у кейсах — оптимізація GPU-ядер, збірка MiniTriton-компілятора з нуля, 48-годинний прогін chip design. За їхніми бенчмарками вона трохи поступається Claude Fable 5 і GPT-5.6 Sol, але стабільно обходить Opus 4.8, GPT-5.5 і точно GLM-5.2. Тобто на зараз це трете місце у світі, K3 відстає від Fable 5 лише приблизно на 5%. За доброю китайскою традицією дешевша за США конкурентів.

На момент анонсу виклали не самі ваги моделі, а лише доступ через API, Kimi.com, Kimi Code та інші свої сервіси. У технічному блозі Moonshot пише, що повні ваги моделі будуть опубліковані до 27 липня 2026 року.

Обговорення
https://news.ycombinator.com/item?id=48935342
За Simon Willison це «найдорожчий пелікан» серед китайських моделей. Якщо K3 справді близько до Fable/Sol — то така ціна виправдана. Локально 2.8T майже нікому не підняти тому тут цінність у GPU клауді, а не в «на ноуті». В цілому довга суперечка про те, чи китайські лабораторії вже майже наздогнали Anthropic/OpenAI, чи ще суттєво відстають.

https://www.youtube.com/watch?v=QfCpRTLSOB4

Fable 5 повернули
https://www.anthropic.com/news/redeploying-fable-5
Після релізу 9 червня керівництво США наклала заборону на відкритий доступ до найпотужніших на сьогодні Anthropic моделей Fable 5 / Mythos 5 з необхідністю попередньої внутрішньої перевірки загроз безпеки. Anthropic вимкнула доступ усім, бо не могла перевіряти звідки користувач.

30 червня обмеження зняли; з 1 липня Fable 5 знову глобально в Claude, Claude Code, Cowork і Platform. Mythos 5 — лише для обмеженого кола США-організацій (Glasswing). Anthropic також продовжила пільговий період доступу до Fable 5 в межах підписних планів спочатку до 12 липня, а потім до 19 липня. Чи буде надалі доступ до моделі тільки за оплату токенів подивимося вже незабаром.

GPT-5.6 у трьох варіантах
https://openai.com/index/gpt-5-6/
OpenAI вивела сімейство GPT-5.6: Sol (передова), Terra (баланс, ~рівень GPT-5.5 при нижчій ціні), Luna (швидка/дешева, ~рівень GPT-5.4). Добре що з'явився явний вибір замість «одна модель на все». Рутинний agent loop → Terra/Luna; важкі рефактори/довгі задачі → Sol.

Сама GPT-5.6 Sol вже відчувається як GPT-6 й може годинами автономно з самоперевіркою виконувати завдання чи генерувати код. Саме через це реліз спочатку різали під урядовий preview й тільки потім зробили відкритим для всіх.

Новий Work / Codex app
https://openai.com/index/chatgpt-for-your-most-ambitious-work/
OpenAI інтегрує свій Codex app з Atlas браузером (через декілька днів Anthropic теж інтегрувала браузер у свій Cluade work/code) та новим ChatGPT під Mac/Windows. Тепер три режими: Chat (швидкі питання/чернетки), Work (довгі агентні задачі з документами/поштою), окремо Codex (підключення репозиторіїв).

Кажуть Computer Use став ще краще. Всюди працюють плагіни, скіли, завдання за розкладом, ітд. Задачі можна менеджити з телефону. Додали вкладку Sites (Сайти) де можна розмістити публічні dashboards/прототипи без зайвих зусиль, просто давши у чаті команду опублікувати сайт.

Додали Inline-редагування. Тепер код і текст можна змінювати прямо в інтерфейсі ChatGPT, не перемикаючись щоразу в зовнішній редактор заради невеликих виправлень.

Клавіатура Codex Micro
https://worklouder.cc/codex-micro
OpenAI також представила свій перший апаратний продукт: компактну програмовану клавіатуру (точніше, макропад), створену спільно з Work Louder для роботи з агентами Codex. Вона має спеціальні клавіші для керування агентами, індикатори їхнього статусу, регулятор рівня reasoning та підтримку голосових команд.

Grok скандал із «тихим» вивантаженням коду, потім — відкритий код як спроба повернути довіру.

Grok CLI та стеження
https://www.internationalcyberdigest.com/xais-grok-build-cli-uploads-entire-git-repositories-to-a-google-cloud-bucket/
https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547
Відразу кілька людей написали репорти, що Grok Build CLI при старті сесії детерміновано (не «агент сам вирішив») пакує поточну директорію / git-репозиторій і заливає його в інтернет на Google Cloud Storage (grok-code-session-traces). Один користувач запустив grok з home directory і побачив, що пішли SSH-ключі, password manager, документи, фото — всі його файли.

Люди почали досліджувати. Це НЕ поведінка моделі. Налаштування приватності «Improve the model» / /privacy тільки керує чи будуть данні використані для навчання, а не тим, чи файли взагалі будуть скопійовані з машини. Це робить код harness'а, аналіз (cereblab, grok 0.2.93) показав два канали:

  1. Model turn (/v1/responses) — те, що агент реально прочитав (у т.ч. .env).
  2. Знімок всієї папки — окреме завантаження усього репозиторія включаючи git history, навіть файлів, які агенту сказали НЕ читати.

На 12 GB репо пішло ≈5.1 GiB у Google Cloud Storage при ≈192 KB на модель. Як вихід був локальний kill-switch: [harness] disable_codebase_upload = true у ≈/.grok/config.toml (+ env для telemetry). Але сервери xAI після розголосу цієї поведінки десь з 12 липня самі вимкнули завантаження. Маск пообіцяв повністю видалити раніше завантажені дані.

https://news.ycombinator.com/item?id=48892468
На HN тон жорсткий: не повинно «trust this directory» давати право «upload everything to vendor». Тому люди все еще за те, щоб агентів тримати у VM/container/окремому user й не допускати до свої машини.

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

Grok CLI відкрили код
https://x.ai/open-source
https://github.com/xai-org/grok-build
https://simonwillison.net/2026/Jul/15/grok-build/
Після скандалу SpaceXAI/xAI виклали код Grok Build на GitHub під Apache 2.0: Rust TUI + agent runtime (≈845k SLOC, ≈3% vendored). Репо — періодичний snapshot з внутрішнього monorepo (SOURCE_REV), зовнішні PR/issues не приймають. Можна збирати з source і ганяти local-first з власним inference. На практиці бінарники з CDN і open tree — різні речі, поки немає reproducible builds.

У коді лишилися сліди upload path (upload/gcs.rs), але session upload повертає session_state_upload_unavailable. Є порти tools з Codex/OpenCode (з THIRD-PARTY notices), terminal Mermaid renderer, system/subagent prompts.

Обговорення
https://news.ycombinator.com/item?id=48926590
На HN змішано: бачать стратегія відстаючого гравця та «відкрили, бо спіймали на непрозорій поведінці». Хвалять TUI (миша, smoothness). Спільнота вже ріже privacy-форки:

  • gork-build https://github.com/thedavidweng/gork-build (telemetry strip, block auto-update),
  • digi-grok / open-grok (multi-provider),
  • desktop Tauri-обгортки,
  • скрипти вимкнення telemetry.
    Але багато хто вважає, що все одно форки не мають змісту для інших моделей, бо під них вже краще взяти Pi / OpenCode.

Kimi K3 стала настільки популярна, що компанія закрила реєстрацію нових користувачів на підписні плани. Довго було написано просто "Sold Out", а зараз список очікування.

Opus 5 часто помиляється
https://www.anthropic.com/news/claude-opus-5
https://news.ycombinator.com/item?id=49038433
24 липня Anthropic випустила Claude Opus 5 — близька до Fable 5 за показниками на тестах, але дешевше. У демо Anthropic модель без доступу до «перегляду» креслення сама пише CV-пайплайн з пікселів і збирає 3D FreeCAD-модель; чинить root cause у package manager, який інші моделі «латають» лише на поверхні.

На практиці вийшла проблема саме в цій надмірній агентності. Забули пароль до Postgres — замість питання піднімає Kind-кластер. Попросили не чіпати sandbox — ламає правила. Пише specs/docs/research гірше, бо йде «робити», а не уточнювати. На code review бувають хибні спрацьовування. Часто спалює токени на винахідливі, але непотрібні обходи.

Ефект Kimi K3
https://stephen.bochinski.dev/blog/2026/07/18/the-kimi-k3-moment/
Stephen Bochinski описує те, що багато хто відчуває зараз: на звичайному кодингу K3 і Claude Fable майже не відрізнити бо та сама якість, схожа кількість токенів. Але ціна ні! Ширший сюжет блогу — провал США ШІ регулювання: Fable різали й гатили safeguard’ами, а китайська open frontier-модель без цих обмежень у відкритому доступі. Висновок автора жорсткий: тепер немає причини платити за Claude, якщо K3 тримає якість.

Kimi K3 на 256k дешевше
https://news.ycombinator.com/item?id=49101852
https://www.kimi.com/code/docs/en/kimi-code/models
Moonshot випустила k3-256k у Kimi Code: та сама якість у межах 256k, але у 2 рази менше ціна/квоти, ніж з 1M контекстом. Але тримає це для поточних підписників, щоб не повторити Anthropic-сценарій «приймаємо всіх і тихо ріжемо ліміти».

Локально K3 усе одно не про «ноут»: 1.5TB VRAM на MXFP4. Тому 256k-скидка важлива саме в cloud/subscription, не в self-host. Логіка та сама, що в OpenAI з порогом 272k — довгий KV-cache дорогий, тож окремий SKU з меншим max context дешевше обслуговувати. Перехід 256k → 1M не збиває кеш (за їхньою докою) — можна стартувати дешево й підняти вікно, коли реально треба.

Kimi K3 виклали
https://huggingface.co/moonshotai/Kimi-K3
https://news.ycombinator.com/item?id=49065752
https://huggingface.co/chat/models/moonshotai/Kimi-K3
Обіцянку з анонсу виконали: повні ваги на Hugging Face під Kimi K3 License. 2.8T MoE (активує 16 з 896 experts, 104B active), 1M context, нативне vision (MoonViT-V2), KDA + AttnRes, native MXFP4. Є chat на HuggingChat. Локально зараз мало кто зможе таке запустити, але вже підтягнулися великі GPU хмарні провайдери.

Поєднання Kimi K3 + Fable
https://fireworks.ai/blog/kimik3-fable
Fireworks прогнали 1030 agentic задач (SWE, terminal, algo, multi-lang, legal) через K3 і Fable 5 в одному harness. Вийшо, що на SWE майже нічия (K3 92.4% vs Fable 92.6%), але спеціалізація різна — K3 сильніший на symbolic math, dev tooling, long terminal (security/crypto/sysadmin); Fable — web, data viz, ширший multi-lang.

Висновок статті: краще не коли одна SoTA модель робить все. Open (K3) — запускає, premium (Fable) — дороблює; роутер це все перемикає. Oracle routing (обрати дешевшу правильну модель) дає до 93% точність і до 50× нижчу вартість за Fable на довгих завданнях.

Не модель Fugu
https://sakana.ai/fugu/
Sakana Fugu — це не одна LLM, а мульті-агента система як модель назовні: один OpenAI-compatible API, всередині динамічна оркестрація пулу чужих frontier-моделей. Які саме моделі і як роутить тут закрита інформація. Це інший полюс того самого тренду, що й Fireworks routing.