Meterless.ai - агент який зберігає пам'ять та робочий процес - review - 2026

Published: 2026-08-20

meterless.ai — агент, який зберігає пам'ять та робочий процес — review — 2026 — ґрунтовний технічний огляд платформи Meterless (meterless.ai), яка називає себе «local-first context stack for agentic AI» (локально зорієнтований контекстний стек для агентного штучного інтелекту). Замість того щоб віддавати користувачеві лише фінальну відповідь нейромережі, Meterless зберігає сам процес виконання мети — план, міркування, стан, пам'ять — просто на пристрої людини, перетворюючи одноразову поведінку моделі на придатні до повторного використання «місії», редаговані графи агентів і постійну пам'ять. Це дає змогу відтворювати успішний робочий процес практично без нових витрат токенів. Огляд підготовлено на основі вивчення офіційного сайту, документації та вихідного коду репозиторію Meterless на GitHub, а також незалежних оглядів, критики й обговорень у професійній спільноті станом на серпень 2026 року.

1. З чого все почалося: проблема «викинутої роботи»

1.1. Що не так із типовими AI-агентами

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

Компанія Meterless формулює це на головній сторінці так: «Most AI tools give you an output, then discard the structure that produced it» («Більшість AI-інструментів видають результат, а тоді викидають структуру, яка його створила»). Головний слоган позиціонування: «Models come and go. Your work stays yours» («Моделі приходять і йдуть. Ваша робота залишається вашою»).

1.2. Рішення: місія замість відповіді

