October 5–11, 2026

0.79.0 — 2026-10-11

The console is part of the inbox now. Its pages moved to inbox.vatio.ai, one app with sections by role: Start, Test, Channels, Tools, Outreach, Team, Security and Account. The links the CLI prints (Try it: after vatio push, vatio env, vatio tools, vatio whatsapp, vatio instagram) open there, and vatio login lands there after you sign in at vatio.ai. Older CLIs keep working: the platform sends the new links and old console URLs redirect. JSON field names, console_url included, did not change.

The CLI names the inbox’s sections. vatio whatsapp and vatio instagram point to the Test page before you publish and to Channels after. vatio init --name before signing in says to set the name with vatio business set --name or on the Business page.

Skills 1.11.0. vatio-init hands over the inbox’s Test page, and a teammate who is not in the workspace yet is invited from Team in the inbox.

0.78.0 — 2026-10-11

A routine is a tool the agent decides to use. Give the agent a routine with tools/NAME.yml and routine: NAME, and add it to agent.tools. The agent calls it once the request is complete, asking first when it is not, and tells the person whether Claude has it in the same turn. A message from a routine’s number no longer starts the routine by itself, and --quiet is gone with it. The tool exists only in WhatsApp conversations with the routine’s numbers, so nobody else can talk the agent into it, and evals never start a real session. vatio routines create prints the tool file to add. See Routine tools.

0.77.0 — 2026-10-11

The agent can answer only some numbers on your WhatsApp number. vatio whatsapp only +56912345678, or The agent answers next to the Live switch in the console, makes the agent answer only those numbers; everyone else’s messages still reach the inbox, for you to answer. The numbers of your routines always count. vatio whatsapp everyone goes back to answering everyone, the default, and vatio whatsapp shows which it is. Set the list before switching Live on, and the agent never answers anyone else. See Who the agent answers (removed in 0.107.0).

A routine’s token is checked when you save it. Anything that is not a sk-ant-oat01-… token is refused right away, instead of failing with a 401 on the first message. Pasting the wrong thing from the clipboard is the usual cause.

0.76.0 — 2026-10-11

A WhatsApp message can start a Claude Code routine. vatio routines create connects a routine’s API trigger to the numbers that start it: when one of them writes to your number, Vatio waits for them to finish and starts the routine with where the conversation is, never what it says. The agent waits while they write and answers once, saying whether Claude has it or the routine could not be started. vatio routines runs shows each run with the link to its Claude session. Only WhatsApp starts one, because only there does Meta vouch for the number. See Claude Code routines.

A server key reads a conversation: GET /api/server/v1/:slug/chats/:id/messages, newest last, with what was forwarded, voice notes as text and signed URLs for files. It is how a routine catches up, and every read is in the workspace’s Activity.

0.75.0 — 2026-10-10

vatio share-session leaves out the people a session is about. Email addresses and phone numbers written with a country code become [EMAIL] and [PHONE], next to the keys and tokens that were already [REDACTED], and the summary says how many. The customers that come up in a database query are the team’s least useful part of a session, and what made Claude Code’s auto mode refuse to send one. Names, and numbers without a +, still go: --save shows exactly what would.

A shared session is deleted 30 days after it arrives. vatio share-session says so before it asks, and prints the date once it is sent; the row saying who sent one, when, and the feedback with it stays. Only the Vatio team reads a session, and every read is logged. The privacy policy lists it.

vatio share-session --list marks the sessions already sent, with their number and when. When a permission check stops the coding agent and you send the session from your own terminal, the agent checks there that it went.

Outside a workspace, the error says where one is. A command run one directory above a vatio.yml (vatio chat show, push, kb …) now names the nearby workspace and the cd to it, instead of asking for an API url.

Skills 1.9.0. When a permission check refuses to send the session, vatio-share-session gives you the command to run yourself instead of retrying, and checks with --list that it arrived. Before asking, it tells you how the session is treated: who reads it, that reads are logged, and when it is deleted.

0.73.0 — 2026-10-10

vatio flags and vatio eval say when the Vatio skills are out of date. They compare the Claude Code plugin’s version, or the copy npx @vatio-ai/skills made in the project, with the latest published skills (asked of npm at most once a day) and say how to update: claude plugin update vatio@vatio, or running npx @vatio-ai/skills again. Claude Code does not auto-update plugins from other people’s marketplaces unless you turn it on; see Keeping them up to date.

Skills 1.7.0. vatio-share-session offers to send the session with Claude Code’s own question (send it, send it with a comment, not now, don’t ask again) instead of a message, and npx @vatio-ai/skills leaves the version it installed next to each copy.

