v1.2.0

Every engine reports its tokens

LangChain, LlamaIndex and the OpenAI Agents SDK now read the token usage OVMS sends back, like OVAT's own loop always did. ovat bench and ovat run --trace show prompt and completion tokens and tool calls for all four engines. Verified on the AI PC: native 2002/485, react 1410/387, llamaindex 1456/224, openai-agents 1418/218. A server that sends no usage still shows a dash, never a zero.

A clearer telemetry page

• Two tabs, Live and Help, instead of four.
• A status line under the numbers says, every second, whether each source is live, silent or not available, and why.
• The POWER card appears as soon as Intel Unified Telemetry sends its first reading.
• Fixed a crash that could happen when leaving the page while its cards were being rebuilt.

A running command shows progress

In the TUI launcher, a running command's status line now moves: a spinner, the seconds so far and the newest output line. The exit line shows how long it took.

Docs

README, ARCHITECTURE and the examples are rewritten in plain language with animated diagrams. The architecture doc now has a glossary, a stack diagram and a sequence diagram, a table of required and optional parts, and a separate design decisions log. There is a new docs site with the demo video: https://lagmator22.github.io/ovat-navigate/

All CI jobs green on Ubuntu 22.04 and 24.04, Windows and macOS.

v1.1.1

Fixes from a hands-on test of the TUI on the LunarLake AI PC. 13 of 14 checks passed, and everything that failed or looked wrong is fixed here, each with a test that fails without the fix.

Local chat

• Answers are no longer cut off. Local chat and ovat chat had a 1024- and 256-token cap, and Qwen3.5 spent all of it reasoning ("Final Check: Did"). There is no default cap now: the answer streams, and Esc or Ctrl-C stops it. /tokens N and --max-tokens N still set one. The OVMS engine keeps model.max_tokens (4096).
• The local model is told it has no tools. Local chat sent the agent prompt ("Always call search_docs") to a model that already has the search result. Measured on Qwen3.5-0.8B: 1 of 3 answers right, each starting with the word "search_docs". With one added note: 3 of 3.
• /thinking shows Qwen3.5's reasoning. Its template opens the <think> block in the prompt, and the reasoning before the lone closing tag was thrown away.
• The sources line survives /thinking and /load.
• Clearer model errors. A wrong path says "no model folder at ...", suggestions show their folders, and an embedding model (Qwen3-Embedding, whose config says CausalLM) is no longer offered for chat.

Everything else

• openvino-genai >= 2026.4 is now required. 2026.2 crashed with no error message while loading OpenVINO/Qwen3.5-0.8B-int4-ov, the README's smallest model.
• Stale index warning. ovat index records when each file was indexed, and ovat run / ovat chat say when a document changed since then. An old index once answered with a claim the docs had dropped weeks earlier.
• Small windows keep the prompt. Below 24 rows the header hides, and the Updates heading no longer wraps into scrambled blocks.
• No hover tooltips on the footer.

812 tests; CI green across Ubuntu 22.04/24.04, Windows and macOS.

Not verified: the TUI telemetry page's Intel power rows on the AI PC (the CLI shows them; the page did not in this test).

v1.1.0

A whole-codebase review, then three measured rounds on the LunarLake AI PC (Arc 140V GPU + NPU). Everything below was reproduced before it was fixed, and every fix ships with a test that fails without it.

OVMS 2026.4.1 is the pinned build

Measured against 2026.2.1, with Qwen3.5-4B on GPU and Qwen3-8B-int4-cw on NPU, 15 questions that each need a tool, through all four engines:

• 56 of 60 answers right, against 42 of 60. 14 went from wrong to right and none the other way (McNemar p = 0.0001).
• The same output on every repeat, where 2026.2.1 varied even at temperature 0.
• GPU server peak memory 4.9 GB, against 17.3 GB. No log errors.

ovat setup and ovat doctor now read the installed version, so an existing 2026.2.1 install is reported with the upgrade command (ovat setup --force) instead of "already installed".

Fixed

• Framework engines fail honestly. LangChain, LlamaIndex and the Agents SDK now fail the run and the bench row when they hit their step cap, invent a tool name, or return raw tool-call markup. Before, they exited 0 and scored "ok".
• Intel UT telemetry works. It was dead: the flag combination OVAT passed was rejected, and continuous mode stops after one second without -t. Its output is now parsed into package, CPU, GPU and NPU power, NPU bandwidth and GPU frequency.
• Qwen2-VL "!!!!" on Apple Silicon. The ARM CPU computes in f16 by default; Qwen2-VL overflows. It runs in f32 there now, and x86 is unchanged.
• The vision tool returns a description. Unified models (Qwen3.5) are asked with thinking off. Before, the 200-token cap was spent on reasoning and no description came back.
• Local chat applies the model's own chat template, and a follow-up question ("and how is that measured?") is searched together with the question before it.
• Misspelt file paths recover a dropped leading folder, are announced in the result, and are quoted without doubled backslashes on Windows.
• Esc and Ctrl-C end the whole process tree on Windows.
• telemetry --out to a bad path exits 1. --once --out writes its snapshot.
• setup says when a download could not be checked against a published checksum.
• A failed run still writes its trace, and the bench table fits an 80-column terminal.