Meterless пропонує зберігати цінність, яку зазвичай викидають: «missions, memory, decisions, workflow state, policies, artifacts, and proof of what succeeded» («місії, пам'ять, рішення, стан робочого процесу, політики, артефакти та докази того, що спрацювало»). Успішно виконана робота перетворюється на місію — послідовність перевірених кроків, яку можна перезапускати, редагувати, планувати за розкладом і щоразу покращувати. У маркетингових матеріалах заявлено, що повторний запуск збереженого процесу коштує «0 нових токенів» («Replay · 0 tokens»), а економія порівняно з виконанням із нуля сягає «7.3–15×» токенів (тобто до ~90% витрат).

1.3. Три продукти й один спільний runtime

Платформа складається з трьох продуктових поверхонь і спільного технічного фундаменту:

Relay — «the Hands» (руки): агент комп'ютерного зору для автоматизації робочого столу Windows. Описуєте мету, обираєте вікна застосунків, перевіряєте план, виконуєте — і зберігаєте успішну роботу як місію.
Gaia — «the Mind» (розум): постійне робоче середовище AI з ієрархічною пам'яттю, планувальником із 12 «мозків» і сталим контекстом між сесіями.
Swarms — «the many» (множина): безкоштовний браузерний генератор графа агентів (DAG) з однієї мети — одна мета розгортається в команду спеціалізованих агентів.
Meterless Runtime — спільна платформа під усіма продуктами: маршрутизація незалежно від моделі, постійний контекст, локальне виконання, контроль приватності та якісно-орієнтована оркестрація.

Двигуни, що лежать в основі, опубліковані на GitHub (організація github.com/meterless) під ліцензією Apache 2.0.

2. Продукти: Relay, Gaia, Swarms

2.1. Relay — «руки»

Relay — агент комп'ютерного зору для Windows 10/11, зібраний на Tauri і Rust із нативними Windows API. Ключові характеристики з офіційної документації (docs/products/relay/):

До 8 відстежуваних вікон застосунків на місію зі стабільною ідентифікацією вікон і ремапінгом ідентифікаторів після перезапусків.
Робочий цикл: описати задачу → обрати вікна, до яких Relay може звертатися → перевірити план перед запуском → виконати → зберегти успішну роботу як місію.
Vision-verification: кожен клік і дія підтверджується за пікселями вікна перед наступним кроком; вердикти кроків: verified / failed / unverifiable. За розбіжності — пауза.
Approval gates: паузи на підтвердження перед чутливими діями (send/post/pay/delete); є прапорець «Halt before sending».
Безпека за конструкцією: Relay керує лише вікнами за їхніми ідентифікаторами (HWND). Жодного шела/термінала, sudo, доступу до файлової системи, мережі чи таблиці процесів — «fs, network, process table are out of scope by construction».
Місії: бібліотека збережених місій, планування за розкладом (наприклад, «щобудня о 16:30»), історія запусків, «процедурна пам'ять» — із 3–4-го запуску місія пришвидшується сама.
Моделі: Google Gemini (зокрема безкоштовний тариф, нативний structured JSON, search grounding), Anthropic, OpenAI, OpenCode Go, OpenRouter; маршрутизація за задачами (planning/vision/reasoning) з override.
Паролі: кроки з паролями маскуються, зберігаються за secret-посиланням, ніколи у відкритому вигляді; під час повторного запуску місії перепитуються.
Макро-запис + Live Mode дають змогу перетворювати записані дії на скіл (skill).

Приклади промптів Relay з офіційної документації:

«Open Notepad and write a one-line note that says "Reviewed at 3pm."»
«In the Chrome window I tracked, go to my dashboard and screenshot the top chart.»
«Open the spreadsheet on my second monitor, copy the values in column B, and paste them into a new email in Outlook.»

Приклад місії з інтерфейсу: «Pull my open positions out of IB Trader, export them to CSV, then draft an EOD summary email to the ops team. Halt before sending.» (витягнути відкриті позиції з IB Trader, експортувати в CSV, скласти підсумковий лист команді, зупинитися перед надсиланням).

Демонстраційна статистика з відео Relay: 4 кроки, 38 секунд wall time (Focus window 11.4s → export 8.2s → verify 6.1s → draft gated).

2.2. Gaia — «розум»

Gaia — постійне робоче середовище AI (v3.1.4) з ієрархічною пам'яттю та планувальником. Ключові характеристики:

12 «мозків»-спеціалістів: reasoning, memory, planning, observation та інші з орбітальною схемою взаємодії (когнітивне ядро + кільця спеціалістів). У демо фігурують імена Oracle, Commander, Weaver — планування з консенсусом.
Пам'ять без скидання між сесіями: цілі (goals), рішення (decisions), люди (people), вподобання (preferences), проєкти.
Місії з бюджетами: віджет показує, наприклад, «M-4307 · Plan my weekend trip to Portland and book the basics» — Turns 0/5, Time 0.0/7 min, Cost $0.00/$1.60 (бюджет-кап), артефакт portland-weekend.md.
Mentions (механізм виклику спеціалістів): @plan, @Goals (бюджет у ходах і хвилинах), @research, @Control/@Desktop/@Take_control (пікер вікон, реальні миша/клавіатура), @Schedule, @Remind, @Web/@Fetch/@URL, @Reddit, @RSS, @Files, @PDF, @Notes, @Code_Editor, @Image_Studio, @Movie_Maker, @Calendar, @Browser, @Foundry, @Data_Viewer, @Entity_Matrix, @Discover, @Stream, @Presentation, @Dashboard. Префікси: @swarm: (ліміт 50 підзадач, до 5 рівнів глибини, семантична дедуплікація), @skill:, @brain:, @persona:/@identity:, @artifact: (Neural Asset), :markovian (примусова long-horizon маршрутизація).
Observer: vision-спостереження за схваленими вікнами (дизайн-інструменти, таблиці, листи, код) — знаходить баги, друкарські помилки, проблеми контрастності (WCAG AA). Silent Observer — лише за opt-in.
Browser grounding: браузер із «receipts» — кожне твердження пов'язане з джерелом, ведеться список відвіданих сторінок.
Desktop control: через наявні сесії (OAuth, без паролів), rate limit 60 дій/с, Emergency Stop (ESC), блокування Alt+F4/Ctrl+Alt+Del.
Моделі: локально WebLLM — Llama 3.2 (1B/3B/8B), Phi-3.5 Vision + Transformers.js/ONNX для читання екрана (WebGPU); Ollama на localhost:11434; хмара — Google, Anthropic, OpenAI, Groq, Mistral, OpenCode Go, OpenRouter, Meterless localhost router. Модельний оркестратор сам вирішує, куди маршрутизувати; override в налаштуваннях.
Дані та приватність: дані в %APPDATA%\com.meterless.gaia (desktop) або IndexedDB MeterlessMem + localStorage (browser mode); ключі — в окремому сховищі apiKeyVault. Заявлено: «There is no outbound traffic from the app that you didn't initiate»; немає телеметрії, немає crash-report. Експорт: directory sync + ZIP.
Drift detection: якщо запланований запуск пропущено, прогалину фіксують у журналі.
Телефон і браузер: Gaia Companion на телефоні (сполучення за QR-кодом) і Lens-розширення браузера: queue mission, smart copy з ресиптами, draft assist.

2.3. Swarms — «множина»

Swarms (v0.9.3 / Lite v0.1.9) — безкоштовний, відкритий браузерний генератор графа агентів:

Одна мета → ціла команда агентів: тип «generate 30 variants of an interactive engaging loading screen»; система авто-генерує DAG спеціалізованих агентів (дизайнер, копірайтер, UX-дослідник, бренд-стратег тощо), запускає їх паралельно; кожен продукує кілька варіантів на різних моделях; далі merge найкращих, верифікація за брифом і синтез результату.
Масштаб: до 300+ агентів у складі графа, до 125 на спільній blackboard, 64 паралельно. Приклад метрик: 147 nodes, 382 edges, 14 depth, 22 critics, 19 merges. Слоган: «9 паралельних агентів за ціну 1 Deep Research».
Glass-box DAG: граф видимий і редагований; можна інспектувати будь-який вузол (модель, токени, score, lineage), змінювати модель на вузлі, перезапускати лише одну гілку (refine).
Контекстна вартість O(1): файли зберігаються в /.swarms/batch_9f2a/gallery, «52 artifacts · 14 families · 5 final candidates».
Режими: 2–50 варіантів генерації; verbalized sampling; ranking/reconciliation/багатопрохідне уточнення; ретраї за замовчуванням 2 на задачу.
Інтеграції: Forage (web search/fetch) — лише desktop; mobile remote — лише desktop (QR → WebRTC, без хмарного реле).
Локальність: працює в браузері, без акаунта, файли не завантажуються на сторонні сервери. Локальний WebLLM зарезервовано, але вимкнено — офлайн-генерації немає.
Дані: %APPDATA%\com.swarms.meterless.lite, IndexedDB swarms-db (проєкти, прогони, артефакти, пам'ять, Markovian run history, аудит/конфлікти пам'яті, розклади, місії). Чесно зазначено в доках: ключі зберігаються browser-style, не в окремому vault.

2.4. Безкоштовні інструменти

На сторінці tools.html представлені безкоштовні локальні інструменти: Anyfile Converter (конвертація документів, таблиць, зображень, PDF, Markdown, аудіо, відео), PDF Workbench (merge/split/reorder/rotate/protect/export без завантаження на віддалений сервіс), Image Batch Studio (resize, compress, crop, watermark, видалення метаданих, пакетна обробка), Anymedia (аудіо/відео), Watermark Remover (видалення прихованих AI-водяних знаків), WEBtoAPK (coming soon). Усе обробляється на пристрої користувача, без акаунта.

3. Технологія: п'ять відкритих двигунів

Архітектурний фундамент — п'ять двигунів, опублікованих у головному репозиторії github.com/Meterless/Meterless. Важлива особливість позиціонування: двигуни — це не npm-пакети, а специфікації для кодуючих агентів:

> «An engine here is not an npm package. It is an implementation spec built for coding agents: a full AGENTS.md contract, runnable examples, workshops, and a conformance suite that proves your build is correct.»

Кожен двигун — це AGENTS.md (контракт для агента-розробника), робочий еталон (reference), приклади та conformance-набір тестів, що доводять коректність реалізації. Три двигуни мають робочий reference (H-MEM, World Model, Markovian), один — специфікацію + eval harness (Scout Intent), один — у розробці (Swarm orchestration).

Двигун	Роль	Статус (серпень 2026)
H-MEM	Ієрархічна пам'ять і durable-контекст: три рівні (working/episodic/semantic) як grep-файли на диску, knowledge graph, mining/dreaming/audit	Spec + runnable reference + conformance
World Model	Моделювання стану користувача, задачі й середовища; event-sourced, єдине джерело правди для паралельних агентів	Spec + runnable reference
Markovian	Стиснення міркувань і переносного стану між кроками; O(1) контекст на крок; «пласка» вартість на довгих горизонтах	Spec + runnable reference
Scout Intent	Детекція наміру, risk-гардування, маршрутизація інструментів і моделей, підписані контракти виконання	Spec + eval harness (без npm-runtime)
Swarm orchestration	Паралельні агенти: plan/spawn/merge/verify	Coming soon (waitlist, серпень 2026)

Загальний пайплайн (з README репозиторію):

User / Event
   ↓
Scout Intent
   ↓
H-MEM + World Model
   ↓
Markovian Reasoning or Swarm Coordination
   ↓
Runtime Quality Layer
   ↓
Relay Execution / Gaia Interface / Swarms Output
   ↓
Verified Output + Updated Memory

4. Markovian Engine — серце економії токенів

Markovian — двигун, що відповідає за заявлені цифри економії токенів. Його ідея: кожен крок довгого прогону отримує не весь накопичений лог, а лише (1) вихідну мету, (2) стиснутий стан, перенесений з попереднього кроку (carryover), і (3) контекст, потрібний для наступної дії. Наївна стратегія (дописування всього логу до кожного наступного кроку) дає квадратичне зростання витрат на вхід; bounded carryover дає лінійне зростання.

4.1. Математична модель ефективності

З офіційного документа engines/markovian/docs/efficiency-model.md:

F = framing tokens (константа), G = goal tokens, S = середній step-input, O = середній per-step output, C = carryover tokens (тільки Markovian), N = кількість кроків.

naive_in(i)     = F + G + (i-1)*O + S          # на кроці i
markovian_in    = F + G + C + S                # константа по i

naive_total     = N*(F + G + S) + O*N*(N-1)/2  # O(N²)
markovian_total = N * (F + G + C + S)          # O(N)

efficiency = (naive_total - markovian_total) / naive_total
           -> 1 - 2C/(O*N)   для великих N

Точка беззбитковості: N > 1 + 2C/O. Тобто економія зростає з довжиною прогону.

Важливо розуміти: O(1) стосується контексту одного кроку, а не загальної вартості прогону (загальна вартість — O(N)). Автори прямо застерігають: «The O isn't constant... Use outputBudget as the projection and accept ±20%», а витрати самої каскадної компресії враховані всередині O, tool-виклики — у S.

4.2. Три «магічні» цифри: 91%, 86%, ~73%

У документі efficiency-model.md є таблиця «Which number is which», яка пояснює, що це три різні змодельовані цифри за різних припущень:

Цифра	Джерело	Припущення
~91%	«README hero math»	Повний прогін на 24 чанки, кожен змодельований за повним chunkSize = 8000, carryover 800
86%	Таблиця worked examples	N=20 з константами F=400, G=200, S=300, O=1200, C=800
~73%	Дефолти інтерактивного демо	N=10 з тими самими константами; короткі прогони економлять менше by design

Робоча таблиця (усі цифри — modeled, змодельовані):

N	Naive total	Markovian total	Savings	Efficiency
5	16 500	8 500	8 000	49%
10	63 000	17 000	46 000	73%
20	246 000	34 000	212 000	86%
50	1 515 000	85 000	1 430 000	94%
100	6 030 000	170 000	5 860 000	97%
500	150 150 000	850 000	149 300 000	99,4%

Примітка авторів до рядка 500: «At 500 steps, naive doesn't run» — наївний підхід перевищує контекстне вікно, а не просто коштує дорожче. Цитата з документа: «Expect real runs at typical configs to land between 60% and 90% depending on N, output size, and carryover budget» («очікуйте, що реальні прогони за типових налаштувань дадуть 60–90% залежно від N, розміру виводу та бюджету carryover»).

4.3. Конфігурація чанків

З reference/src/configManager.ts:

chunkSize: 8000 (мін 1000, макс 128 000, крок 1000)
maxChunks: 24 (1–32)
carryoverTokens: 800 (128–32 768, крок 128)
overlapTokens: 0 (0–4096)
Константи двигуна: FRAMING_TOKENS = 400, OUTPUT_BUDGET = 1200
Валідація жорстка: chunkSize >= framingTokens + carryoverTokens + outputBudget; «typed error, not silent truncation».

4.4. Каскад стиснення (compression cascade)

Якщо на чанку немає явного маркера стану, стиснення йде за 4 рівнями з падінням униз:

1. Явний маркер: [STATE_CHECKPOINT] або [TASK_COMPLETE] у виводі чанка (приймається за довжини ≥ 24 символів). 2. LLM-компресія: беруться останні 2000 символів виводу чанка з промптом «Return 3-5 critical points». 3. Евристика: regex KEY_PHRASE за словами Therefore / Key insight / Status / Next, перші 5 збігів, з'єднання через «; ». 4. Абсолютний fallback: хвостове усічення до carryoverTokens × 4 символів.

4.5. Маркерний протокол

Підтримувані маркери, які модель може емітити: [STATE_CHECKPOINT], [TASK_COMPLETE], [NEEDS_TOOL tool="..." input="..."], [NEEDS_CLARIFICATION]. Приймаються (але не емітяться) зворотно сумісні форми: @@@STATE@@@, [STATE], ---STATE---, @@@FINAL@@@, [FINAL], ---FINAL---, <DONE/>; кутові форми <CARRYOVER>, <DONE>, <PROGRESS>, <NEEDS_TOOL .../> — аліаси.

4.6. Оцінка токенів

estimateTokens = Math.ceil(text.length / 4) — лише fallback; пріоритет у provider-reported usage (usage.input_tokens / output_tokens), якщо провайдер їх повернув. Усі числа позначаються measured / estimated (telemetry.md). runEfficiency рахується за знімком chunkConfig конкретного прогону, а не за поточним конфігом — автори прямо пишуть, що перерахунок за поточним конфігом «produces dishonest numbers the moment anyone changes a slider». Історія: сховище markovian_history, кумулятивна статистика, ліміт 200 записів.

4.7. Replay

Run-history зберігає повний промпт і вивід по кожному чанку; реплей детермінований за тієї самої моделі й temperature=0: markovian.replay(runId). Це і є механіка «Replay · 0 tokens» — повторне виконання за збереженою структурою без повторної генерації.

4.8. Фази прогресу й телеметрія

Фази прогону: initializing → generating → compressing → reflecting → complete | error. Фінальний прохід reflection — синтез над goal + final carryover + артефакти коду; збій reflection не валить прогін. Типова ефективність за телеметрією: 80–95% на довгих прогонах, 30–50% на коротких (3–5 чанків) — також modeled. Компоновка зі swarm: якщо task.estimatedTokens > 4000 — використовувати Markovian, інакше прямий виклик.

4.9. Команди для запуску демо

# Скопіювати двигун і запустити reference
npx degit meterless/meterless/engines/hmem my-hmem
cd my-hmem/reference && npm install && npm test
npx tsx ../examples/01-add-memory/index.ts

# Замір моделі вартості Markovian
cd engines/markovian/reference && npx tsx scripts/measured-run.ts

# Conformance-прогін (приймання агента-реалізації)
HMEM_IMPL=<your build> npx tsx conformance/runner.ts
SCOUT_IMPL=<your build> npm run evals

4.10. Демо «memory compounding»

Приклад examples/memory-compounding-research: 12-крокова задача «Produce the storage-layer design brief for the local-first sync app». Холодний прогін = 12 чанків, теплий (з пам'яттю H-MEM) = 8 чанків; економія 4 чанки та 814 оцінених токенів (chars/4, позначено estimated). Прогін детермінований — «run it twice and diff». У prior-sessions.ts три сесії, і коригування сесії 2 («sqlite over IndexedDB») має переважувати сесію 1.

5. H-MEM — ієрархічна пам'ять

H-MEM (Hierarchical Memory) — двигун постійної пам'яті, яка «виживає» між сесіями. Позиціонується так: векторний пошук дає лише similarity, H-MEM додає 8-сигнальний ранжинг, provenance, життєвий цикл capture→enrich→retrieve→dream→sleep, human-approved синтез, preview-first sleep, append-only trust ledger і детекцію суперечностей.

5.1. Три рівні пам'яті

Working memory (робоча пам'ять) — актуальний поточний контекст.
Episodic memory (епізодична) — події та ситуації, що відбулися.
Semantic memory (семантична) — узагальнені факти та знання.

Усі три рівні зберігаються як grep-абльні файли на диску (наприклад, /.gaia/events.log), що робить пам'ять читабельною, аудованою та переносимою.

5.2. Структура запису пам'яті

Обов'язкові поля: confidence (ініціалізується <1.0 для вилученого/інференсного, 1.0 — тільки для спостереженого системою факту), source («reject records without it, by construction»), provenance (обов'язковий для нових записів; origin із 13 значень: chat, import, web, decision, curiosity, goal_run, user_explicit, inference, plan_run, mission, swarm_run, tool, brain). Обмеження: entities — до 10 на запис, relatedTo — до 5.

Інваріант мутації: «No create, update, delete, feedback, promotion, archive, synthesis, or resolution happens without a trust ledger entry» (жодне створення, оновлення, видалення, зворотний зв'язок, просування, архівування, синтез чи вирішення не відбувається без запису в реєстрі довіри).

5.3. Формула ранжування під час вилучення

З reference/src/memoryRetrieval.ts і retrieval-ranking.md:

raw = 0.35*semantic + 0.20*keyword + 0.10*tag + 0.10*domain + 0.15*entity + 0.05*layer + 0.05*recency - 0.20*superseded
score = clamp01(raw) * confidence

Ваги рівнів: long_term 1.0, working 0.8, short_term 0.6. Розпад recency — експоненційний, ~14 днів. Поріг фінального score 0.35, topN=5. Зворотний зв'язок: helpful +0.05, not_helpful -0.03, wrong -0.20 + тег review. Вузли з тегами review/wrong не інжектуються без явної аудит-стратегії («Memory is context, not instruction»).

5.4. Mining (добування пам'яті)

7 канонічних подій: chat_message, user_correction, file_save, file_open, file_edit, model_response, plan_completion. Мапінг: user_correction → preference, file_edit → factual тощо. Model-free шлях (дефолт): розбиття на речення, фільтр 20–300 символів, regex-сигнал \b(prefer|always|never|decided|chose|choose|use|because|instead|must|should|important|remember)\b, максимум 10 кандидатів. З моделлю: строгий JSON-масив рядків зі стійким парсером (fences + зріз за першою «[»/останньою «]»). Fallback за збою моделі: truncate(event.content, 240), type=general, layer=short_term, теги fallback:no-model.

5.5. Embeddings

Детермінований mock: токенізація lowercase → лише [a-z0-9\s] → довжина > 1; хеш FNV-1a на токен у 64-вимірний вектор (sign за бітом, magnitude 1–2), сума, L2-нормалізація. cosine — скалярний добуток одиничних векторів; jaccard за множинами. Відтворювано між машинами — такий контракт; реальний embedder підміняється.

5.6. Trust ledger (реєстр довіри)

17 типів дій (add_memory, feedback_applied, memory_updated, memory_archived, memory_consolidated, memory_synthesized, conflict_detected, conflict_resolved, dream_proposal_created, dream_proposal_approved, dream_proposal_rejected, ledger_rotated та ін.). Append-only; «чистка» ніколи не деструктивна: перед усіченням пишеться ledger_rotated із номерами пропущених записів.

5.7. Dreaming і Sleep

Dreaming: кластери мінімум із 2 записів; relatedness = 0.5*cosine + 0.2*jaccard(tags) + 0.1*(same domain) + 0.2*jaccard(entities); типи пропозицій insight/invariant/domain, максимум 8 пропозицій кожного типу. Межа схвалення людиною: без approval пропозиція не стає пам'яттю; синтез отримує derivedFrom.
Sleep: консолідація — запис без доступу ≥7 днів у short_term/working → long_term; архів — ≥30 днів І accessCount ≤ 2 І без посилань; синтез — cosine ≥0.82; preview-first: спершу план із backup, застосування лише після підтвердження.

5.8. Детекція та вирішення конфліктів

Пари протиставлень always/never, enable/disable, prefer/avoid, on/off, yes/no. Конфлікт за cosine > 0.5 (confidence = 0.5 + 0.3·sim); висока схожість із різними числами за sim > 0.8 (confidence = 0.55 + 0.25·sim). Скоринг автовирішення: 0.3*recency + 0.2*access/10 + 0.25*confidence + 0.1*richness/200 + 0.15*(origin==user_correction ? 1 : 0.5); decisionConfidence = clamp01(conflict.confidence*0.6 + margin*0.8). Гейт автовирішення ≥ 0.70; інакше — черга людині. Програлий запис отримує supersededBy — зберігається, штраф -0.20 у ранжуванні, ніколи не видаляється. Скан — щодня; кожне вирішення — запис у ledger.

6. World Model — єдина модель світу

World Model відповідає на питання «що істинно зараз». Це канонічне сховище сутностей, контекстів, відношень, подій і похідних уявлень. Відрізняє себе від knowledge graph (append-only проти edit-in-place) і vector DB (модель домену, а не пошук за текстом).

6.1. Канонічне сховище

5 write-примітивів: upsertEntity, upsertContext, relate, assertFact, snapshot. Системні види подій: tombstone, alias, view-rebuild. Стан — згортка (fold) над логом; кожен вид — проекція. Персистенція reference: JSON-файл на неймспейс .world/<namespace>.json із реплеєм під час завантаження. Provenance обов'язкова: «If a write has no provenance, it gets rejected at the boundary. There is no exception.» Семантика relate: нове відкрите ребро з тими самими (from, type, context), але іншим target закриває попереднє (validTo + supersededBy). Never delete.

6.2. Стабільні ідентифікатори

Зовнішньо-ключові: id = type:system:externalId (наприклад account:salesforce:0015g00000A1b2cAAA). Name-keyed fallback: ent_${sha256(type:normalizeName(name)).hex.slice(0,16)}. normalizeName = lowercase → NFKD → зняття діакритики → схлопування пробілів → trim. ID контексту містить батька; ID відношення — hash(from+type+to+context+validFrom). Злиття → первинний + аліас; посилання на аліас прозоро резолвляться; анмердж — одна інверсна alias-запис.

6.3. Пайплайн інгесту

Внутрішній цикл із 6 стадій на спостереження: extract → normalize → resolve → validate → append → project (append — єдина exactly-once стадія). Зовнішній цикл із 10 кроків: 1) Reconcile, 2) Cluster/classify, 3) Persist primary aggregates, 4) Score/measure (velocity(w) = mentions/hours за вікнами 1h/24h/7d; trendDirection = sign(різниці сусідніх бакетів)), 5) Infer derived, 6) Persist edges, 7) Rebuild views, 8) Patch source items, 9) Rebuild aggregates, 10) Mark stale. Пряма заборона пропускати 9–10. Ідемпотентність: content-addressed dedupe-ключ, чекпоїнти, append-only лог; тест: «Run the pipeline twice... Diff should be empty.» Кластеризація: entity-overlap Jaccard ≥ 0.5 АБО embedding cosine ≥ 0.85. Старіння: 30 днів (stale).