0.72.0 — 2026-10-10

vatio flags and vatio eval say when the Vatio skills are missing. Without the Claude Code plugin or the skills npx @vatio-ai/skills copies into a project, Claude Code has no /vatio:vatio-improve, so both commands end with one line on stderr saying how to install them. At most once a day per directory, never in CI; VATIO_NO_SKILLS_HINT=1 turns it off. See Improve.

The inbox’s Continuous improvement page is simpler. One box says what is next (reports open, with the command for the developer; fixes waiting to be published; a fix that broke something; or all resolved), reports are Pending, Resolved or All with one latest result each, and a report can be removed from its row.

0.71.0 — 2026-10-10

One loop: your coding agent fixes, Vatio verifies. A supervisor reports a reply in the inbox and writes what it should have said. One session of your coding agent takes every open report: vatio flags, fix, vatio push (updates preview, runs no tests), vatio eval (tests every report on preview), then vatio publish. In Claude Code, /vatio:vatio-improve (skills 1.6.0) runs it, with vatio eval in the background. See Improve your agent from flags.

vatio publish checks preview first. Once the agent is published, publish is refused until vatio eval has tested preview’s current version (evals_missing), while its tests are still running (evals_running), and when a report that passes on live fails on preview (evals_regressed, listed by id and title). Reports that still fail on both do not block, so a partial fix can ship. When it goes through, the reports preview passed are resolved with the version that fixed them, without testing again. vatio publish --force publishes over a regression anyway, failing results included. The console’s Publish button goes through the same check and publishes directly. See The publish gate.

vatio push does not overwrite an unpublished push from another branch. Once the agent is published, a push is refused when preview holds a version that is not live, pushed from another git branch (preview_has_unpublished_push). Publish it first, or vatio push --force to replace it.

Only preview and live. There is no environment per git branch and there are no named environments: --env takes preview or live (staging and sandbox still mean preview), and any other name is an error. Commands no longer pick an environment from the git branch, and vatio env rm is gone.

Proposals are gone. vatio propose, the inbox’s proposals and an owner accepting a change were removed; vatio propose now says so, and the proposals endpoints answer 410 proposals_removed. Test with vatio eval and publish with vatio publish.

The GitHub App integration is gone: pull request previews, publishing by merging, comments and checks on pull requests, the vatio-flags issue and connecting a repository. Signing in with GitHub stays.

“Ask for an improvement” and the Learning view are gone. A report’s state now shows on the reported reply in the conversation: open, fixed in preview, or resolved with the version that fixed it. The inbox’s Continuous improvement page lists every report with its latest tests and what vatio publish would say, with the prompt /vatio:vatio-improve; the daily email to the workspace’s developers links there.

Every report with a note is a test, wherever it was made, live or preview. A report made on preview after the first publish used to be a note with no test.

Evals run five cases at a time. A run of 27 cases takes 3 to 4 minutes instead of about 15.

0.70.0 — 2026-10-10

vatio logout revokes the token. It used to delete the token from this machine and nothing else, so a copy of the config file kept working. Now the token is revoked on Vatio first; offline, the local copy is still removed.

CLI tokens expire after 90 days without use. Each command slides the expiry forward, so a machine in regular use never notices. One left alone needs vatio login again. Every token alive today starts with the full 90 days.

Two-step verification. Passkeys, an authenticator app and recovery codes, in Settings → Security, which also lists every console browser, inbox device and CLI token signed in to your account and closes any of them. A workspace marked as holding sensitive data requires it from its whole team; for those workspaces the API answers two_factor_required until the account has it. See Two-step verification and sessions.

0.69.0 — 2026-10-09

base_url keeps its path. A tool’s path is appended to the base URL’s own path: https://<ref>.supabase.co/functions/v1 plus /my-tools/check_stock calls .../functions/v1/my-tools/check_stock. Until now the base URL’s path was dropped without a word and the call went to /my-tools/check_stock on the host. A path that already repeats the base URL’s path, the way around it, is not prefixed twice. See Declarative HTTP tools.

A reply makes at most 12 tool calls. After the twelfth, or after the same tool fails three times with the same message, the agent is told to answer with what it has and say what it could not do; a call after that is refused, so a tool that keeps failing no longer leaves the person without an answer. vatio chat show marks it with a [tool limit] line. See Tool results.

A failing tool’s own words reach the agent. On a non-2xx, a body with no message but a string error ({ "error": "...", "hint": "..." }) uses it as the message, instead of a bare “HTTP 422”.

