Privacy

Last updated 6 October 2026.

The short version

toryo runs on your own machine. Your source code, your prompts, and your agents’ output are not sent to us, with two exceptions. The first is crash reports. When toryo itself crashes, and when an agent harness it started crashes or refuses to start, it sends a short error message. That message is whatever the failing code put in it, so it can quote a fragment of what toryo was processing. Secrets are redacted from it, paths are collapsed, it is capped at 500 characters, and you can turn crash reports off entirely. The second is hosted knowledge. If your team’s owner turns on hosting, the team’s shared knowledge is stored with us, including comment text from your files. What we hold otherwise is the small amount of information needed to email you and to license the software, and optional website audience measurements.

What this website collects

If you submit the form, we store your email address, which form it came from, and the time you submitted it. That is the information the signup form collects. When audience measurement is allowed, a successful signup is also counted as a custom event, described below, which never carries your email address. Signing up creates no account and no password.

The site sets no cookies for audience measurement and embeds no third-party trackers. Optional audience measurement estimates public page displays, unique visitors and visits to understand aggregate usage and rough changes after posts on different channels. Repeat displays count again; blocked requests, network failures and imperfect bot filtering can cause undercounting or overcounting. Visitor and visit counts, and the conversion counts built from the custom events described below, are estimates: they are not people, accounts or verified attribution.

When enabled, measurement retains the normalized public page path, server timestamp, a daily visitor hash and a visit record (both described below), broad browser and operating-system families, approximate country and region (not city or coordinates), external referrer hostname, internal, external or unknown referrer classification, which toryo site an internal referral came from (toryo.ai or docs.toryo.ai, never the page), and approved source, medium and campaign labels, and for each page display, how long the page was visible (up to 30 minutes) and how far down it was scrolled, as a percentage. Internal hostnames are discarded before transmission and storage. Unknown attribution and unavailable location or browser details stay unknown. When you leave a counted page, including by moving to another page on this site, the browser sends that page's visible time and scroll depth in one final request, without cookies or a referrer.

Measurement also records a fixed list of actions, called custom events: a successful newsletter signup, a click on a download link, and a click on a link to another site. For each it retains the event name, the page it happened on, the server timestamp, the daily visitor hash and visit described below, and at most one allowlisted detail: the operating system section a download link sits in (macOS, Windows, Linux or other), or the hostname a link leads to when it is toryo.ai, docs.toryo.ai or github.com. Any other destination is kept as unknown, and a destination's path is never sent. A signup event records only that a signup happened, never your email address, and is not linked to it. Custom events never start, extend or end a visit. They follow the same opt-out, GPC and Do Not Track suppression as page displays, are sent only for a page whose display was counted, and are kept and deleted on the same schedule. The list of events and details changes only with a reviewed release; any other event name or detail is rejected.

To count visitors and visits without cookies, the server computes a visitor hash from a secret random salt, the fixed name toryo.ai, your IP address and your browser's full user-agent string, using a keyed one-way function (HMAC-SHA256), and keeps only the first 64 bits. A new salt is generated at random for each UTC day and is used to compute stored hashes only on that day. It is kept through the following UTC day, only so that a visit crossing midnight UTC continues, and is then deleted, so no salt is kept longer than about 48 hours unless an outage delays that deletion. While a salt exists, someone holding both it and the measurement database could test guessed IP addresses and user agents against a hash. Once it is deleted, hashes made with it can no longer be matched to an IP address or user agent. The same browser gets an unrelated hash each day, so separate visits on different days cannot be linked, except that a visit continuing across midnight UTC links that browser's hashes for those two days. The same hash is used on toryo.ai and docs.toryo.ai, so someone who reads both sites on the same day counts as one visitor. Page displays from the same visitor hash belong to one visit until 30 minutes pass with no display, not counting up to 30 minutes of time spent viewing each counted page, and leaving a page you viewed restarts that count; the next display after that starts a new visit. A visit record holds its start and last-activity times, first and last page, the site it began on, its number of displays, total visible time, whether it was a single-display visit with under 10 seconds of visible time, and a copy of the referrer hostname and classification, campaign labels, coarse location, and browser and operating-system families of its first display, with the traffic channel derived from them. Your IP address and user-agent string are used only in memory to compute the hash and are never stored. When the server cannot establish a trusted client IP address, it records the display without a visitor hash or visit.