6.4. Вирішення сутностей

У репозиторії співіснують дві схеми порогів (виявлена розбіжність документації): reference/src/resolve.ts — ≥0.85 auto-merge, 0.82–0.85 review-черга, <0.82 нова сутність (similarity = 1 − levenshtein/max(lenA,lenB)); HOW_TO_USE_WORLD_MODEL.md — ≥0.92 auto-merge, 0.82–0.92 черга, <0.82 нова. Фактичний дефолт reference — 0.85.

6.5. Конкурентність і control plane

Монотонний тотальний порядок усередині неймспейсу (за порядком append, не за годинником). Стратегії конфліктів: most-recent-wins / highest-confidence-wins / source-priority / manual — впливають лише на похідний вид, жоден запис не втрачається. Ліміти конкурентності: Extract 4, Normalize 8, Resolve 4, Validate 16, Append 1 (serialized), Project 2. Читання — eventually consistent; waitForConsistency() і atEvent() для строгого режиму.

Control plane (5 можливостей): Inspect, Merge (side-by-side diff → одна alias-запис → оборотно з аудиту), Edit (новий запис з операторською provenance, supersedes — не перезапис), Rebuild (wipe і репроекція, канон не чіпається), Repair (replay джерела за вікно; погані події лишаються в лозі). Ролі: Viewer/Editor/Admin. «A world model with no control plane calcifies» (модель світу без control plane скам'яніває).

7. Scout Intent — вибір правильної дії

Scout Intent відповідає на питання «чи можна і як діяти». Перший принцип AGENTS.md: «Nothing acts on a raw prompt» — нижчі двигуни діють лише за підписаними контрактами виконання. Другий: «If an intent is not in the registry, it cannot be acted on».

7.1. Пайплайн із 5 стадій

Sense → Interpret → Guard → Route → Recommend → ExecutionContract

Sense: top-k кандидатів (ніколи одна мітка). Stage-1 — детермінований trigger-скан по всьому реєстру за < 16 мс (закріплений startup self-test'ом). Stage-2 — опційний гібридний рескоринг (локальний класифікатор 50–200 МБ, типово 20–80 мс клієнтськи). Деградація: без Stage-2 лишається результат Stage-1.
Guard: 4 шари (ін'єкції, політика/RBAC, PII-редагування, rate limits); вихід low|medium|high|block. Детекція ін'єкцій: known-pattern (роль-конфузні маркери, </system>, [INST]), role-drift, out-of-band tool-посилання, опційна мала модель. Пейлоади ін'єкцій за замовчуванням НЕ логуються повністю.
Route: граф можливостей (capability graph) → tool plan; правила вибору за пріоритетом: 1) permissions, 2) availability, 3) surface preference, 4) cost/latency budget, 5) tie-break — local-first. Нерозв'язана можливість → структурована помилка, ніколи не вигаданий інструмент.
Recommend: вибір model-профілю + підпис контракту.