New, all off by default

top_p, top_k, min_p, presence_penalty, seed, enable_thinking, ovms_tool_guided_generation, ovat bench --repeat N and MCP tools[].env. The knobs were measured and none improved accuracy on 2026.4.1, so they stay off.

793 tests on macOS; CI green across Ubuntu 22.04/24.04, Windows and macOS.

Not verified: OVMS 2026.4.1 on Linux and with other model families; a human pass through the TUI on Windows.

v1.0.9

Ravi's asks 2 through 5: three settings lived outside workflow.yml and had to be exported before a run, so handing the file to a colleague, a CI runner or a container failed with nothing in the file to say what was missing.

Config, not environment

• A tool's model and device are config now (tools[].model, tools[].device), not OVAT_WHISPER_MODEL / OVAT_VLM_MODEL. Named model rather than whisper_model: the tool is transcribe, and any OpenVINO speech-to-text export serves it.
• Model discovery is config too (model_search_paths), not OVAT_MODELS.

Every variable still works as a fallback and config wins over it, so nothing that works today stops working. No user-facing doc mentions one.

Docs

• docs/workflow_yaml_reference.md — every field, generated from the pydantic schema, so types, defaults and constraints cannot drift. Tests fail if it goes stale or a field ships undocumented.
• The README opens with the project mark, and a test fails on any missing image in any markdown file.

Two things a rename alone would have missed

The tools cached their pipeline in one module slot, correct only while the model came from a single env var. Per-tool models made ovat bench — four engines in one process — liable to reuse whichever pipeline loaded first and report nothing wrong. Keyed by (model, device) now.

And the env vars were read at import into module constants, so setting one late did nothing.

Verified on an AI PC, every OVAT_* cleared

The audio-multimodal example transcribes with tool_calls: 1 from config alone; two different models load in one process; model_search_paths finds a model the environment does not know about, in both CLI and TUI.

Also answered on hardware: OpenVINO/bge-base-en-v1.5-int8-ov is a real pre-converted embedder, dim 768 measured, a drop-in with no code change.

706 tests, CI green across Ubuntu 22.04/24.04, Windows and macOS.

Not verified: the interactive TUI has no human pass at a real terminal, and the README's Windows-half commands have not been executed literally since 1.0.0.

v1.0.8

An external AI review proposed eight issues. Five were real and are fixed here; three were not, and each was rejected against the code or the vendor's own source rather than applied.

Fixed

