Skip to main content
Tessary watches agents running in production. It reads every trace your agents produce, runs classifiers over all of them to detect changes and likely problems, checks whether each detected change is a real issue, and then investigates what caused the ones that are. The four stages have names you will see throughout these pages. A classifier creates a finding when it detects a change. Triage decides whether the finding is a real issue. A validated finding becomes a case. An agentic RCA (root-cause analysis) run then investigates the case and reports what it thinks caused it. Tessary comes in two editions. Open Source is free, and you run it one of two ways. Tessary Cloud is the hosted service. The open edition is the code in the tessary repository, released under the Apache License 2.0, and you self-host it. These pages cover both. Paid adds custom classifiers, higher limits, longer retention, and support over a dedicated Slack channel, and you self-host it or use managed hosting.

​
Sign up for Tessary Cloud

Tessary Cloud is the quickest way to start, because there is nothing to deploy. Sign up at app.tessary.ai and your first project opens on the connect screen. It is free, and a one-time model credit pays for triage and root-cause analysis until it is used up or you add your own model provider key. Limits on traces, stored data, and retention are on the pricing page. Start on Tessary Cloud takes you from sign-up to your first finding.

​
Self-host Tessary

Self-host when you want Tessary running on your own infrastructure. A deployment is a single-node Docker Compose stack, and every credential it needs ships with a working default. Paste this into your coding agent:
setup.md is written as instructions to an agent: install what is missing, bring every service up, verify the frontend, and hand back the URL. It needs Docker Engine 26 or newer and Docker Compose v2.34 or newer on the machine. Prefer to run it yourself? The same install is one command, with nothing cloned and no .env to edit:
Either way, open http://localhost once docker compose -p tessary ps reports every service healthy, and create the first account with an email and password. Three of the shipped credentials are placeholders published in the repository, so this install is a localhost test drive until you replace them. Secure the instance covers that, and it is not something the agent does for you.

​
What runs where

Five built-in classifiers run out of the box on Tessary Cloud and self-hosted alike: duration_drift, cost_drift, tool_error, secret_leak, and malformed_output. frustration starts switched off on both and needs an OpenRouter or TypeSafe key. groundedness is on from the start on Tessary Cloud; self-hosted, it starts switched off and needs its model running on a Mac with Apple silicon or a GPU instance on AWS. Triage and root-cause analysis work on both. On Tessary Cloud, the model credit pays for them at first, and you start triage by hand on each finding. Self-hosted, both need a model provider credential you supply, and automatic triage is available but starts switched off, so nothing spends against your provider account until you turn it on. Custom classifiers, which you build for failures specific to your own agent, are available only in the Paid edition.

Editions

What the Open Source and Paid editions each include, what differs between Tessary Cloud and self-hosting, what needs configuring, and where the product’s boundaries are today.

​
Start in three steps

1

Start Tessary

Sign up at app.tessary.ai. To self-host instead, take either self-host path above, create your account, and replace the three placeholder secrets. Start on Tessary Cloud and Set up Tessary cover each path end to end.
2

Instrument your agent

Send traces to the OTLP (OpenTelemetry Protocol) endpoint, and tag every span that covers a model call with a tessary.call_site.id attribute. There is no Tessary client library to install, and the connect screen carries a prompt you can hand to a coding agent. Instrument your agent covers both paths.
3

Review what Tessary finds

Classifiers need a stretch of your own traffic before they can tell a change from normal variation. Once they have it, findings start arriving.

​
What you see after connecting traces

The project reports its progress as a milestone ladder, and Triage names the stage whenever the queue is empty. A new project reads not_connected, then listening once the endpoint is live, then fitting once traces are arriving. Classifiers stay at fitting while they learn what your traffic normally looks like, which takes a while on low volume and is expected rather than a fault. After that, three things appear in order: Tessary explains the issue and hands it to you. It does not open the fix.

How Tessary works

The four stages in detail, and what each one needs before it can run.

The call-site tag

What a call site is, why the tag is required, and where it goes in your code.

Configuration reference

Every environment variable a self-hosted deployment reads, and what it controls.

API keys

The three key scopes, and the surfaces each one reaches.