7.2. Скоринг і бенди

finalScore = 0.40*lexical + 0.35*semantic + 0.20*contextual + 0.05*recency - riskPenalty

Бенди («the load-bearing numbers»): High ≥ 0.80 (пряма маршрутизація), Medium 0.55–0.79 (прогрес + лог + «did you mean?»), Low 0.40–0.54 (уточнення з top-3 кнопками), Reject < 0.40 (fallback на безпечний GENERAL; «never guess a high-risk intent»).

Тригери уточнення (4): 1) top-1 у Low-бенді; 2) top-1 і top-2 у межах 0.05 один від одного в Medium-бенді; 3) не зв'язується обов'язковий параметр; 4) intent із riskClass=high нижче 0.95 впевненості. Мульти-інтент: обидва кандидати у High-бенді з непересічними спанами → план із двох інтентів; вторинні інтенти ≥ 0.55.

7.3. Реєстр інтентів

Канонічний реєстр: 131 інтент + 8 topology-векторів. 31 foundation (GENERAL, CODE, SWARM, RESEARCH, ARCHITECT, EDIT, MEMORY, MISSION, DEBATE, DESTRUCTIVE, EXPLAIN, ENHANCE, TESTER, DEBUGGER, DEVOPS, SECURITY, DATABASE, DATA_SCIENTIST, WRITER, DESIGNER, TECHNICAL_WRITER, TRANSLATOR, BUSINESS_ANALYST, TUTOR, CODE_REVIEWER, OPTIMIZER, API_DESIGNER, PROJECT_MANAGER, ACCESSIBILITY, MUSICIAN, LEGAL) + 100 expansion за 10 групами (advanced code 12, memory & context 10, swarm & orchestration 10, mission 8, workspace & files 8, specialized dev 12, quality & maintenance 10, AI & automation 8, communication 8, platform admin 8, data & visualization 6). Вектори: pipeline, fan_out, debate, loop, hierarchical, star, tree, mesh — емітяться як scout_topology_pattern для вибору DAG. registryVersion штампується в кожен контракт.

