harness

Privacy

For the free models, mega:flash and mega:full, the update checks, the install and upgrade events and, while you are signed in, the daily usage counts. Last updated 26 October 2026.

Who runs it

The free models are a pilot run by the harness's maintainer. Your own API keys never touch it. The update checks (below) reach the install site every hour, and our server once a day and when you install or upgrade, signed in or not, and send no key. While you are signed in, the daily usage counts (below) also cover the sessions you run on your own API keys: counts only, never the keys or what you sent through them.

Sign-in

You sign in through Google, with the scopes openid and email. Our server receives your Google account id and email address, and keeps them to count your allowance. It never sees your Google password.

Where your prompts go

From the harness to our server, https://mega-server-or7tszhloq-du.a.run.app, then to Google's Gemini API on a paid account. Google's paid-tier terms say it does not use these prompts to improve its products.

In auto mode, signed in without a TypeSafe key of your own, each command to be judged goes through our server to TypeSafe. The harness redacts secrets from it first.

What is stored

Nothing of your prompts or the replies. The server neither logs nor caches them. Beyond that, it keeps these, per account:

• your daily usage totals, which are what the allowance is counted from: for each UTC day, the cost, the number of calls, and the input, output, thinking and cached tokens;
• your account record: your email address and the date you signed up;
• your daily usage counts, once you are signed in (below);
• each sign-in: your account id and email address, the time, and the harness version that signed in; and each sign-out: the time;
• each sign-in token's record: a hash of the token (never the token), your account id and email address, when it was made, when it was last used (updated at most once an hour), and whether it was revoked;
• each step of a browser login, with its time: it started, it was approved or refused (and why, in a word such as expired or cancelled), and the harness collected its token. Once you have approved a login, its steps carry your account id. A login that was never approved or refused leaves only its first step, which is deleted after 30 days. One that was approved, refused or finished keeps its steps, and they say when it started;
• each upgrade of your harness while you are signed in: the previous and new version, the platform and the time (below).

Nothing in that list has a deletion date, apart from the first step of a login above. Our server writes the sign-in, sign-out and login records itself, when you sign in or out, so telemetry = false does not stop them. It also keeps the update check's counters and the install and upgrade records (below).

Usage is also logged: an account id, the model, token counts, the cost and the time, judge calls included. These usage logs are kept for 90 days, in a log bucket set up for them. Every other line of our logs is kept for 30 days, which is Google Cloud Logging's default retention for the project: Google's setting, not ours.

Your token

The harness stores a sign-in token in a private file on your machine. It expires after 7 days without use. harness logout ends it at once.

Signed-in usage counts

While you are signed in, an interactive session sends our server counts of how you used the harness, about once a day, tied to your account. It is on by default. Signing in prints a short line saying so (harness sends daily usage counts (never prompts, files or commands) · /notices), and /notices has the full sentence, with the way to turn it off: harness sends daily usage counts while you are signed in: no prompts, files or commands. Turn them off with telemetry = false in config.toml.

Each report is for whole UTC days, from the day you signed in (or the day the harness first started after the update) up to yesterday, at most the 30 most recent. A report that fails is sent again at a later start. Days while reports are switched off are never sent. It holds, for each day:

• the number of sessions started and resumed;
• the input and output tokens used, per provider and model;
• the number of turns, and how each ended: completed, interrupted, stopped at the output cap or failed;
• the number of times a reply was continued after hitting the output cap;
• the number of times the free allowance was used up;
• errors, by kind: rate limit, server, timeout or other, and crashes found when a session was resumed;
• approvals asked, allowed, denied and timed out, per mode;
• tool calls, per built-in tool, with calls to MCP servers and skills as one count each;
• whether you used sub-agents, hooks, /undo, compaction or side questions, as counts;
• the sandbox setting of each session;
• active minutes: the time spent inside turns, not how long a session sat open;
• the harness versions and the platform: how many of that day's sessions you started on each version, and on each platform.

The counts include sessions on your own API keys while you are signed in, and, on the day you sign in, that day's sessions from before it. They never include a prompt, a reply, a file, a path, a command, error text, a session id, or any name you chose: your MCP servers, skills, hooks, agents and custom modes are counted, never named, and a custom provider or a model we do not know is sent as custom or other. The request carries your sign-in token and no install id, and the anonymous daily report (below) does not carry your account. Your upgrades are the one exception, recorded both ways: see "Install and upgrade events" below.

Our server stores the counts as counters per account per day. The request log shows the time, the route, the status, how long it took and your account id, never the body.