• ovat serve on Windows downloaded 185 MB without asking. The consent prompt was indented under if note:, and that note is None on every platform except Linux -- so the primary supported platform never saw a prompt.
• A workflow that parses as a list gave a twelve-frame TypeError instead of a sentence.
• The TUI called a Pillow method that only exists from 12.1.0 while pillow carries no floor, crashing at launch on anything older.
• Five lines of prose sat inside a ```cmd fence, so the copy button pasted English at a shell. A test now checks every markdown file in the repo.
• A Whisper language code a model had already wrapped became <|<|en|>|>, which the tokenizer cannot match -- so it transcribed the wrong language rather than failing.

Rejected, with reasons

• A PDH handle leak in _WindowsNPUCounter that is unreachable: _query and _counter are only ever set and cleared together.
• A VLM [1, H, W, 3] batch dimension that OpenVINO GenAI's own three samples contradict. Applying it would have broken a working path.
• A pidfile PermissionError that CPython's refcounting prevents. Changed anyway for hygiene, but it was not the bug claimed.

685 tests, CI green across Ubuntu 22.04/24.04, Windows and macOS.

Not verified: the interactive TUI has headless tests and no human pass at a real terminal, and Linux GPU/NPU remains untested.

v1.0.7

Everything here came from running 1.0.6 on real hardware.

NPU serving could not answer a single agent question. OVMS caps an NPU prompt at 1024 tokens unless --max_prompt_len says otherwise, and one agent turn -- system prompt + every tool schema + history -- passes that immediately. The flag was documented in two comments and passed by nothing. model.ovms_max_prompt_len now exists and defaults to 4096 on NPU, and the Mediapipe error is translated into a sentence naming the setting.

ovat serve started a second OVMS on an occupied port. Windows permits two sockets on the same address and port; Linux answers EADDRINUSE, which is why it was never seen. The pidfile recorded only the newer pid, so --stop orphaned the older one holding the port and 4 GB. serve now asks the port what it is serving and refuses when the model differs.

ovat telemetry printed kv_cache_pct bare. On a dynamic cache ~100% is normal working state, and that number produced two wrong diagnoses across three sessions. DYNAMIC/STATIC is printed beside it now.

/chat never said it accepts a config, so a config pointing at the plano gateway's /v1 path was inescapable without reading the source.

674 tests, CI green across Ubuntu 22.04/24.04, Windows and macOS.

Not verified in this release: the interactive TUI has 47 headless tests and no human pass at a real terminal, and the README's Windows-half commands have not been executed literally since 1.0.0.

v1.0.5

1.0.5 -- the tool-call decode failure has a mechanism

Two sessions chased a parser that was working correctly. A tool call is decoded
from the text the model GENERATES, so when the KV cache is full there is no
room to finish generating: the <tool_call> block is cut off mid-way, and a
parser handed a fragment refuses it and passes the text through as content with
finish_reason 'stop'. That is exactly what the traces showed.

Measured on an AI PC: 4/4 agent runs failed on a server whose cache was
reported at 98-100% of 3.6 GB; 17/17 decoded on a freshly started server, same
machine, same model, same tool_parser: qwen3coder. An older note in the test
suite records the same shape from an earlier session, 4/4 failing and 12/13
fine after a restart, with the cause left unresolved.

model.ovms_cache_size_gb passes --cache_size to OVMS. Default None, so the
server keeps its own default and nothing changes
unless you set it. Raise it if you run many turns
or long answers in one session.

The error message now names both causes rather than only the parser, tells you
to check the parser once and stop looking there if it is right, and quotes the
measurement for the second. Naming only the obvious suspect is what cost two
sessions.

This is a hypothesis with strong evidence, not a proven fix: nobody has yet
made a full cache decode correctly after raising --cache_size. The landmine in
AGENTS.md still says do not close it on a clean-server pass.

600 passed. CI green across ubuntu-22.04/py3.10, ubuntu-24.04, windows and
macOS, plus base-install isolation and the built wheel.

v1.0.4

1.0.4 -- telemetry silences, and the mentor review closed

Telemetry had three states in the world and two in the code. A source that
could not start was reported; a source that started and produced nothing had
nowhere to say so, so the table simply had no Intel rows -- which reads as idle
hardware rather than unreadable hardware. Collector.notes reports those as
'live but silent' with the reason, which for Intel UT is that its continuous
mode writes binary traces instead of streaming values.

The remaining review points from the OpenVINO mentors are closed. The factual
ones shipped in 1.0.3 (the NPU claim replaced with a measurement, INT4 framed
as one low-bit precision among several, an uncited headline number removed, and
every figure in all three documents labelled measured or estimated). These are
the readability ones: architecture rules that say what they protect rather than
what they forbid, a section on how to add an LLM backend rather than
archaeology about an old annotation, and a blog that opens on the actual
argument -- agents should be configuration, not code -- with a
system-requirements table keyed on what the reader has rather than on what to
avoid.

599 passed. CI green on ubuntu-22.04/py3.10, ubuntu-24.04, windows and macOS,
plus base-install isolation and the built wheel.

v1.0.3

1.0.3 -- a failed run reports failure

Verified on an Intel AI PC against 3b7fda9, and every finding was the same
species: the code did what it was written to do, and what it TOLD you was
wrong.

• ovat run printed "Error: ..." and exited 0. The loop delivers its
  failures as the answer text on purpose, because the model has to read them
  and correct itself -- but the CLI then reported success, so four
  consecutive failed RAG runs were indistinguishable from good ones to any
  script, CI job or benchmark. The trace now carries a failed flag and run
  exits 1 on it, after the answer, sources, telemetry and trace are written.
• "NPU cannot do tool calling" had been cleared from every document and
  still sat in device_manager.py, findable by grep in ten seconds. Replaced
  with the measurement: OVMS does not start on NPU for Qwen3.5-4B or
  Qwen3.5-0.8B, both failing identically at model compilation with
  [NPU_VCL] Compilation failed (0x78000004) -- before a single token is
  generated, so it never reaches the dynamic-shape limit either.
• ovat index appended instead of replacing. The dedupe existed; its key was
  an unnormalised path, and docs\notes.md and .\docs\notes.md are the same
  file and different strings. One index held three copies of one document.
• A byte order mark survived into the chunk, the vector and the citation.
• The README quoted 4.3 GB steady / 6.5 GB peak while a long generation
  measured ovms.exe at 10.6 GB with the KV cache growing 3.6 -> 5.8 GB. Both
  numbers are real; only one was labelled, and now both are.
• Two test defects of my own: a setup test that could only pass on a machine
  without OVMS, and an isolation guard patching urlopen after the health
  probe moved to build_opener().open() -- so it reached real localhost:8000,
  failed on timing with a live server and hung the file without one.

598 passed. CI green on ubuntu-22.04/py3.10, ubuntu-24.04, windows and macOS,
plus the base-install isolation and built-wheel jobs.

v1.0.2

Windows CI Hardened, Plano/WSL Port Binding, and AI PC Validation