Приклад інтента з fixture: deal.recover — параметри count (int 1..20), channel (enum email/call/slack), stage (optional), capabilities [world.query, swarm.run, memory.recall], riskClass medium, поверхні [chat, inbox], ролі [ae, csm, sales-leader], version 3.

7.4. Контракт виконання

Структура: contractId (ULID), traceId, intent.primary (id + confidence + параметри + alternates), risk (level/flags/redactions/approvals), toolPlan, modelProfile, scope (user, capabilities — точна дозволена множина, budget costMaxUSD), issuedAt/expiresAt, registryVersion, policyPackVersion, signature = HMAC_SHA256(secret, canonical_json(contract_without_signature)), signedBy.

TTL за замовчуванням 5 хвилин; «Never extend TTL; long-running work refreshes contracts per chunk/phase with the original as parentId» (scout.replan({parent, reason, state}), спільний traceId).
verifyContract: 1) перерахунок HMAC за канонічним JSON мінус сигнатура; 2) now() < expiresAt; 3) обов'язкові approval для high-risk. «Signature is mandatory at every boundary, including dev.»
«The contract is the only thing downstream trusts». Відмова за межами scope — на межі виконавця.
Приклад 04 демонструє tamper-check: підміна capabilities на [«DANGEROUS.tool»] → FAIL.

7.5. Маршрутизація моделей

Профілі: default-fast (gpt-4.1-nano, 128k, $0.0001 вхід/$0.0004 вихід, p95 800 мс), default-capable (claude-opus-4-7, 200k, $0.003/$0.015, p95 2200 мс), local-capable (webllm llama-3.1-8b-instruct, 32k, $0, p95 4000 мс, усі dataClasses аж до restricted). Правила: сумісність, data class, context budget, cost target, latency target, quality target; tie-break — local. Ланцюги: local-first дефолт (local-fast → local-capable → remote-fast). Cost ceilings: intent.deal.recover: perInvocation 0.05 USD, surface.chat: perDay 5.00. BYOK: «Every remote profile requires user-supplied API keys. Scout doesn't proxy. There's no Meterless-hosted model gateway.»

7.6. Eval-харнес

Корпус v1: 32 приклади (15 intent, 10 injection, 3 multi-intent, 4 edge). Запуск: SCOUT_IMPL=/abs/path npm run evals. 7 метрик із таргетами та хард-флорами:

Метрика	Target	Hard floor
intent_top1	0.92	0.85
intent_top3_recall	0.98	0.94
injection_precision	0.95	0.90
injection_recall	0.90	0.82
tool_precision	0.88	0.80
clarification_rate	max 0.15	hard max 0.25
override_frequency	max 0.08	hard max 0.15

Slice-флори (захист від приховування провалів агрегатами): intent_top1 ≥ 0.80 і injection_precision ≥ 0.85 за surface/role/intent family/risk class. Важливо: це цілі, а не виміряні результати — у README прямо: «targets are not measured results», і вимога: претендувати на досягнення таргетів можна лише за ≥50 прикладів на велике сімейство. Телеметрія: логується trace_id, contract_id, prompt_hash (sha256) — але не raw prompt, не параметри, не tool I/O, не ключі. Приклад латентності: sense 18 / interpret 32 / guard 22 / route 8 / recommend 4 мс. Оверрайд = gold label для навчання; ретрейн щотижня.

8. Ліцензування та статистика репозиторіїв

8.1. Ліцензії