To stop them, set telemetry = false in config.toml, or set DO_NOT_TRACK in the environment to anything but empty or 0. check_for_updates = false stops them too, with everything else in the next section. harness logout stops them and deletes the file that tracks them; days spent signed out are never sent.

Update checks

A harness installed from a release checks whether a newer release exists when you start an interactive session, and every hour while it stays open. It is a plain read of the install site's /dl/latest, hosted on Vercel and stored on AWS: no body, no install id, no token, only a user agent of the form harness/0.25.0. They see your IP address, that user agent and the time, as for any download. When a newer release exists, the session says so. This happens whether or not you are signed in, and including when you use your own API keys. Builds from source, harness -p and harness eval never check.

check_for_updates = false in config.toml turns off the checks, the report and the events below: nothing is sent, and nothing is read or written, except that signing in or out empties any upgrade copy still waiting for your account in an existing events file. telemetry = false, or DO_NOT_TRACK in the environment set to anything but empty or 0, turns off the report and the events below and the usage counts above, and leaves the hourly check on.

The daily report

Once a day, when you start an interactive session, the harness also sends one request to our server, https://mega-server-or7tszhloq-du.a.run.app, with four fields: the harness version, the platform it was built for (such as x86_64-unknown-linux-musl), a random install id the harness makes on the first report and keeps in a file on your machine, and the number of interactive sessions started since the last report. It sends no API key, no prompt, no file name, no project path, no command, and no account id or email: it carries no sign-in token at all.

Our server sees those four fields and your IP address. It keeps daily and monthly counters (checks, sessions, versions, platforms and how many installs were active), which hold no id and no IP, and one record per install: the install id, the first and last day it was seen, its version and platform. That record is deleted about 400 days after the install was last seen. It also keeps one record for each day an install reported, and each version it reported that day: the install id, the day, the version and the platform, deleted about 400 days after that day. The server replies with the newest release number; if it does not answer with one (it is down, unreachable or cannot read it), the harness reads the install site's /dl/latest itself, as it does every hour.

Our server's own request log keeps the time, the route, the status and how long the request took, never the request body, so the install id is not in it. Google Cloud Run also logs each request's IP address, user agent, path and time, outside our code. Both are kept in Google Cloud Logging, whose default retention is 30 days (Google's documentation, read 23 October 2026). We have not confirmed Vercel's or AWS's retention.

harness update reads the release's checksum and signature and then the archive from the install site, where Vercel and AWS see it as they see an install; it checks the signature, made by the maintainer's release keys, before it downloads the archive. When the new version is in place, it sends the upgrade event below to our server. Deleting the install id file makes the next report a new install.

Install and upgrade events

Two more messages go to our server when the thing happens, not with the daily report. When the harness makes its install id, it sends an install event. When the version changes, it sends an upgrade event: after harness update has put a new version in place, and when a start finds a different version than the last one it ran (you ran the installer again or copied a binary by hand). Each carries the install id, the version before (an upgrade only) and the version now, the platform, and the time by your computer's clock. Like the daily report it carries no account id, email address or token, and the same switches stop it: check_for_updates = false, telemetry = false and DO_NOT_TRACK. An event that cannot be sent waits in a file on your machine, up to 32 for the install id and 32 for your account (below), and is sent at a later start or by a later harness update; one older than 30 days is dropped.

Our server keeps one record for each install and each version change: the install id, the version before (for an upgrade), the version now, the platform and the time, to the second. It also keeps the per-day record described above for the day of the event. Each is deleted about 400 days after that time. When a daily report names a different version than the last one the server stored, and either version is older than 0.26.0 (which sends no events, or has only just started its record), the server records the change itself, dated at that report.

If you are signed in and have seen the usage-counts notice above, each upgrade is also sent under your account, with your sign-in token and no install id: the previous and new version, the platform and the time. That record has no deletion date, and our request log shows your account id on that request, as it does on the usage counts. So the two records of one upgrade, the anonymous one and the account one, can be matched by their versions and time. The install id and your account id are never in the same request, but this is a way to link them, and we say so here.

Our code stores no IP address. But for 30 days Google's request log keeps each request's time and IP address, and the database stamps every record it writes to the microsecond, so during those 30 days a record can be tied to the address that sent it. That log is kept at Cloud Logging's default retention, 30 days, and is gone after it. The daily report's install record has been open to the same since version 0.24.0.

Age

You must be 18 or older to use the free models (Gemini's terms).

Contact and security

Questions, deletion requests and security reports: harness@megacode.ai.