A typed phone number is not asked for. Off WhatsApp, a tool that requires contact.phone_number used to tell the agent to ask for it, but a number typed in the chat never fills $contact.phone_number: only WhatsApp or the visitor’s sign-in do. The agent is now told not to ask and to say it cannot be done from that chat. See Required values.

vatio secrets list shows every environment. Each secret on its own line with its scope (every environment, only preview, tests), so a value set from a branch or with --env is never missing from the list; --env NAME still shows only what that environment reads. set and rm say which scope they touched. A key starting with VATIO_ is refused with a message that says so, instead of “Translation missing”.

0.68.0 — 2026-10-09

Start by installing the skills. The prompt on vatio.ai now has the coding agent run npx @vatio-ai/skills in the project first and follow the vatio-init skill it installs, and installing them is step one of Starting a new agent and of the quickstart. The skills stay in the repository, so the next session — or a different coding agent — finds how to start and improve the agent without being told again.

vatio-new is now vatio-init, and it looks first. Before creating anything it searches the whole repository for a vatio.yml, reads the app (its API, how its users sign in, its docs) and says what it found and what it recommends. With no agent it builds one, asking the owner only what the code does not answer. With one, it follows Joining an existing workspace: it never runs vatio init there, compares the folder with live, explains the agent and points at open flags and failing tools. npx @vatio-ai/skills removes the old vatio-new copy when it installs vatio-init.

vatio share-session: send the Vatio team your Claude Code session. When a sentence in vatio feedback is not enough, vatio share-session sends the session the coding agent is in (or the most recent one for this directory): what you asked, what it ran and what it was shown. Feedback in your words is optional: vatio share-session "what got in the way". Images and Claude Code’s own bookkeeping are left out, anything that looks like a key, token, password or private key becomes [REDACTED], and it shows which session goes and asks before sending; a coding agent sends only with --yes, after asking you. --save FILE writes exactly what would be sent instead, --list and --id pick another session. It needs you signed in, and only the Vatio team reads it. See Share a session.

A third skill, vatio-share-session. Say “send this session to Vatio” or run /vatio-share-session: Claude Code shows you what would go, asks, suggests adding feedback in your words, and runs vatio share-session. npx @vatio-ai/skills (1.5.0) installs it with the other two. When vatio-init or vatio-improve finish, Claude Code offers to send the session, with three answers: send it, not now, or don’t ask again. vatio share-session --should-ask decides whether to offer — at most once a week, never twice in a session — and vatio share-session --never stops it. See Claude Code.

0.67.0 — 2026-10-09

Tool metrics for your coding agent. vatio tools prints the console’s Tools page as a document a coding agent works from: each tool’s calls, error rate, timeouts and p50/p95 latency, then the calls that failed with what your backend answered and the vatio chat show that opens the conversation. --json gives the same as data. It reads the branch’s environment on a branch and live elsewhere (--env), over the last 7 days (--period). A failing tool seldom gets flagged, because the agent apologizes and moves on: this is where your agent finds it. See Tool metrics.

The last hour. The Tools page and vatio tools read the last hour as well as the last day, 7 and 30 days: enough to see whether a fix you just published stopped the errors.

Each tool call in vatio flags says how it went: the HTTP status, outcome and duration of the call to your backend, next to its arguments and response. The vatio-improve skill (1.4.0) and the AGENTS.md section vatio init writes point at vatio tools too.

0.66.0 — 2026-10-09

Publish through your tests. The console’s Publish buttons (the Test page and Environments) no longer publish at once: they propose the environment and take you to it in the inbox, where every eval case is replayed on it and the owner or a developer publishes it. preview can be proposed now, and deciding never removes it. Accepting an improvement publishes the version that was tested and takes its results live with it, instead of replaying every case on live again. vatio publish and a merge to the default branch still publish directly. See Eval runs.

A failing case is retried. The same case can fail once and pass the next time on the same version, so a case the judge fails is replayed again in a fresh chat, up to 3 attempts; only one failing all three counts as failing. One that passed on a later attempt says how many it took, in the report (F-7K2QX (2 attempts)), on the improvement and in Learning: it is unstable.

Test values for secrets. vatio secrets set KEY VALUE --tests sets the value every environment but live uses, and every eval replay, live’s included: one staging URL for everything that is not a visitor on live. list marks it (tests). A replay’s tool calls carry an X-Vatio-Test: 1 header, and a write (any method but GET) whose URL has no test value is not sent: the agent gets a success, and the judge still checks the call and its arguments. See Secrets.

