Skip to Content
TaresReferenceRelease notes

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 session starts 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) and POST /api/projects/{id}/release (the orchestrator, or the person’s session), releasing in /api/crew/projects, the release_project MCP tool, and finish_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/tares adds 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 install is 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 login opens 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 over 127.0.0.1 with 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. --cloud points at another console.
  • tares logout removes this machine’s key from the workspace and deletes the saved login.
  • One order everywhere. A flag, then TARESD_URL and TARES_AUTH_TOKEN, then the saved login, then the local Tares. tares status says which workspace it is signed in to, and tares factory doctor says 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 login prints 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 up starts 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 doctor checks what the crew needs.
  • /tares:spec turns 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 spec opens 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 finish does 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}/results takes show (findings or agent:<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-mcp in every session. Locally, run tares mcp --transport streamable-http next to tares up; the new plugin option mcp_url defaults to http://127.0.0.1:8788/mcp. On Tares Cloud, set mcp_url to https://<cell>.tares-glassflow.com/mcp; nothing needs installing. Each session’s station, role and project travel as X-Tares-* headers, so many sessions share one server. tares factory refuses to start sessions when the endpoint does not answer. tares-mcp over stdio still works for other MCP clients. See Claude Code.

Fixed

  • write_milestone keeps 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/drafts and POST /api/projects/{id}/setup/plan take name and description.
  • 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/channels lists every public channel of the connected Slack, not only the ones Tares was added to, plus the private channels Tares is in, each with is_member. When a re-read fails, the last good list is served with stale: 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:read and commands.
  • 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_broker credential 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.
  • /health reports slack_connect_url, workspaces_url, workspace_api_url and logout_url when 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.id on every span, rius.main_agent.name beside gen_ai.agent.name, and service.version on 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 github source: 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_run posts 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 github connector is labelled “GitHub”. Upgrading adds event_type = commit to 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 conclude tool 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_finding and project_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, filters and key_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 /query and POST /derive answer 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_rca template takes a daily_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_URL is 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 triage preset 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 stats tool (counts per label value, this window against the one before) and can end a run with conclude: no_op when 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: true wakes 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_KEY and OPENAI_BASE_URL seed an OpenAI entry; TARES_MODEL_PROVIDER names 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 key is resolved when the run starts, and the body carries the firing’s labels as labels so 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_SIZE is 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’s key (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_URL and ANTHROPIC_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_poll connector. 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_poll for 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/chat takes mode: "build" and step.
  • 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/dependents lists 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 (status and offset on 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.instance and tares.agent as 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 otlp provider. 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_rca project 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 /api and /ingest paths 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/discover explains 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.
  • /projects is 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; /deliveries redirects. 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_usd on 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/projects and /api/projects/templates, catalog YAML uses projects: with template:, and the seed variable is TARES_SEED_PROJECT. The old routes, YAML keys and variable keep working for two releases.
  • claude_code events label the repository the session ran in as repo (was project); 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_workflow use case by itself; /tares:challenger in 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 under tares up and 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_code connector gains the flow label and challenge events with verdict, sha, round and finding counts.
  • Claude Code plugin 0.2.0. /tares:challenger turns 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; --json for scripts. tares up prints 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_KEY before tares 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/model reports a by_key_source split, 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_commit trigger’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_timeline view, incident trigger and incident-first-look agent 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> on github sources, credential:github/<name> on MCP servers; rotation in one place.
  • MCP servers take extra headers (for example X-MCP-Toolsets on GitHub’s hosted server).
  • Per-agent round cap max_rounds (default 6, 12 with external MCP servers) and an exhausted run status with a partial note.
  • GitHub commits carry their changed files in the payload (capped; files: false to 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_URL set (reported on /health as workspace_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:read and groups:read scopes; 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 ask answers 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, region and cache can 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/chat no longer accepts an X-Anthropic-Key header. There is one Anthropic key per instance, ANTHROPIC_API_KEY or the one stored in Settings, used by Ask, /tares ask in Slack and Tares agents alike. A request with no key configured anywhere gets a 400.
  • Ask and Organize are one assistant. /organize redirects 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

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 is taresd, the MCP proxy is tares-mcp, and --navflowd is --taresd. Every NAVFLOW_* environment variable is now TARES_*, and the old names are not read. The image is ghcr.io/glassflow/tares, the repository is glassflow/tares , and the Claude Code plugin is tares@tares.
  • The database file is tares.duckdb, previously navflow.duckdb, inside a data home that moved from ~/.navflow to ~/.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 findings source). 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 --auth generates 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 ingest API keys (Authorization: Bearer <key>), not a shared token.

Removed

  • NAVFLOW_INGEST_TOKEN and NAVFLOW_READONLY: folded into the one auth switch + scoped API keys.
  • GITHUB_TOKEN and NAVFLOW_VERCEL_VERIFY env vars: GitHub tokens come from the source’s token config; Vercel drain verification echoes Vercel’s own probe header.
  • NAVFLOW_ANTHROPIC_KEY: use ANTHROPIC_API_KEY (or the console-stored key).

0.1.36: 2026-07-23

Added

  • alertmanager connector: a push receiver for Alertmanager. Point a webhook_configs.url at the source’s ingest endpoint; each routed alert becomes an event (keyed by a label, firing / resolved). The source page shows a copy-paste alertmanager.yml receiver block.

0.1.35: 2026-07-23

Added

  • prometheus_alerts connector: polls Prometheus’s own /api/v1/alerts and emits one event per active alert (keyed by a label), plus a resolved event when it clears. Discover lists the configured rules with an optional severity filter.
  • reference connector: 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

  • alerts and static connectors: superseded by prometheus_alerts / alertmanager and reference respectively.

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 value label, 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. Dropped key_column (the key is a primary label) and cursor_type (inferred from the value).

0.1.4: 2026-07-03

Removed

  • changelog and config connectors: dummy, demo-only connectors that had outlived their use. Also drops the demo api-server’s unused /admin/changelog and /admin/config endpoints and renames its fault switch /admin/inject → /demo/inject.

0.1.3: 2026-07-03

Added

  • include_payload on read/query: opt-in flag that returns the full lossless stored record as raw on each row, alongside the summary text. Exposed over HTTP and the MCP read/query tools; covers all connectors.

Fixed

  • Claude Code plugin install: publish a root marketplace.json (/plugin marketplace add glassflow/navflow) and fix plugin.json load errors on Claude Code 2.1 (duplicate hooks ref, missing ingest_token default, navflow_url required 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 of label=value constraints, with no view required. Exposed over HTTP (POST /read) and MCP (the read tool). 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-mvp to navflow.
Last updated on