Only allowlisted values for utm_source, utm_medium and utm_campaign can become campaign labels. No values are currently approved; all three lists are empty. Unapproved or repeated values are discarded, and arbitrary properties are rejected.

Measurement records and diagnostics never store IP addresses, full user-agent strings, full referrers, full URLs or query strings. The daily visitor hash and the visit record are the only per-visitor data kept, and they are not linked to cookies, accounts or other devices. Measurement has no account or signup linkage, advertising integration or external analytics vendor.

A trusted ingress IP may be used transiently, in memory, to compute the visitor hash and to look up approximate location in a locally stored MaxMind GeoLite2-City database. The server periodically downloads that database from MaxMind; visitor IPs are not sent to MaxMind for lookup. Separate abuse protection for forms holds IP keys in memory. Cleanup is demand-driven, so we do not promise a fixed IP-erasure deadline. These measurement limits do not describe all hosting or application logs.

Measurement is enabled on this site. Checking the control below suppresses measurement in this browser. It stores only a local opt-out flag, not a visitor identifier, in this site's localStorage. The preference applies to this browser and site origin, persists until removed or site storage is cleared, and needs to be set separately on another browser or device. Unchecking removes the flag; an unchecked control is not affirmative legal consent.

Global Privacy Control (GPC) and Do Not Track suppress measurement and override allowance. Failure to read or write browser storage also suppresses collection; a failed save cannot promise the preference will persist. Opting out aborts pending requests where possible, but cannot retract events already received. Allowing measurement later does not replay suppressed displays or custom events.

Reading browser preference.

What licensing collects

If you start a trial or activate a seat, the license service records:

  • your email address, and your name if you give one
  • your license and seat, including plan, seat count, and status
  • an identifier for each machine you activate on, plus when it was first and last seen

Machine identifiers exist so that one seat covers all of your own machines instead of being consumed by the first one. They are not device fingerprints and are not used to track you across anything.

Crash reports

When toryo crashes, it sends us a crash report by default. The report holds toryo’s own stack frames, the error message with paths and anything that looks like a secret stripped out, which app and command failed, the version and platform, and the account and user identifiers from your license.

The report is built from a fixed set of fields, and none of them is your email address, your license key, your environment variables, the arguments you ran toryo with, a request or response body, the values in your database, or the signed proof your license is real. That is a fact about the report’s shape rather than something we filter for: sending any of them would mean adding a field to the report first.

The one free-text field is the error message, and it has secrets redacted and paths collapsed before it is sent. That is a filter rather than an absence, so it is worth being precise about it. The message is whatever the failing code put in it, which means it can quote a fragment of what toryo was processing when it broke. What the filter then does is replace anything shaped like a secret and any email address, reduce each path to a label and a filename rather than your directory tree, and cut the whole message to 500 characters.

A worker whose agent harness crashes or refuses to start sends a report as well, and its message is the harness’s own error output, under the same redaction, path collapse and 500-character cap. Which failures qualify is deliberately narrow: the harness dying, the harness or the worker never starting, the harness refusing something toryo asked it for, and your provider’s API failing. A run whose agent completed and then failed its own task sends nothing, so the failures whose text would be your agent’s own output are not the ones that report.

A worker’s report also carries identifiers and labels for the job it was running: the job and project identifiers, which provider and model it used, which build of that provider’s harness is installed, and how the run ended, meaning the exit kind, exit code, signal, duration and retry count. The identifiers are opaque, and every other value is a short label: your provider’s own name for its harness and model, and toryo’s own for how the run ended. Each one goes through the same filter as the message. Your prompt, your project’s name and directory, and the job’s payload are not among them.