Tests come from live. A report made on live is a test, and so is one made before the agent’s first publish. After that, a report from a preview or a branch is a note for whoever fixes the agent: it is in vatio flags, with Eval case: no, but nothing replays it.

Learning, simpler. The inbox lists each report as solved or not, under one card with what to do next. Asking for an improvement, and accepting one, happen on live only. Nobody overrules the judge any more: a supervisor who disagrees rewrites the note, which starts the case over.

0.65.0 — 2026-10-08

The docs live at vatio.ai/docs. Same pages, same Markdown contract, now under the main domain:

• /docs/docs.md is the whole contract, and every page is also at its path plus .md, indexed in /docs/llms.txt.
• Every docs.vatio.ai address answers with a 301 to the same path under vatio.ai/docs, so existing links keep working.
• vatio docs fetches the same file as before, and any version of the CLI follows the redirect. This release only updates the URLs the CLI prints.

The widget is on npm, and open source. npm install @vatio-ai/widget mounts the same widget from your app’s code with mountVatioWidget(), returning identify and unmount — see From your app’s code. Its source is public under MIT at github.com/vatio-ai/widget. The script tag at cdn.vatio.ai/v1/widget.js is unchanged.

The skills are on npm. npx @vatio-ai/skills copies vatio-new and vatio-improve into a project’s .agents/skills/ and .claude/skills/, so Codex, Cursor, Gemini CLI, GitHub Copilot and Claude Code pick them up without the plugin. See Claude Code.

The browser SDK is back on the CDN as a classic script, cdn.vatio.ai/v1/sdk.js, which leaves the SDK on window.Vatio for a page without a bundler (Without a bundler). The old vatio.ai/vatio-widget.js and vatio.ai/sdk/1.js redirect to the CDN again.

0.64.0 — 2026-10-07

vatio propose: a fix the owner accepts from the inbox, without GitHub. On a workspace with no repository connected, push the fix to the branch’s environment and run vatio propose --title "What it fixes" (plus --summary or --summary-file for why). Vatio replays every eval case there and mails the workspace’s owner when the replays finish. In the inbox, under Learning → Improvements, the owner sees why, every case on live next to this version, what changes line by line against live, and a link to try it, then accepts (which publishes the environment, prompt, tools and knowledge together) or discards it. Accepting is refused while the replays run, when the environment was pushed again after proposing, and when a case that passes on live fails there. Either way the environment is removed and the proposal keeps its record. Proposing the same environment again updates it and replays the evals; vatio propose --list shows where each one stands. preview and main cannot be proposed: they are shared. See Without GitHub: propose it to the owner.

Ask for an improvement, from the inbox. On Learning, the owner and developers can have Vatio review the open flags. It reads each conversation, what every tool answered and how the agent is set up, and sorts the flags by cause. A fix in the agent’s instructions or knowledge it writes itself and opens as a proposal, tests running. A missing tool or one that fails (an error, a 500) it never works around in the prompt: Vatio has no access to your backend’s code, so it gives you a prompt for your coding agent instead. One review at a time, up to ten a day. See Ask for an improvement.

0.63.0 — 2026-10-07

Create WhatsApp templates from the CLI, and test them before you have a number. vatio templates create submits a template for Meta’s review on Vatio’s test number, so your coding agent no longer stops at the console to write one:

vatio templates create order_shipped --language es \
  --body "Hola {{1}}, tu pedido {{2}} va en camino." --example Ana --example "#1042"

Once Meta approves it, a preview key sends it to your test phones when the 24-hour window is closed — before, a preview key could not send a template at all. When you connect your own number, Vatio moves your templates to it under the same names, so the template your backend sends does not change when it goes live, and removes them from its test number. From then on your backend sends from your number with a live key: a preview key is refused with 409 use_live_key, and templates create submits straight to your number.

The template is checked before Meta sees it — the name’s format, {{1}}, {{2}}, … in order, one --example per placeholder, and no placeholder at the very start or end of the body. utility is the default category; pass --category marketing for promotions. vatio templates list --env preview shows the ones on Vatio’s test number, and vatio templates list tells a workspace with no number of its own where its templates are.

0.62.1 — 2026-10-05

vatio whatsapp and vatio instagram link to a page you can see. Before your first publish the console shows only the Test page, so they now print its WhatsApp or Instagram tab, where you verify a test phone or account and talk to your agent. After you publish they print that channel’s page under Integrations, where you connect your own number or account. vatio status reports published, plus whatsapp_url and instagram_url next to integrations_url, which also points at the Test page until you publish.