Двигуни та головний репозиторій — Apache 2.0 (перевірено дослівно в усіх п'яти LICENSE): «Apache 2.0-licensed. Yours forever.»
Продуктові застосунки (Gaia, Relay, Swarms) — Meterless Permissive Use License (пропрієтарна «permissive» ліцензія): «covers personal, commercial, research, and production use. The one thing you cannot do is resell or redistribute Gaia itself as a competing product. There is no paid tier... no subscription, no in-app purchases». Ключове обмеження — заборона перепродажу/субліцензування/поширення застосунку як самостійного продукту.
Маркетинговий тезис: «No npm packages to wait on, no runtime lock-in, no license meter. The spec is the product.»

8.2. Статистика (GitHub API, 20.08.2026)

Репозиторій	Створено	Зірки	Форки	Комміти	Останній push
Meterless/Meterless	2026-07-13	224	34	10	2026-07-24
Meterless/Gaia	2026-05-07	1	0	7	2026-07-17
Meterless/Relay	2026-05-07	2	0	13	2026-08-01
Meterless/Swarms	2026-05-07	6	2	13	2026-08-01

Релізи: Meterless v1.0.6 (2026-07-21, meterless-suite-installer.msi), Gaia v3.1.4 (2026-05-27, exe ~27 МБ), Relay v0.7.12 (2026-05-27, exe ~3 МБ), Swarms v0.1.9 (2026-05-27, exe ~11 МБ). Показово: зірки та комміти зосереджені в головному репозиторії (специфікації), продукти — допоміжні репозиторії з одним релізом і без вихідного коду. ROADMAP: swarm-orchestration — серпень 2026, runtime — Q4 2026, далі fulcrum. Контакт безпеки (SECURITY.md): sam@thedataplant.com. Стиль репозиторію: kebab-case імена, короткі декларативні речення, без em-dash, без знаків оклику.

9. Ціни та монетизація

Опублікованого прайс-листа немає — продукт у стадії early access:

Вільні інструменти (Swarms, конвертери, PDF Workbench, Image Batch Studio): безкоштовно, без акаунта, усе локально.
Relay і Gaia: «продуктові бінарники пропрієтарні та безкоштовні в період раннього доступу» (з релізних нотаток і discussion #2).
Enterprise: «ціни на запит» — внутрішні agentathons, forward-deployed впровадження, ліцензування двигунів/рантайму, корпоративне розгортання (about.html). Контакт: partnerships@meterless.ai.
Демо-бюджет Gaia «$0.00/$1.60, BUDGET $1.60 CAP» — частина демо-UI, а не тариф.

Увага: у низці оглядів фігурує міф про тарифи «$20–200/міс як у Claude Cowork» — для Meterless таких тарифів не публікувалося; реальна модель монетизації не розкрита.

10. Незалежні огляди та критика

10.1. Wavect — головний незалежний розбір

Кевін Рідль (Wavect, 22 липня 2026) провів перевірку фактів проти першоджерел. Ключові висновки:

Meterless — не open-source клон Claude Cowork: «Meterless is not an open-source Cowork clone, and we could not verify the ex-Anthropic attribution from the project repository, website, or named maintainer material available on 22 July 2026» (не вдалося підтвердити атрибуцію «екс-інженер Anthropic»). Вірусний наратив «екс-інженер Anthropic відкрив вихідники Cowork» не підтверджується.
Межа відкритості: двигуни відкриті (спека + референс + conformance), але бінарники Gaia/Relay/Swarms — пропрієтарні: «Engine openness does not make the complete product stack open source».
Три типи доказів не можна змішувати:

 * 12 чанків cold / 8 warm, 814 зекономлених токенів — відтворюване детерміноване демо на mock-генераторі, токени = символи ÷ 4. Доводить, що накопичена пам'ять дає змогу пропускати вирішені кроки; НЕ доводить якість живої моделі, білінг провайдера чи production ROI.
 * 86% за 20 кроків — математична модель із фіксованими припущеннями. Доводить кращу асимптотику входу у bounded carryover; НЕ доводить, що агент зберігає достатньо інформації для успіху.
 * 97% за 100 кроків — та сама модель, продовжена на довгий прогін. Доводить зростання економії з довжиною; НЕ доводить, що 100-крокова задача завершиться коректно/безпечно/швидше.

Технічна критика: «It can also discard the detail that makes the next decision correct. The production question is therefore not "did context shrink?" It is "did successful task cost fall without lowering task success, factual consistency, policy compliance, or recoverability?"» (стиснення може відкинути деталь, яка робить наступне рішення правильним; виробниче питання — не «стиснувся чи контекст», а «чи впала вартість успішної задачі без падіння успішності, фактичної узгодженості, дотримання політик і відновлюваності»).
Колізія імен: Meterless H-MEM — не те саме, що травнева стаття arXiv «H-Mem» (2605.15701) — «Do not use the paper as independent proof for the product».
Вердикт: «Treat Meterless as architecture you can inspect, a pilot you can measure, and a possible foundation you must still engineer» (ставтеся як до архітектури, яку можна інспектувати, пілота, який можна виміряти, і можливого фундаменту, який усе одно доведеться будувати самим). Плюс дисклеймер: Wavect продає AI-консалтинг, тому критерії пілота автор зробив максимально вимірюваними.

10.2. IKE Analytics — «The Blank Layer»

Ісаак Лієм (10 серпня 2026) розбирає Meterless у контексті проблеми «шару доказів» (evidence layer) в агентному AI. Запис від 13 липня:

> «Their own documentation says the signature is "not a cryptographic-grade defense." The daemon signs itself. The ledger is an append-only audit trail with no signature at all, and nothing but policy stops the party running it from rewriting history. They are honest about this, which I respect. It is simply not the layer.»

Суть критики: запис працює як доказ, лише якщо його тримає сторона, не зацікавлена в його змісті. Агент не може бути зберігачем, бо він — суб'єкт; вендор не може, бо він — зацікавлена сторона. Для незалежного аудиту («eviduciary» — фідуціарій доказів) реєстр Meterless не підходить. Це критика довірчої архітектури, а не економіки токенів — важлива як межа застосовності.

10.3. LinkedIn-обговорення

Нікіта Худорожков (репост вірусного посту Алекса Ванга): «The expensive part of a long agent run is not the model. It is that every step drags the full history behind it. Meterless compresses the state the agent carries forward, not the logs. 86% fewer input tokens over 20 steps. Context is becoming the whole game.»
Алекс Ванг (оригінальний вірусний пост, 386 реакцій, 76 коментарів): «Each step receives only: → The original goal → A compressed state from the previous step → The context needed for the next action... The repo models an 86% reduction in input tokens over a 20-step task» — важливо: навіть у хвалебному пості прямо вказано «the repo models» (моделює), а не вимірює.
Бікрам С. (найзмістовніша критика в LinkedIn): «Everyone's sharing the 86% token reduction from Meterless's Markovian Engine. That's the wrong number to be excited about... The headline win isn't efficiency. It's that the system throws away the right things.» І головне попередження: «Sufficiency — whether the state you kept is enough for the step you haven't taken yet — is the thing that actually decides success. Compress against the wrong schema and it won't error; it'll produce something plausible and wrong, with no trace back to the drop» (достатність збереженого стану вирішує успіх; за стиснення за неправильною схемою система не помилиться явно, а видасть правдоподібний і неправильний результат без сліду втрати).
Сабріна Станевська (про Swarms): «You give it a single goal and it auto-generates an agent graph: a designer, a copywriter, a UX researcher, a brand strategist, each spun up in parallel... It also runs local-first, in-browser, no account, nothing uploaded.» Єдиний коментар (Мартін Міхаель Фредеріксен): «Surprisingly generic and anonymous outcome» — скепсис щодо якості результату.
Стів Нурі: пост недоступний (логін-стіна LinkedIn), заголовок вказує на наратив «екс-інженер Anthropic відкрив вихідники Claude Cowork», який Wavect не зміг підтвердити.

10.4. Контекстні українсько- та російськомовні матеріали

Хабр 1066896, «Агент за долар» (stas-clear, 5 серп.): головна арифметика — кеш префікса, а не стиснення: вхід із промахом кешу $0.14/млн токенів, вхід із влучанням у кеш $0.0028, вихід $0.28 — «розрив між двома рядками входу п'ятдесятикратний». Частка незмінної частини входу в агентних циклах «сягає понад дев'яносто відсотків» — стабільна «шапка» йде в кеш. Що ламає кеш: мітка часу, ідентифікатор сесії, перетасований порядок інструментів, динамічний список файлів, RAG-фрагменти перед основнім контекстом. Правило: «незмінне — на початок, змінне — у хвіст». Перемикання моделі скидає кеш.
vc.ru (Дмитро Ільїн, 15 травня): «GitHub MCP-сервер із 43 інструментами — навіть простий запит міг тягнути близько 44 000 токенів за ітерацію; за трьох стандартних MCP-серверів службовий контекст сягав 143 000 токенів». «10 000 операцій через зв'язку CLI + Skills коштували приблизно $3.20, а через віддалені MCP-сервери — близько $55.20»; «28% запусків падали через мережеві таймаути». Висновок: «якщо агент щоразу тягне великий список інструментів, він платить токенами ще до того, як почав думати».
Хабр 1065426 — статтю «Один хід агента — 120 000 токенів» знято з публікації модератором на момент дослідження.

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

11. Порівняння з альтернативами

11.1. Claude Cowork (Anthropic)

За даними Wavect, Anthropic описує Cowork як десктопні робочі простори з файлами, інструкціями, планувальником задач, контекстом і пам'яттю з областю проєкту. Meterless публікує перевикористовувані специфікації двигунів і пропонує окремі продуктові поверхні. Вони перетинаються в амбіції зберігати контекст між роботами, але не взаємозамінні.

Критерій	Claude Cowork	Meterless engines	Custom build
Швидкий шлях для knowledge workers	Найсильніший	Потребує реалізації або пропрієтарних застосунків Meterless	Найслабший
Володіння пам'яттю та контрактами контексту	Обмежено контролами продукту	Сильна архітектурна відправна точка	Максимальний контроль
Продакшн-інтеграція у ваш SaaS	Не його завдання	Можливо після інженерної роботи	Спроєктовано під вашу систему
Час до першого workflow	Години	Дні для reference, довше для продакшену	Тижні чи місяці
Незалежність від вендора	Низька–середня	Середня–висока на рівні контрактів двигунів	Висока

11.2. OpenClaw та його екосистема

На about.html Meterless публікує self-порівняння проти екосистеми OpenClaw (NemoClaw, ZeroClaw, OmegaClaw, Hermes): «Екосистема OpenClaw довела попит, але роздробилася на спеціалізовані форки. Meterless об'єднує те, що вони роздробили... перевершує всіх на grounding, desktop control і orchestration». Це маркетинг, а не незалежна оцінка. З контекстних статей по ринку (getsliq, autonomous.ai, contracollective, strategized.ai, coey) випливає, що підхід «computer use через пікселі» (OpenClaw/Relay-стиль) менш надійний, ніж детерміновані API-інтеграції (Cowork); а проблема «replayability» (відтворюваності чат-агента) реально визнається індустрією — її розв'язують і n8n, і COEY.

11.3. Скіли (skills) і MCP

На відміну від скілів (статичних описів повторюваних задач) і MCP-серверів (інструментальних інтерфейсів), Meterless зберігає динамічний процес — послідовність виконаних кроків із перевіреними результатами. Показова формулювання Relay: «workflows that compile, not click-coordinates that break» — робочі процеси, які компілюються, а не координати кліків, які ламаються: прив'язка до живих HWND вікон, а не до координат пікселів. Зв'язок із проблемою з vc.ru: скіли та локальні CLI дешевші за MCP саме тому, що не тягнуть службовий контекст інструментів — та сама логіка, що й у bounded carryover.

12. Синтез: що перевірено, а що заявлено

12.1. Що доведено

Механіка двигунів, межі ліцензій, наявність специфікацій/reference-реалізацій/conformance-тестів — перевіряється у відкритому репозиторії.
Математична асимптотика коректна: квадратичне зростання наївного накопичення проти лінійного у bounded carryover (формула efficiency-model.md).
Детермінованість демо: 12-крокове демо memory-compounding можна повторити («run it twice and diff»).
Чесність застережень: репозиторій сам позначає цифри як modeled, визнає, що компресія не безкоштовна, що tool-виклики дають змінну вартість, що chars/4 — лише fallback.

12.2. Що заявлено, але не підтверджено незалежно

86% / 97% / 7.3–15× — модельні цифри, а не незалежні бенчмарки (Wavect: «No» на питання про independent benchmarking).
814 токенів демо — оцінка за «символи ÷ 4» на mock-моделі.
«0 токенів за replay» — маркетингове спрощення; насправді replay коштує прогін за збереженою структурою (можливо, 0 нових генерацій, але не «0 вартості» в сенсі білінгу провайдера за живої верифікації).
«Екс-інженер Anthropic відкрив Cowork» — не підтверджено.
Self-скоркарди на about.html (26/30 проти Fable 5 тощо) — без опублікованої методології.
Eval-таргети Scout (precision ≥0.95 тощо) — цілі, а не виміряні результати; корпус із 32 прикладів малий.

12.3. Ключові ризики

1. Проблема достатності (sufficiency): агресивне стиснення обмінює токени на ризик втрати критичного факту; система видасть «правдоподібно неправильний» результат без сліду відкинутого (Бікрам, Wavect). 2. Доларова економія менша за токенну: промпт-кеш провайдерів (50× у DeepSeek Flash) уже робить повторне читання історії майже безкоштовним; реальна економія від реплею — на «хвості» прогону та на вихідних токенах. Перевіряти потрібно provider-reported usage, а не chars/4. 3. Довірчий шар: trust ledger і підписані контракти — не «шар доказів» (Лієм): підпис не криптографічний, демон підписує сам себе, append-only журнал без підпису. 4. Пропрієтарність продуктів: «open source» стосується лише двигунів; бінарники закриті, незалежної аудиторської оцінки їхньої безпеки немає. 5. Зрілість: Scout не встановлюється як npm-пакет; три двигуни — «не production-бібліотеки», а специфікації; Relay лише Windows; Swarm orchestration ще в waitlist.

13. Безпека та приватність

Relay свідомо відмовляється від шела й доступу до ФС/мережі/процесів, працюючи лише через вибрані вікна (HWND) — позиціонується як плюс безпеки; але незалежної оцінки закритих бінарників немає.
Gaia: дані на пристрої, ключі в apiKeyVault, заявлено відсутність неініційованого вихідного трафіку, немає телеметрії та crash-report. Desktop control через OAuth-сесії, rate limit 60 дій/с, Emergency Stop.
Scout: BYOK — жодного Meterless-hosted model gateway; логуються лише хеші промптів, не самі промпти й не параметри; ін'єкційні пейлоади не логуються повністю.
Ризик-модель Gaia: «anything judged destructive is refused rather than executed — the step fails as "refused destructive"» (усе, що оцінено як деструктивне, відхиляється; крок падає з помилкою «refused destructive»).

14. Практичні рекомендації: як перевірити на своїй задачі

Wavect пропонує двотижневий пілот (критерії відтворювані):

1. Виберіть один повторюваний workflow на 8–20 кроків (підходить support investigation, account research, збір доказів для комплаєнсу, triage репозиторію). 2. Заморозьте базову лінію: успішність задач, вхідні/вихідні токени, латентність, ретраї, час ручних виправлень, збої інструментів. 3. Почніть з одного двигуна: H-MEM, якщо болить забування між сесіями; Markovian, якщо домінує роздування історії. Не інтегруйте всі чотири одразу. 4. Створіть adversarial memory-кейси: виправлення, застарілі факти, конфліктні джерела, відкликання доступу, видалення, отруєна/нерелевантна пам'ять. 5. Проведіть сліпі приймальні перевірки: рецензент оцінює якість результату, не знаючи, чий це результат. 6. Інспектуйте траси та збережений стан: що було згадано, чому відранжовано так, що стиснуто, чи збереглася provenance. 7. Рішення про продовження — за виміряною цінністю: успішність-вартість, надійність, контроль оператора.

Ключове питання оцінки, сформульоване Wavect і підтримане Бікрамом: не «стиснувся чи контекст», а «чи впала вартість успішної задачі без зниження успішності, фактичної узгодженості, дотримання політик і відновлюваності».

Для відтворюваних команд:

# Відтворення демо економії
npx degit meterless/meterless/engines/markovian my-markovian
cd my-markovian/reference && npm install && npm test
npx tsx ../examples/token-savings-demo/index.ts   # очікується: naive 246000, markovian 34000, Efficiency 86%

15. Плюси та мінуси

Плюси

Сильна і чесно задокументована архітектурна ідея: розділення пам'яті, стану світу, обмеженого розмірковування та маршрутизації намірів.
Відкриті специфікації з reference-реалізаціями та conformance-тестами — можна вивчати, відтворювати, будувати власні реалізації.
Реальний внесок у дискусію: «процес — актив», а не «відповідь — продукт»; явна спроба розв'язати проблему втрати контексту між сесіями.
Локальність: дані на пристрої, BYOK, відсутність хмарного шлюзу моделей, вільні інструменти без акаунта.
Безпека за конструкцією в Relay (тільки вікна, без шела/ФС) і risk-гардування в Scout.
Величезний обсяг інженерної деталізації (131 інтент, 8-сигнальний ранжинг, 17 типів ledger-дій, каскад стиснення) — видно високий рівень інженерної культури.

Мінуси

Заявлені цифри економії (86%, 90%, 7.3–15×) не підтверджені незалежними бенчмарками — це модельні оцінки.
Промпт-кешування провайдерів уже дає велику частину «економії» на повторному читанні — доларовий ефект невідомий.
Ризик тихих втрат контексту за агресивного стиснення («правдоподібно неправильні» результати без сліду).
Довірчий шар не є незалежним доказом (самопідписний демон, append-only без підпису).
Продукти пропрієтарні, лише Windows (Relay), Mac/Linux — у планах; проєкт молодий (репозиторій із липня 2026).
Реєстр намірів (131 інтент) і eval-корпус (32 приклади) малі для заявлених метрик якості.
Є розбіжності в документації (пороги вирішення сутностей 0.85 vs 0.92; ризик в ілюстративному контракті vs registry riskClass).
Немає публічної моделі монетизації; довгострокова стійкість проєкту незрозуміла.

16. Висновки

Meterless — один із найамбітніших проєктів 2026 року в галузі агентного AI: він намагається зробити «роботу, яку виконує AI», перевикористовуваним активом користувача. Ідея зберігати не відповідь, а процес — планування, міркування, пам'ять, стан, перевірені кроки — архітектурно обґрунтована й інженерно продумана. Відкриті двигуни (Apache 2.0) з reference-реалізаціями та conformance-тестами дають змогу будь-кому вивчити та відтворити ключові механізми, а чесні застереження у власній документації (усі цифри позначені як modeled) викликають повагу.

Водночас, станом на серпень 2026 року проєкт молодий (менш ніж два місяці від публікації репозиторію), продукти закриті та існують лише під Windows, а заявлені 90% економії токенів — модельні оцінки, а не незалежні вимірювання. Головний практичний ризик — не «чи зекономили ми токени», а «чи втратили ми правильну деталь»: стиснення стану може дати правдоподібно неправильний результат без сліду до відкинутого контексту. Доларова ж вигода частково з'їдається провайдерським промпт-кешуванням.

Розумна позиція: вивчати Meterless як архітектурну специфікацію, пілотувати на одній повторюваній задачі із замороженою базовою лінією та власними вимірюваннями, і не закладати в бюджет недоведені цифри. Ідея «процес — це актив» перспективна; питання лише в тому, наскільки акуратно розв'язана проблема достатності збереженого стану і наскільки чесно буде виміряна реальна економія на живих моделях.

Резюме

meterless.ai — локально зорієнтований стек для агентного AI, який зберігає не відповідь нейромережі, а сам процес її отримання: план, міркування, стан, пам'ять і перевірені кроки. Три продукти (Relay — десктоп-автоматизація з vision-верифікацією, Gaia — постійне середовище з ієрархічною пам'яттю та 12 «мозками», Swarms — браузерний генератор графа агентів) спираються на п'ять відкритих двигунів (H-MEM, World Model, Markovian, Scout Intent, Swarm orchestration). Ядро економії — двигун Markovian із bounded carryover: кожен крок отримує лише мету, стиснутий стан і контекст наступної дії, що дає лінійне (замість квадратичного) зростання витрат і заявлену економію до 86–97% токенів на довгих прогонах. Однак усі ці цифри — змодельовані, а не виміряні; незалежні огляди (Wavect, IKE Analytics) підтверджують архітектурну цінність і прозорість, але відзначають непідтверджені бенчмарки, пропрієтарність продуктових бінарників, ризик «тихих втрат» контексту за стиснення та недостатність довірчого шару для незалежного аудиту. Проєкт перспективний як архітектурна специфікація та пілот, але потребує власної перевірки успішності задач, пам'яті та реальної економії на живій моделі.

Ссылки

Офіційний сайт: meterless.ai
Офіційна документація (додатки та двигуни) — у репозиторіях GitHub організації meterless
GitHub-організація: github.com/meterless
Головний репозиторій: github.com/Meterless/Meterless (README, CHANGELOG, ROADMAP, engines/)
Незалежний огляд Wavect: wavect.io/blog/meterless-ai-agent-context-layer-review/
Критика довірчого шару (IKE Analytics): ikeanalytics.com/articles/the-blank-layer/
LinkedIn-обговорення: пости Нікіти Худорожкова, Бікрама С., Сабріни Станевської, Стіва Нурі
Хабр: «Агент за долар: як улаштована економіка зв'язки Hermes Agent + DeepSeek V4 Flash» (habr.com/ru/articles/1066896/)
vc.ru: «Як AI-агент палить бюджет ще до початку роботи: коли MCP зайвий, а навички достатньо» (vc.ru/ai/2925450-kak-ii-agent-ekonomit-byudzet-navyki-protiv-mcp)
Стаття arXiv H-Mem (однойменна, НЕ стосується Meterless): arxiv.org/abs/2605.15701
MEMPROBE (про оцінку пам'яті агентів): arxiv.org/abs/2606.24595

×