Reports are processed by Sentry on our behalf. To turn it off, run toryo settings set --telemetry false, use the toggle in the desktop console’s settings, or set TORYO_TELEMETRY=0 in your environment. The desktop console picks the change up the next time you open it.

What stays on your machine

Your repositories, your prompts, and your agents’ output stay on infrastructure you control. toryo’s execution plane is local by design: an agent working on your code is a process on your own machine, in every configuration of the product.

A hosted team is the exception for knowledge. Its shared knowledge, described below, is stored with us. That includes what your agents record as memories, and a code index that carries comment text from your files.

Model usage goes directly from your machine to your provider under your own credentials. We do not proxy it, see it, or bill for it. That provider’s handling of the traffic is governed by your agreement with them, not by this notice.

One thing does come back to us when toryo, or a harness it started, breaks: the crash report described above. Of what this section describes, the only thing it can carry is whatever the scrubbed error message quotes of what toryo was processing, and you can turn it off.

Your knowledge plane

The memory, library, and code index your agents build up live in a database. By default that database is on your own machine and we hold no copy of it.

Team and Enterprise include a shared knowledge plane, so a team’s agents learn from one another. A team starts with its knowledge on its members’ machines. Only the team’s owner can turn on hosting, and members cannot override that choice. When it is on, the shared knowledge is stored on our hosted service by default. An Enterprise team can run the same service itself instead, and a self-run service sends us no error reports.

A hosted team’s store holds memories and library documents, each with the vectors your members’ machines computed. It holds project definitions: a name, a git remote, and settings such as verification commands and sensitive paths. It holds a code index of file paths, a hash of each file, exported names, the import graph, and comment text. The comment text is the comment at the top of each file and the doc comment on each exported name, up to 8 KB per file. Library documents contain whatever your team puts in them.

Some things are never stored with us, hosted or not: your repositories, your session transcripts, your personal knowledge that spans all of your projects, and the record of your runs and jobs.

Teams are kept apart by the database itself, with row-level security bound to one team per transaction. The store is encrypted at rest. We hold a hosted team’s knowledge to serve it back to that team. To run the service we look at counts per team, such as how many items are stored and how many requests arrive, not at what the items say.

When our own servers hit an error, they send a report to Sentry. It carries a scrubbed message, the stack, which service failed, and the request method and path, never the query, the headers or the body. The message can quote a fragment of what the server was processing. The crash-report setting described above does not cover our servers.

A team can ask us to delete the whole of its hosted knowledge. Ending access and destroying data are two separate steps, so we will confirm before doing the irreversible one.

How long we keep it

Interest-list addresses are kept until you ask us to remove them. Licensing records are kept for as long as the license is active and for a reasonable period afterwards for accounting purposes.

Audience measurement retains individual page-view events and custom events, with their visitor hashes, and visit records for 13 calendar months; there are no separate aggregate counts. Visitor-hash salts are deleted as described above. Scheduled sweeps remove expired data; outages and catch-up backlogs can extend physical retention. These limits cover the measurement tables, not a promise about backup or infrastructure-log retention.

A hosted team’s knowledge is kept until the team deletes it or asks us to. Deleted rows can remain in backups until those backups age out.

Who else sees it

We do not sell personal information and we do not share it for advertising. It is handled by the infrastructure and database providers that run this site, the license service and our hosted knowledge service, and crash reports are processed by Sentry. Sentry also processes error reports from our own servers. All of them act on our instructions.

Your choices

Use the browser control under What this website collects to object to website audience measurement at no charge. This choice is separate from the crash-report settings above.

Write to support@toryo.ai to see what we hold about you, correct it, or have it deleted. Deleting a licensing record ends the license it belongs to, so we will confirm before acting on that one.

Changes

If this notice changes in a way that affects you, we will update the date at the top and, where the change is material, tell the people on the list.