Release notes
Notable changes to Tares, newest first. The project follows Semantic
Versioning ; earlier 0.0.x history is in the git log.
Entries below 1.0.0 name the commands and variables as they were at that release, when the project was called NavFlow. They are history, not current usage. See Upgrading from 0.x for the full mapping.
1.46.0: 2026-10-14
Work on a software factory project in your own Claude Code session, and take it over from the crew when the crew holds it.
Added
tares factory sessionstarts your own Claude Code session on a project, with the Tares plugin loaded.tares factory session <project>works on a planned project and picks up a ticket left in progress. When the crew holds the project, it asks whether to take it over; on yes the orchestrator stops its builders, they push what they have and write their progress, and the project is yours.tares factory session "<idea>"plans a small project lightly (goal, short spec, tickets, checks) and builds it in the same session, offering the full spec and the hand-over to the crew when it turns out big. With no argument it asks which project.- Take over and release through the API:
POST /api/projects/{id}/takeover(the person only) andPOST /api/projects/{id}/release(the orchestrator, or the person’s session),releasingin/api/crew/projects, therelease_projectMCP tool, andfinish_project(words=...)for a person’s own session, which also finishes a project the crew never held. - Skills for coding harnesses:
npx skills add glassflow/taresadds a software-factory skill and an ai-sre skill, so Claude Code and others suggest Tares for building a software factory or an AI SRE.
Changed
- Plugin, marketplace and PyPI descriptions name both uses: a software factory for Claude Code and an AI SRE. Claude Code plugin 0.5.1.
- Tares on Homebrew follows every release: the tap is pointed at the new PyPI version and the
install is checked.
brew installis shown as the alternative to uv.
1.45.0: 2026-10-14
Sign in to a Tares Cloud workspace with tares login. The software factory, tares status and the
Claude Code plugin then use it, with no environment variables to set.
Added
tares loginopens the Tares Cloud console in your browser. You sign in, pick a workspace on Tares 1.44.0 or later, and this machine gets its own admin key on it, handed back to the CLI over127.0.0.1with a one-time code. The workspace and the key are saved in~/.tares/login.json, readable only by you. Logging in again replaces the key.--cloudpoints at another console.tares logoutremoves this machine’s key from the workspace and deletes the saved login.- One order everywhere. A flag, then
TARESD_URLandTARES_AUTH_TOKEN, then the saved login, then the local Tares.tares statussays which workspace it is signed in to, andtares factory doctorsays where it found its Tares. - Claude Code plugin 0.5.0. Outside the factory, sessions stream to the saved workspace with its
key while the plugin’s Tares URL and Access token are left as they came, and the MCP
connection presents the key to that workspace’s own
/mcp.tares loginprints the MCP endpoint to set. See Claude Code sessions.
Changed
- The plugin’s session shipper no longer follows redirects, so a token is never sent on to another host.
1.44.0: 2026-10-13
The software factory: a crew of Claude Code sessions on your machine builds every project you hand it, from tickets to pull requests merged on main, and Tares keeps the plan, the tickets, the reviews and your decisions. 1.43.0 stays with the decision-model watcher (released as 1.43.0-rc.1 to rc.3); this release does not contain it.
Added
- Software factory.
tares factory crew upstarts one crew for every project: an orchestrator and a reviewer, and a releaser only when you ask for one. The first run asks how far the crew may go and keeps the answers on Tares, offers to trust the crew’s own folder, and starts a watch that revives stopped stations. The orchestrator starts builders per milestone and repo.tares factory doctorchecks what the crew needs. /tares:specturns an idea into a Tares project. It interviews you one question at a time, has a second model challenge the plan, and writes the spec, the plan, milestones with acceptance checks, tickets with their dependencies and repos, a working doc per ticket and an AGENTS.md. Tickets can live in Linear instead.tares factory specopens it in the repo the project builds on.- The ledger. Tickets carry a holder and a stage; the orchestrator assigns them and each holder moves its own. Pull requests are read from GitHub, a project can span several repos, and a cross-repo dependency holds a builder back.
- The build, recorded: assumptions, checks matched against what the session actually ran, project memory, review rounds with findings and verdicts tied to the commit, a review queue, and recurring findings offered as rules. The Codex challenger can review each builder’s commits.
- The desk. One list of questions for you across every project, answered in the
orchestrator’s session and kept as you typed them. A standing answer becomes a grant. When a
project’s work is done the orchestrator asks, and your yes marks it finished
(
tares factory finishdoes it from the terminal). - Console: a Crew page (members, projects, a member’s details, notices), and on a factory project page the build’s steps, tickets by milestone, each repo’s pull requests, assumptions, decisions and the sessions that worked on it. See A project, end to end.
- The project page’s results have a Show filter: everything, only findings, or one agent’s
conclusions.
GET /api/projects/{id}/resultstakesshow(findingsoragent:<name>). - An agent’s budget can be set on the agent form under Advanced. Blank means no budget.
Changed
- The Claude Code plugin (0.4.0) connects to Tares’s MCP endpoint over HTTP instead of starting
tares-mcpin every session. Locally, runtares mcp --transport streamable-httpnext totares up; the new plugin optionmcp_urldefaults tohttp://127.0.0.1:8788/mcp. On Tares Cloud, setmcp_urltohttps://<cell>.tares-glassflow.com/mcp; nothing needs installing. Each session’s station, role and project travel asX-Tares-*headers, so many sessions share one server.tares factoryrefuses to start sessions when the endpoint does not answer.tares-mcpover stdio still works for other MCP clients. See Claude Code.
Fixed
write_milestonekeeps the goal or checks an update leaves out.- A session that exits shows as ended, and one silent past its window shows as quiet instead of waiting forever.
- A build session started from Tares’s own prompt joins its project, and the project page names an in-progress ticket only for the session working on it.
- The desk waits a few seconds for a reply Tares has not read yet before refusing it.
- The session picker in Summarize a session now shows each session’s repo, branch and state in full instead of cutting them off.
1.42.0: 2026-10-06
A new instance opens on Start instead of Overview, and Slack works with every public channel.
Added
- Start (
/start): a short list of what is ready (the demo, a model provider, GitHub and Slack, each optional and ticked from the instance’s state), then the goal step for your first project. On Tares Cloud it shows the included model credit and what is left. Projects shows the same list until it is done or hidden. - The goal step asks for an optional name and description.
POST /api/setup/draftsandPOST /api/projects/{id}/setup/plantakenameanddescription. - The plan screen offers Ask Tares to fix it when the plan still has a mistake after Tares’s own fix rounds.
- One searchable Slack channel picker wherever Tares asks for a channel: the guided setup, the
agent form, a project’s subscribers and template forms. Private channels show a lock, with how to
add Tares to one (
/invite @Tares). POST /api/slack/channels/changed(admin) drops the cached channel list so the next read asks Slack again.- On Tares Cloud, one Slack workspace can serve several Tares workspaces:
/tares ask <workspace> <question>picks which one. - Settings > Usage (self-hosted) holds model spend and storage; on Tares Cloud they join Settings > Workspace.
Changed
GET /api/slack/channelslists every public channel of the connected Slack, not only the ones Tares was added to, plus the private channels Tares is in, each withis_member. When a re-read fails, the last good list is served withstale: true.- No screen asks for a Slack channel ID any more. A channel already saved as an ID or a name keeps working and shows by name.
- Settings > Slack lists the bot scopes a pasted token needs:
chat:write,chat:write.public,channels:read,groups:readandcommands. - The planner gets up to three rounds to fix what the check finds, and never asks about what only you can answer, such as which Slack channel.
/opens Start until you have a project of your own, and Projects after that.- The Default project is made the first time something is created outside a project, not when the instance starts. Projects no longer lists it.
Removed
- Overview and the landing screen. The goal step is now the one place to say what you want to build.
1.41.0: 2026-10-02
Switch workspaces from the console, and connect GitHub and Slack from the workspace’s own settings on Tares Cloud. A self-hosted instance looks and behaves as before.
Added
- Workspace switcher (Tares Cloud,
TARES_WORKSPACES_URL): the top left of the console shows the workspace’s name and opens a menu of your workspaces, workspace settings and New workspace. - Connect Slack (Tares Cloud,
TARES_SLACK_CONNECT_URL): Settings > Slack connects and disconnects in one click and shows which Slack workspace it is connected to. - GitHub App on Tares Cloud: an
app_brokercredential carries the repositories this workspace follows; Settings > GitHub lists them, with Pick repositories or Change repositories. - Settings > Workspace (Tares Cloud,
TARES_WORKSPACE_API_URL): the plan, Tares version and state; the team, where the owner invites and removes members; storage and its limit; the included credit; and, for the owner, Delete workspace. Members see it read-only. /healthreportsslack_connect_url,workspaces_url,workspace_api_urlandlogout_urlwhen set.
Changed
- Members who are not the workspace owner see who can connect GitHub and Slack instead of buttons that would be refused.
- On Tares Cloud (
TARES_LOGOUT_URL), Sign out also signs you out of Tares Cloud, and the sidebar shows the email you are signed in with.
Fixed
- Disconnecting the Tares Cloud GitHub App now goes through Tares Cloud, so its events stop arriving.
1.40.0: 2026-10-02
Changed
- Agent traces carry
user.idon every span,rius.main_agent.namebesidegen_ai.agent.name, andservice.versionon the resource.
1.39.0: 2026-10-02
The GitHub connector: a personal token or the GitHub App, and agents that act on your repositories.
Added
- GitHub App: Settings > GitHub > Create GitHub App, then install it on an organization.
Every event of every repository it is installed on arrives as it happens, in one
githubsource: pull requests, pushes, reviews, comments, issues, releases and CI runs. On Tares Cloud, Connect GitHub does the same and the instance holds no key. - Personal token sources report pull requests opened, merged or closed next to commits (
prs). Both ways produce the same event types, keys (owner/repo#number) and labels. - Webhook signatures: GitHub, Linear and HMAC-SHA256, checked on the raw body. A source that
checks signatures needs no Tares key on its ingest URL; the generic webhook connector opts in with
signature_scheme. - Agents on GitHub: a credential per agent, with read or read-and-write access through GitHub’s
MCP server. With the App,
github_create_check_runposts the verdict as a check run with line notes. - The guided setup can start from a goal about your GitHub repositories.
- Trigger filters take
in(a list, case-insensitive).
Changed
- The
githubconnector is labelled “GitHub”. Upgrading addsevent_type = committo every trigger on a token source that had no event filter, so it keeps meaning what it meant. - Shared code context uses the App’s source when there is one, and offers “every merged pull request”.
1.38.0: 2026-10-02
Projects are the unit, parts are shared between them, a guided setup starts a project from a goal, and an agent’s run ends the way you set. Released after release candidates 1.38.0-rc.1 to rc.8.
Added
- Projects are the unit. Every instance has a Default project that holds whatever was made outside another one. A project has a goal, a one-sentence outline of how it works, a health line, today’s totals and What the agents found: one result per chain of runs, with a headline and a next step, that you can mark as handled. Advanced setup’s Activity shows one thread per firing, with the runs it woke and what they led to. See Projects.
- Parts are shared. Sources, triggers, agents, MCP servers and skills belong to the instance,
and any number of projects can use the same one. A project holds its own wiring: which trigger
wakes which agent, on or off, and which agent takes over on whose verdict. A run belongs to the
project whose wiring started it. Pausing a project turns only its wiring off, and deleting one
keeps every part another project uses. All resources lists every part with the projects
that use it (
GET /api/resources), and the catalog export carries each project’s wiring. - Guided setup. Projects → Create new starts from a goal: Tares writes a plan in plain words (what it watches, when it wakes, who does the work, tools and know-how), you change any part in place, then connect what only you can and Run it once now to see a result. The plan is kept as a draft you can finish later from Projects, or delete. It reuses sources, agents, tools and skills already on the instance, and posts findings to a Slack channel you pick. See Guided setup.
- Skills: named instructions (a runbook, a house style) that agents load when a task matches. A skill is shared: editing it changes it everywhere, and removing it from a project deletes it only when no other project uses it.
- Handoffs. An agent names, per verdict, the agent that takes over on the same entity, with a cooldown. A chain stops after three handoffs. An agent can have no trigger of its own, so only a handoff starts it. See Tares agents.
- How an agent ends. “Ends every run with a conclusion” gives an agent the
concludetool whatever its prompt says. Its verdicts are a list you set, each with when to give it; a finding must carry one of them, and the handoff form offers them as a dropdown. The runs table shows each run’s verdict and headline in an outcome column. - Outside agents in a project. A project key reads one project and records findings in it.
An agent outside Tares can join a project’s firings, record findings with a headline and next
step, and use new MCP tools such as
join_project,record_findingandproject_timeline. See Connect an outside agent to a project. - A trigger can say what wakes it in plain words (
description), and the project sentence uses it.
Changed
- Views are gone. A trigger names its own
sources,filtersandkey_field. The first start after upgrading moves each view into the triggers that used it, and places every object in a project./api/views,POST /queryandPOST /deriveanswer 404. - Deleting a trigger, agent, MCP server or source removes it from every project. The agents a deleted trigger woke stay, without a trigger.
- Every write needs the admin scope, apart from reads, ingest, recording a finding and subscribing. A read key can no longer create projects or add MCP servers.
- An agent’s trigger can be changed after the agent is made, and the console names sources by what they watch (a repo, a host), with the name underneath.
Fixed
- Upgrading from 1.37.0 and then stopping the instance hard no longer leaves the database unusable.
1.37.0: 2026-09-29
Added
- The
rius_rcatemplate takes adaily_cap, so each workspace’s root-cause agent can be sized by plan.
Changed
- A finding in Slack is posted whole when it fits in one message; only a longer note gets an excerpt in the channel and the full note in the thread.
Fixed
- Clicking a button on a Tares message in Slack no longer shows “This app is not configured to handle interactive responses”.
1.36.0: 2026-09-29
Changed
- Slack messages from Tares read like an alert: the entity as a header, the agent, trigger,
verdict and model as fields, a short excerpt, and View in Tares and Open timeline buttons
(when
TARES_PUBLIC_URLis set). The full note goes in the thread. - Wide markdown tables in Slack become one line per row, and long notes no longer split inside a code block.
1.35.0: 2026-09-28
Added
- Watch, then escalate. A
triagepreset runs on a schedule and flags the entity that looks off; a root-cause preset digs in on what it flagged. See Watch, then escalate. - Schedule triggers fire every N minutes and hand the agent a summary of the window.
- Tares agents get a
statstool (counts per label value, this window against the one before) and can end a run withconclude:no_opwhen there is nothing to report, or a finding with a verdict about a named entity. - Runs record what they produced (a pull request, a commit, a Slack message, a write-back), read off their own tool calls.
- Runs per agent per day is a setting under Settings → Agents.
1.34.0: 2026-09-28
Added
- A push delivery with
X-Tares-Bypass-Cooldown: truewakes the triggers over that source now, even inside their cooldown.
Changed
- Agent traces follow the OpenTelemetry GenAI conventions more closely: one run is one session, and spans carry the agent’s name, tool definitions and tool call details.
1.33.0: 2026-09-15
Fixed
- A model provider set in the environment lists its models at start, instead of waiting for a refresh under Settings.
1.32.0: 2026-09-15
Added
- A deployment can hand an instance a model provider (
TARES_PLATFORM_PROVIDER_URL,_KEY,_NAME): an OpenAI-compatible entry that is the default until you pick another. Tares Cloud uses it for trial instances.
1.31.0: 2026-09-14
Added
GET /metrics: the daemon’s own counters in the Prometheus text format (ingest, polls, agent runs, model spend, database size, trigger passes). Counts only, never an entity or payload.
1.30.0: 2026-09-14
Added
- Model providers. An instance holds a list of providers under
Settings → Model providers: Anthropic, OpenAI, or any OpenAI-compatible endpoint (LiteLLM,
OpenRouter, Ollama, vLLM). Each agent picks a provider and a model; Ask and the builder run on
the default. Saving a provider reads the models it serves, with a refresh, and an agent can name
a model by hand when it lists none.
OPENAI_API_KEYandOPENAI_BASE_URLseed an OpenAI entry;TARES_MODEL_PROVIDERnames the default. The Anthropic key and gateway settings are unchanged under the new tab, and an agent that names a provider the instance lacks runs on the default. - The spend meter prices OpenAI models, takes a router’s own cost figure when it reports one, splits spend by provider, and records tokens without a dollar figure for a model it cannot price. Traces name the provider on every model span.
- Small-model hardening: a tool call written as JSON text is run, a mis-cased tool name still matches, and a run with no conclusion and no tool call says to check tool calling.
Changed
- Console, CLI and README say “model provider” where they said “Anthropic key”. The Settings tab Model access is now Model providers.
1.29.1: 2026-09-10
Fixed
- The RCA write-back reported the wrong delivery id when more alerts for the same service arrived
while the agent was running. The
keyis resolved when the run starts, and the body carries the firing’s labels aslabelsso a receiver can check the attribution.
1.29.0: 2026-09-08
Added
- Storage is measured against the volume the database sits on when no
TARES_MAX_DB_SIZEis set; at 95% of the limit ingest is refused with 507 and poll connectors wait, with the reason on the source’s health and the Overview. A run records whether its finding reached the write-back webhook. Agents can report a label’s value as the write-back’skey(webhook_key_label).
1.28.0: 2026-09-08
Added
- Model access through an LLM gateway. Tares agents
and Ask can talk to any server that speaks the Anthropic Messages format: LiteLLM, Portkey, a
proxy in front of Bedrock or Vertex. From the environment with
ANTHROPIC_BASE_URLandANTHROPIC_AUTH_TOKEN, the names Claude Code uses, or from Settings → Model access, stored on the instance and winning over the environment, so a hosted cell with a mandated proxy is configured by its owner. The gateway token is sent as a bearer header and never returned. The Settings tab is now called Model access and leads with where model calls go. Thanks to KurochkaR for the environment half.
1.27.0: 2026-09-08
Added
- HTTP API (poll), the
http_pollconnector. Polls any JSON endpoint on a schedule and stores one event per item, for the APIs no other connector covers: a weather service, a status page, a SaaS export, your own API. GET or POST with a body, extra headers, one credential header stored as a secret, a payload key into the reply, the webhook connector’s mapping and a deduplication key. Nested values are reachable by dotted name in labels, the fields profile, view filters and trigger fields. A poll under 10 seconds is refused; a 429 or 5xx backs the source off, up to an hour, honouring Retry-After. Discover fetches once and proposes the rest. - The source form for it reads in order: method, URL, credentials yes or no, additional headers as key-value rows, body for POST. The mapping appears only after Discover, as decisions already made with the sample value beside each, under a panel showing what Tares fetched.
- The builder proposes
http_pollfor a goal that reads a public or third-party API, instead of a webhook plus a script; “tell me when a city gets storm winds, from a public weather API” now builds in one sitting.
Changed
- Source form: test and save results sit above the buttons, not at the top of the page, and a required field the click found empty turns red and scrolls into view. A URL field is checked on save (http or https, a host) on Prometheus, Prometheus alerts and Loki as well.
1.26.0: 2026-09-07
Added
- The builder in two columns. The conversation on the left with the answer box pinned under it, and a “To do” column on the right holding every card the assistant proposed. A decided card folds to one line; the pointer the chat leaves for each card opens it. A one-line head carries the steps, the project name and the goal.
- Overview shows the Projects panel with Create new also on an instance with no project yet.
Changed
- The builder no longer invents a trigger for the agent: the daemon refuses an agent proposal whose trigger does not exist, Continue on the views and triggers step waits until a trigger exists, the step names sources that have no events yet, and the agent card never prefills an unknown trigger.
- Front door: the starter sentences keep a fixed order instead of reordering while you type, the picked one is marked, and the call to action reads Build it.
- The assistant shows a readable line for a non-JSON error reply, such as a proxy’s 502 page.
Fixed
- Behind an nginx ingress, a builder step sent about five seconds after the previous one could fail with 502 “upstream prematurely closed connection”: the proxy reused a pooled connection the daemon was closing at that moment. The daemon now keeps idle connections open longer than the proxy’s pool.
1.25.0: 2026-09-04
Added
- Build with Tares, the guided project builder. Describe what you need; the
assistant proposes sources from the installed connectors, then views and triggers, then an
agent, one step at a time, asking before it guesses. Each proposal is the object’s own form,
prefilled, with the fields only you can fill marked. Nothing is created until you click, every
Apply goes through the normal API, and the result is an ordinary project. A goal that matches
a template is proposed as that template.
POST /api/agent/chattakesmode: "build"andstep. - A new front door. An instance with no project of its own opens on one question, “What do
you want to build?”, with starter sentences from the templates, a paste-your-last-incident
door and the demo as a one-click offer. The same screen is Projects → Create new; the template
gallery is behind Use a guided template.
GET /api/projects/templates/{key}serves one template. - Project page: source rows fold open to the ingest endpoint or the polled target, with Configure. Framed empty states for runs, firings and events.
Changed
- Deleting takes dependents along. A source or view delete lists what depends on it and
offers to delete those too (
cascade=true;GET /api/catalog/dependentslists them). A project delete lists its objects with picks; unpicked ones stay (DELETE /api/projects/{id}?delete=kind:name,...).
1.24.0: 2026-09-04
Added
- Runs on an agent’s page and a project’s Agents tab filter to successful or failed runs, and
Show more pages past the first fifty (
statusandoffseton the runs endpoint).
Fixed
- Edit on a project from a template without its own wizard opened the create form and said the template did not exist. The form loads the template by key, prefills the project’s parameters (secrets blank, blank keeps the stored value) and saves in place.
Changed
- The root span of a traced run carries
tares.instanceandtares.agentas attributes.
1.23.0: 2026-09-03
Added
- Agent tracing. Every Tares agent run and every Ask turn can be exported as an OpenTelemetry
trace: a root span, one span per model call and one per tool call, in the conventions GenAI
observability backends read. Rius is a preset; any OTLP/HTTP endpoint works with the
otlpprovider. Settings → Observability holds the switch;TARES_TRACING_*sets the same from the environment. Off unless switched on.
1.22.0: 2026-09-03
Added
- Pause a project with its sources. Pause asks whether to pause the sources too; Resume
brings back exactly what Pause stopped.
{"sources": true}on the pause endpoint. - The GitHub source form picks a stored token from a dropdown and the repo from the list that token can see; a new token can be saved from the same form.
Changed
- The challenger project’s sessions open in place, with the summary, that session’s memory proposals and the exchange under the row. The project page shows the status badge beside the name.
1.21.0: 2026-09-02
Added
- The
rius_rcaproject template: the Tares half of the Rius RCA integration, created by the Rius control plane over the API and hidden from the gallery.
Fixed
- Unknown
/apiand/ingestpaths answer with a JSON 404 instead of the console’s HTML. - PUT on a view or agent no longer requires the name in the body; a rename is still refused.
GET /api/sources/discoverexplains that discover is POST-only.
1.20.0: 2026-09-01
Changed
- The side nav has two groups. Projects at the top with Overview and Ask; everything a project is made of in one Catalog group in pipeline order.
- The demo’s logs source drops routine 2xx access lines in hosted mode.
Fixed
- Deleting a template project with purge also deletes its triggers’ firings.
1.19.0: 2026-09-01
Changed
- Every project renders on one page: Setup (sources, views and triggers editable in place, subscribers), Events, Firings, Agents, and Sessions where a template reports them. Template actions, Repair and the change history moved with it.
- Templates describe their page extras as data (panels and cards); a new template needs no console work.
1.18.0: 2026-09-01
Added
- The project page manages subscribers: a Subscribers box lists everyone subscribed to the project’s triggers, with what each received, and adds or removes them there.
- The project Firings tab shows who each firing was delivered to.
/projectsis the list of projects; the ways to start one moved to/projects/new.
Fixed
- Deleting a trigger also removes its subscriptions.
1.17.0: 2026-09-01
Changed
- Deliveries is now Firings. A firing is the event, a delivery is what happens to it per
recipient;
/deliveriesredirects. External subscribers moved to the agents page. - The Sources, Views, Triggers and Firings pages became lists with filters; the firing page is one facts box with the payload beneath.
Fixed
- A delivery whose Tares agent is still running showed as failed; running, delivered and failed are distinct.
1.16.0: 2026-08-31
Added
- Hand-assembled projects got their own page with four tabs: Setup, Events, Firings, Agents.
Changed
- Trigger page: the watched view and the project badge moved into the first box.
1.15.1: 2026-08-31
Changed
- Rerun is offered on every finished agent run, not only failed ones.
1.15.0: 2026-08-31
Added
- A per-agent budget.
budget_usdon a Tares agent caps its lifetime spend; once reached, runs are capped before any model call and the run says where to raise or clear it. - On a hosted demo stack the AI SRE demo’s agent is born with a $2 budget.
1.14.0: 2026-08-31
Changed
- Use cases are now projects; recipes are templates. A project is a named set of sources,
views, triggers, agents and MCP servers with one page; the shipped recipes are Tares templates.
The API moves to
/api/projectsand/api/projects/templates, catalog YAML usesprojects:withtemplate:, and the seed variable isTARES_SEED_PROJECT. The old routes, YAML keys and variable keep working for two releases. claude_codeevents label the repository the session ran in asrepo(wasproject); saved sources, views and stored data follow on upgrade.
Added
- Projects from existing objects. Assemble a project from the sources, views, triggers, agents and MCP servers you already have; nothing is created, and removing an object from the project leaves it in place.
- Rerun an agent run. A run that failed, ran out of rounds, was capped or came back empty has a Rerun button: same trigger, same entity, same firing data, against the agent’s current definition. Runs also open with the agent’s previous finding for the entity, a head start instead of rediscovering it.
- The challenger session thread lists every finding of a review in full.
1.13.0: 2026-08-27
Added
- Challenger workflow in the console. The use case page lists every challenger session with the plan and per-commit review outcomes, the Claude/Codex exchange as one thread, a Summarize button per session, and the summarizer’s memory proposals with Accept / Reject. Decisions are kept on the memory source, so they hold in every browser.
- The first session marked as a challenger session creates the
challenger_workflowuse case by itself;/tares:challengerin Claude Code is the whole setup.
Fixed
- Plugin fixes for marketplace installs,
git -c ... commit, and Codex 0.150’s sandbox flags; only[P1]findings block on a plan critique. - Use case actions that start an agent run (
summarize) failed undertares upand left a run stuck at running. - Challenge outcomes read “no findings” / “N findings (M blocking)” instead of PASS/FAIL, which elsewhere in the console means a broken run.
1.12.0: 2026-08-27
Added
- Challenger workflow. A second model challenges Claude Code’s plan and every commit,
locally, while Tares keeps the record: a per-session view, a trigger on session end and a
summarizer agent that writes a session summary with memory proposals. The
claude_codeconnector gains theflowlabel and challenge events with verdict, sha, round and finding counts. - Claude Code plugin 0.2.0.
/tares:challengerturns a session into a challenger session; the plugin runs Codex on plan exit and after each commit (blocking on P1/P2 findings, with a fix loop and/tares:challenger-waive), ships every review to Tares, and hands accepted memory to Claude at session start.
1.11.0: 2026-08-26
Added
- Install skill for coding agents:
npx skills add glassflow/tares --skill tares. From one prompt, an agent installs Tares, starts it, adds a first source, connects itself over MCP and shows one read. tares status: a readiness checklist for a running instance that ends with the one next step;--jsonfor scripts.tares upprints the same “Next:” line under the console URL.
Changed
- An agent run without a key, and the banners on the Agents pages, say what to do: set
ANTHROPIC_API_KEYbeforetares up, or add a key under Settings.
1.10.0: 2026-08-25
Changed
- A key stored in the console now takes precedence over
ANTHROPIC_API_KEY(it was the other way around). If you relied on the env var overriding a stored key, clear the stored key.
Added
- Grafana Loki connector. Polls a LogQL stream selector; one event per log line with the stream’s labels and the same derived fields as docker_logs. Works against any reachable Loki, including Grafana Cloud.
- The AI SRE demo works against a hosted demo stack when the
TARES_DEMO_*URLs are set; with them unset the local docker compose flow is unchanged. - The spend meter records which key paid:
GET /api/usage/modelreports aby_key_sourcesplit, so an operator-provided key’s spend is separable from your own. TARES_SEED_USECASE: seed a named use case once on first boot, so an instance starts with a working setup instead of an empty catalog.
1.9.0: 2026-08-24
Added
- Model usage and cost per agent run. Every run records its model, token usage and a USD cost priced at write time; Ask turns are metered the same way. Runs from before this release show no cost (unknown, never guessed).
GET /api/usage/model: the instance’s Anthropic spend as all-time totals plus a per-day tail, split by surface.- The Tares agents page is an operational surface: stat cards, tabs, and runs as a table with model, rounds, tokens and cost, expandable to the finding.
1.8.2: 2026-08-19
Fixed
- A trigger no longer misses a key whose source ingested right after another; a skipped evaluation is re-run once the debounce interval ends.
- Shared code context: the
every_committrigger’s detection window is 5 minutes, matching the 60-second source poll.
1.8.1: 2026-08-19
Added
- AI SRE demo as a use case. Use cases > AI SRE demo (tagged demo) creates the same three
sources,
service_timelineview,incidenttrigger andincident-first-lookagent the demo catalog seeds, with one click; an already imported demo catalog is adopted, not duplicated. The setup page asks Docker what is running and fills the Prometheus and api-server URLs and the log container from it, shows the docker commands with copy buttons when the stack is not up, and takes an Anthropic key inline. The use case page has Cause an incident (error spike, latency, dependency outage) and Clear the fault buttons. Recipes can declare tags, setup steps, actions, a guide link and a detect hook.
Fixed
- Auto-discover (Docker) works again when a Prometheus container is running; it proposes a reachable starter metrics source and says how many metrics wait to be picked on the source page.
1.8.0: 2026-08-18
Added
- Use cases. A new console section and framework: a use case is a ready-made setup that creates
ordinary Tares objects and owns them (badge on their pages, editable and deletable there; an edit
marks the object customized, a hand delete shows as missing with Repair). Create, update by
re-plan, pause and resume, delete, repair;
/api/usecases;usecases:in catalog YAML. Use cases are now Projects. - Shared code context use case: one commits source per repository, a view with one timeline per repository, a trigger on new commits, GitHub’s hosted MCP server registered with the stored credential, and an agent that keeps a context repository current as pull requests; existing pages updated in place or one page per repository; optional first look on start. See the guide.
- GitHub credential stored once under Settings > GitHub;
credential: <name>ongithubsources,credential:github/<name>on MCP servers; rotation in one place. - MCP servers take extra headers (for example
X-MCP-Toolsetson GitHub’s hosted server). - Per-agent round cap
max_rounds(default 6, 12 with external MCP servers) and anexhaustedrun status with a partial note. - GitHub commits carry their changed files in the payload (capped;
files: falseto skip). - Settings has tabs: Access and API keys, Anthropic, GitHub, Slack.
1.7.1: 2026-08-17
No code changes. A version bump so managed Tares Cloud instances can be re-provisioned through the upgrade path.
1.7.0: 2026-08-17
Added
- A Tares Cloud instance links to its workspace. With
TARES_WORKSPACE_URLset (reported on/healthasworkspace_url), the console shows a Workspace link in the sidebar footer and a banner in Settings naming what is managed there. Self-hosted instances never set it and see nothing.
1.6.0: 2026-08-17
Changed
- The console wears the GlassFlow design system, the same palette and type as Rius, in both themes.
- The sidebar is rearranged: Overview and Ask on top, then Data, Automate and Agent access, with Settings in the footer. A new Deliveries page holds every subscriber with its delivery health and every trigger firing. MCP servers has its own entry, and Security moved into Settings. Old routes redirect.
Fixed
- Agent findings posted to Slack render properly instead of as raw Markdown; tables become aligned monospace blocks and long findings are split.
1.5.1: 2026-08-17
Fixed
- The trigger page keeps setup out of the way: the webhook and Slack forms open from Add webhook and Add Slack channel buttons instead of always being open.
1.5.0: 2026-08-14
Added
- Tares agents can use external MCP servers. Register a server once (streamable HTTP URL and an optional auth header, stored as a secret; Test lists its tools), then opt agents in on their form. Each run records which external tools it called. A down server is skipped, and a failed call is evidence for the model rather than a failed run. See Tools and MCP servers.
- A model per agent, picked from a list, or the instance default (
TARES_AGENT_MODEL). - Findings go where you already look: post to a Slack channel through the workspace bot, or POST each finding as JSON with its run metadata to an authenticated webhook. See Deliver findings.
- Paste a catalog snippet. Add via YAML on the Add source page merges a snippet into the live catalog: validated first, upsert-only, no restart. One paste can carry sources, triggers, agents and MCP servers.
Fixed
- Delivery links on a firing’s page lead to the run for that firing, or to the external agent.
1.4.0: 2026-08-14
Added
- Ask keeps your conversations. Every conversation is saved on the instance, listed in a sidebar next to the chat, and the newest resumes when you come back. The instance keeps the newest 50.
1.3.1: 2026-08-14
Fixed
- Explore no longer sticks at “reading timeline…” after a background tab becomes visible.
- The Connect page no longer shows the access token in clear text. Every snippet shows the masked token, and the copy button copies the real one.
1.3.0: 2026-08-10
Added
- Connect → MCP asks which client you use (Claude Code, Codex CLI, Cursor, Claude Desktop, other) and shows its exact command with your endpoint and token filled in. See Connecting agents.
- A new instance with no sources opens on Sources, where the next step is.
- The trigger page links the webhook contract (
/connect?tab=push).
Fixed
- The webhook tab states the acknowledge rule the dispatcher uses: 2xx acknowledges, 5xx and transport errors are retried with backoff, and a 4xx is recorded as failed and not retried.
1.2.1: 2026-08-07
Fixed
- A Slack channel on a trigger shows as a subscriber, not as an agent, and a subscription can be removed from the console. Slack rows show the channel name instead of its ID.
1.2.0: 2026-08-07
Added
- Pick a Slack channel from a list of the channels the bot can post to, private ones marked
with a lock. Needs the
channels:readandgroups:readscopes; a token issued without them falls back to typing the channel.
Changed
- Slack alerts no longer unfurl links, link to the firing instead of the entity, and show times in each reader’s timezone.
/tares askanswers render tables and rules properly in Slack.- The console’s remaining native dropdowns use its own themed picker.
1.1.1: 2026-08-07
Added
- Vercel sources expose the request block:
status_code,url,method,referer,path_type,regionandcachecan be labels and keys. See Vercel.
Fixed
- The Vercel connector no longer discards the HTTP status code.
- Ask proposes filters in the shape the console accepts, and shows each proposed filter instead of a count.
1.1.0: 2026-08-07
Changed
- Breaking:
/api/agent/chatno longer accepts anX-Anthropic-Keyheader. There is one Anthropic key per instance,ANTHROPIC_API_KEYor the one stored in Settings, used by Ask,/tares askin Slack and Tares agents alike. A request with no key configured anywhere gets a 400. - Ask and Organize are one assistant.
/organizeredirects to/ask. - The Ask page reads well at length: it scrolls with the page, follows new output only while you are at the bottom, and draws tool calls as steps.
- The source page names which rule rewrites each label, and the entity key is picked from one dropdown.
Fixed
- A failed tool call in Ask no longer reports itself as successful.
- Pressing Stop no longer breaks the next question.
1.0.2: 2026-08-06
Changed
- Documentation moved to docs.glassflow.ai/tares , and repository
links follow the rename to
glassflow/tares.
1.0.0-1.0.1: 2026-08-05
Changed
- NavFlow is now Tares. This release is breaking, with no compatibility layer. The package and
command are
tares, the daemon istaresd, the MCP proxy istares-mcp, and--navflowdis--taresd. EveryNAVFLOW_*environment variable is nowTARES_*, and the old names are not read. The image isghcr.io/glassflow/tares, the repository is glassflow/tares , and the Claude Code plugin istares@tares. - The database file is
tares.duckdb, previouslynavflow.duckdb, inside a data home that moved from~/.navflowto~/.tares.
Two guards instead of a fallback. Both renames above would otherwise fail quietly, coming up
healthy and empty while the real data sat untouched beside the new file. So the daemon refuses to
start if any NAVFLOW_* variable is still set, or if a pre-1.0 database sits next to a missing
tares.duckdb, and prints the rename or the mv you need. Full instructions:
Upgrading from 0.x.
0.2.0: 2026-07-26
Added
- Tares agents: a prompt attached to a trigger. When the trigger
fires, Tares reads the correlated timeline and writes a finding back onto the entity’s
timeline (a built-in
findingssource). Configured in the console (Agents) or the catalog (agents:); enabled ⟺ subscribed to its trigger; read-only (it concludes, it doesn’t act). The demo ships one that diagnoses the injected incident out of the box. navflow up --auth: one switch for authentication. Bare--authgenerates and persists a root token and prints a…/?token=…login URL each launch;--auth=<token>uses your own. Open by default (navflow up).- Per-source API keys: creating a push source on a secured instance mints an
ingest-scoped API key for it (shown once). The Security page groups Access, API keys, and the Anthropic key.
Changed
- Ingest is gated by auth like every route. Producers authenticate with scoped
ingestAPI keys (Authorization: Bearer <key>), not a shared token.
Removed
NAVFLOW_INGEST_TOKENandNAVFLOW_READONLY: folded into the one auth switch + scoped API keys.GITHUB_TOKENandNAVFLOW_VERCEL_VERIFYenv vars: GitHub tokens come from the source’stokenconfig; Vercel drain verification echoes Vercel’s own probe header.NAVFLOW_ANTHROPIC_KEY: useANTHROPIC_API_KEY(or the console-stored key).
0.1.36: 2026-07-23
Added
alertmanagerconnector: a push receiver for Alertmanager. Point awebhook_configs.urlat the source’s ingest endpoint; each routed alert becomes an event (keyed by a label, firing / resolved). The source page shows a copy-pastealertmanager.ymlreceiver block.
0.1.35: 2026-07-23
Added
prometheus_alertsconnector: polls Prometheus’s own/api/v1/alertsand emits one event per active alert (keyed by a label), plus aresolvedevent when it clears. Discover lists the configured rules with an optional severity filter.referenceconnector: documents (json / csv / md / txt) attached to an entity by their labels, always surfaced when correlating on that entity regardless of the read window.
Removed
alertsandstaticconnectors: superseded byprometheus_alerts/alertmanagerandreferencerespectively.
0.1.34: 2026-07-22
Changed
- Prometheus: pick the metrics, no PromQL. Discover now lists the
server’s metrics and labels; you pick what to ingest (by name or by label) and Tares writes the
query. The metric value is stored as a number-typed
valuelabel, so triggers can aggregate it. Added bearer / basic auth.
0.1.32-0.1.33, 2026-07-22
Changed
- Postgres: the connection URL (
dsn) is a required per-source config field, stored as a secret; the driver ships in the base package (no[postgres]extra); you can select which columns to pull. Droppedkey_column(the key is aprimarylabel) andcursor_type(inferred from the value).
0.1.4: 2026-07-03
Removed
changelogandconfigconnectors: dummy, demo-only connectors that had outlived their use. Also drops the demo api-server’s unused/admin/changelogand/admin/configendpoints and renames its fault switch/admin/inject→/demo/inject.
0.1.3: 2026-07-03
Added
include_payloadonread/query: opt-in flag that returns the full lossless stored record asrawon each row, alongside the summarytext. Exposed over HTTP and the MCPread/querytools; covers all connectors.
Fixed
- Claude Code plugin install: publish a root
marketplace.json(/plugin marketplace add glassflow/navflow) and fixplugin.jsonload errors on Claude Code 2.1 (duplicate hooks ref, missingingest_tokendefault,navflow_urlrequired flag hiding its default). - Double-ingest for
claude_code: the first pushed event flips a poll-mode source to push mode, so a source fed by the plugin no longer also tails files and ingests every event twice.
0.1.2: 2026-07-02
Added
navflow --version.
0.1.1: 2026-07-02
First public (soft-launch) release.
Added
read(selector, window)primitive: a correlated, time-ordered read across all sources matching a strict-AND conjunction oflabel=valueconstraints, with no view required. Exposed over HTTP (POST /read) and MCP (thereadtool). Views become an optional narrowing lens; triggers still attach to a view.- Console redesign: a selector-first Explore (pick an entity, add filters, read across every source, with a human/agent view toggle), a ⌘K Ask command palette, a three-act navigation, and separate Views / Triggers pages.
- Agents → Reads: a client filter (defaults to
mcp) over the read activity log.
Changed
- Package and CLI distribution renamed from
navflow-mvptonavflow.