What we collect, and why.

Who we are.

Carthagent is operated by an individual developer (“we”, “us”). For anything in this policy, including access, correction, or deletion requests, email [email protected]. We aim to reply within 30 days.

The harness source code is public at github.com/B-icy/Carthagent; the website and the Cloud control plane are at github.com/B-icy/Carthagent-Backend. Where this policy and the code disagree, tell us and we will fix one of them.

The harness on your machine.

The ctg command-line tool runs locally. Your project files, acceptance contracts, check results, and evidence stay in your project folder and under ~/.carthagent/ on your computer unless you explicitly send selected content through a network feature described below. Using the tool does not upload your whole project to us.

The harness talks to the network for these features:

• The model provider you chose. If you connect your own provider (Anthropic, OpenAI, OpenRouter, or another), prompts go directly from your machine to that provider under their terms. We are not in that path and do not see the traffic.
• Carthagent Cloud, if you chose it. See the Cloud sections below.
• Voyages, when you explicitly use an authenticated client. Ordinary character, equipment and coin requests do not send project files or require a paid Cloud plan. Daily-quest assessment, if enabled, accepts only evidence you explicitly select and consent to send, as described below.
• Update checks. Once a day, and when you run ctg update, the harness asks api.carthagent.xyz (falling back to GitHub) which version is current. This request carries no account or project information.

This website.

Public pages on carthagent.xyz use no third-party analytics, advertising, or tracking scripts. Fonts and images are served from our own domain. Account features communicate with our API host using the sign-in cookies described below.

We run a small first-party measurement on the landing, install, Cloud, and workflow comparison pages. When scripts are enabled, your browser sends us the page path, the event (page view, a button click, how far you scrolled), the referring site's hostname, and any utm_ campaign tags in the URL. On the server we derive a visitor identifier by hashing your IP address and browser user agent together with a secret and the current date. The raw IP address and user agent are not stored; the hash changes every day, so visits on different days cannot be joined. We also record a two-letter country code supplied by our edge provider. Known crawlers are discarded. This data is kept for 180 days and is used only to understand how the site is used.

If you are signed in to Cloud, the public pages ask api.carthagent.xyz whether you have a session so the “Account” link can point to the right place. That request carries your session cookie to our own API host only.

Cloud accounts.

Cloud is optional. You only have a Cloud account if you signed in on api.carthagent.xyz. When you do, we hold:

• Your email address, which is the account identifier. It arrives either from the one-time sign-in link you requested, or from Google if you chose “Continue with Google”. With Google we receive your Google account ID and your email address with Google's verification status. We request nothing else from Google and do not receive your contacts, calendar, or files.
• Sessions. Hashes of browser session tokens and CLI refresh tokens, when they were created and last used, and the name of the client that holds them. New device approvals and CLI sessions retain the approving sign-in user's identifier and granted permissions so private Voyages data is returned to the correct user, not an inferred account member. Devices authorised from the command line are listed on your account page, where you can revoke them.
• Billing records. Your Stripe customer and subscription identifiers, plan, status, billing period dates, reviewed plan-change quotes and payment-recovery references, plus a ledger of credit granted, reserved, and settled in integer fractions of a dollar. We never see or store your card number; Stripe does. The one-time $1 starter usage credit on terminal authorization is limited per account and per IP address, so we retain the claiming IP for that purpose. This is separate from Builder’s paid introductory month.
• Usage metadata. For each hosted model request: the model alias, timestamps, HTTP status, an error code if any, latency, token counts, the resulting charge, your CLI version and operating system, and an installation identifier the CLI generates. This is what the account page shows as “recent requests”.
• Security records. Expired sign-in links are deleted on the next write. Rate-limit counters are keyed by IP address and roll off within an hour. Sign-in attempts and device approvals are logged as events without content.
• Onboarding measurements. Account-linked timestamps distinguish terminal connection, starter-credit outcomes, first successful model response, first explicitly claimed verified delivery, checkout completion and confirmed payment. We use these to report signup cohorts and time to first claimed delivery or next response after payment. A model response is not a completed task. These events contain no prompts, responses, credentials or source text.

Voyages.

When you explicitly claim a verified-delivery reward from a compatible terminal client, we receive a hashed project identifier, run identifier, source snapshot digest and check/review digests. No source code, command output, local paths or prompts are included in this claim. We retain an account-linked reward receipt, evidence fingerprint, policy version, award amounts and dates for the beta/account lifetime to prevent duplicate awards and maintain your balance and progression. These records are private, are not sent to the quest classifier, and are included in manual account export/deletion and backup handling described below.

Voyages uses the same sign-in identity as Cloud but does not require a paid subscription. Opening the signed-in editor or initializing an authorized client creates a private player record linked to that identity. We store your chosen character and ship names, appearance, owned equipment, equipped items, starting coin grant, balance, and purchase receipts in a separate PostgreSQL database. We also retain the original account creation time and version counters used to prevent conflicting saves. These records contain no source code or prompts.

Your wallet, inventory and personal quests are private to your authenticated account. Quests store the title, kind, completion state and dates you choose to record. They do not send code to us or verify coding activity. Account-anniversary badges use your original sign-up date; we store earned dates and your pinned selection. There is no connected GitHub activity, public profile directory, chat or friend graph.

Daily-quest assessment is a separate, default-off backend preparation as of October 26, 2026, not a claim that it is available in the website or terminal. If enabled, it offers three curated daily coding quests and accepts selected evidence only with your explicit consent for each submission. Evidence can include a goal and change summary, revision and local project/run/outcome identifiers, selected check results and review findings. It is limited to 12 KiB, not a whole-project upload. We send the selected revision, goal, change, checks and findings to the configured external JEV classifier to assess the quest; local project/run/outcome identifiers are not sent to it. An assessment is not independent verification and earns no coins, XP, distance or badges.

A submitting client must let you preview the exact evidence, remove sensitive material and confirm the external processing before sending. That terminal interface is not implemented in this backend slice. We do not promise automatic secret detection or redaction. Do not submit credentials, personal data or confidential code you are not authorised to share. The external provider's own policy governs its processing and retention; ask us about the configured provider and its terms before deciding to submit.

For enabled daily assessments, raw selected evidence is kept pending processing for at most 24 hours and erased when assessment reaches a terminal result, including terminal failure. Daily assignment and submission metadata is retained for 90 days: identifiers needed to prevent duplicate claims, consent, frozen criteria, status, scores, model/rubric versions, attempts and dates. Cleanup runs in bounded batches; outages can delay physical cleanup and require operator recovery. Private API reads do not return raw evidence, and we do not log it. Operational monitoring uses queue age, worker heartbeat, retries and provider latency, not individual productivity scores. Restricted backups may retain deleted data until their policy rotation completes; restored data must have expiry cleanup and deletion requests reapplied before use. This does not promise deletion of copies already processed by the external provider.

Crews are optional, invite-only groups. Choosing a handle lets existing players invite that exact handle; it does not create a searchable directory. We store crew names, roles, membership, invitations and their outcomes, removal bans, blocks and minimal crew-action records. An invitation recipient sees the crew name and inviter's character name and handle. After accepting, current members can see each other's character name, handle, ship name, appearance and role. Crew owners and admins can also see pending invitations and removed members. They cannot see your email address, source identity, wallet, inventory or private quests. Leaving or being removed ends roster access; members may already have seen or copied information you shared.

Invitations expire after seven days. Blocking prevents invitations between you and that player and cancels pending invitations between you; it does not remove either of you from an existing shared crew. Declining, revoking or unblocking does not automatically restore an invitation. Crew action records support authorization and abuse investigation and contain action identifiers, actor/target references and timestamps, not quest text or source code. Contact us about abuse or data requests using the address above.

The editor, coin shop and crew flows require JavaScript. Session cookies remain on the API host; the browser holds a session-bound request-verification token in memory. When a purchase result is uncertain, session storage holds only its quote and retry identifiers so reloading can retry the same operation without buying twice. It does not hold sign-in credentials.

An authorized terminal client uses its own scoped access and refresh credentials obtained through explicit browser device approval, not copied browser cookies. Its requests access the same saved player and coin records. Revoking that CLI session prevents further access; an old account-only session must sign in again before it can use Voyages.

Player data, personal work-log quests, badges, coin records and crew history remain while you use the beta; daily-assessment records have the shorter periods above. Crew action records keep the latest 1,000 actions per actor; expired invitation history has no timed purge in this release. To request export, correction, or deletion, contact us from your account email. Deletion is manual: the operator removes or anonymizes your private profile, inventory and linked coin, crew and daily-assessment records, resolving any crew ownership first. Coin history is not part of Cloud billing and is not retained as a tax record. Restricted backups may retain deleted data until their rotation completes; restored data must have deletion requests reapplied before it is served. Debugging grants are restricted to designated test users and are recorded, not public minting controls.

Prompts, code, and model output.

When you use Cloud, the harness sends your prompt, the relevant parts of your code, and tool definitions to api.carthagent.xyz, which forwards them to an upstream model provider and streams the answer back. We do not store prompt or response bodies. The gateway counts bytes to estimate tokens without interpreting the content, holds a credit reservation, forwards the request, and records only the metadata listed above. Our financial ledger refuses to accept any field whose name suggests content.

The upstream provider receives the content in order to generate a response, and its own policy governs what it does with that content. We route under our own API credentials, so the provider does not learn your identity from the request. We do not currently publish the provider list because it changes; ask us if it matters to your decision.

If you need control over where prompts are sent, connect your own provider instead of Cloud and check that provider’s data policy. That path is permanently available and carries no upsell.

Who receives data.

We do not sell personal data and do not share it for advertising. We use these services to operate the hosted features:

• Stripe for payments. Stripe receives your email address and payment details and sends us billing events. Stripe's privacy policy applies to what you give Stripe.
• Google if you sign in with Google. Google tells you what it shares with us on its consent screen.
• An email delivery provider to send sign-in links. It receives your email address and the link.
• Upstream model providers for hosted model requests, as described above.
• The configured external JEV classifier, if daily-quest grading is enabled and you explicitly consent to a submission. It receives the selected evidence and assessment questions, not an automatic upload of your whole project. Its own policy governs its copies; ask us for the configured recipient and terms before submitting.
• Cloudflare and Oracle Cloud as our network edge and hosting. They process traffic in transit and provide the country code mentioned above.
• GitHub for the harness repository and release downloads. We also read our own repository's aggregate traffic statistics from GitHub; those are repository totals, not visitor records.

We will disclose data if the law requires it, or to protect the service against abuse or fraud. We will tell you if we are allowed to.

How long we keep it.

• Website measurements and per-request usage metadata: 180 days, pruned automatically every hour.
• Enabled Voyages daily assessments: selected raw evidence for at most 24 hours pending processing, erased on terminal assessment or failure; daily metadata for 90 days, pruned in bounded batches. See the Voyages section for outage, backup and external-provider limits.
• Expired sign-in links: deleted on the next sign-in request. Revoked and expired sessions: kept as revoked until you ask us to remove them.
• Account, identity, and billing ledger records: for as long as the account exists, then as long as tax and payment-dispute rules require (typically up to seven years for financial records).
• Account creation, first hosted response and first claimed verified-delivery markers retain their account identifier and timestamp for account history and deduplication; they are not anonymous counts. Other onboarding events are pruned after 180 days. Account export/deletion also covers these markers.

Your rights.

You can see most of your data on your account page, revoke any session there, and cancel your subscription through the Stripe customer portal linked from the same page. Logging out ends only the current browser session; connected CLI devices stay connected until revoked.

To get a copy of your data, correct it, or delete your account, email [email protected] from the address on the account. Deletion is handled by hand today. We will remove your email, identities, and sessions and detach the usage metadata; ledger entries required for tax or dispute purposes are kept in a form that no longer identifies you. Self-service deletion is planned and will replace this paragraph when it ships.

If you are in the European Economic Area, the United Kingdom, or a jurisdiction with similar law, these are the rights of access, rectification, erasure, restriction, portability, and objection, and you may complain to your local supervisory authority. Our basis for processing is performance of the contract with you for Cloud, and our legitimate interest in operating a secure service and understanding how the website is used. If you are in California, we do not sell or share personal information as those terms are defined there.

Optional daily-quest evidence processing requires your explicit consent for each submission. You can decline to submit without losing ordinary Voyages access. Contact us to request deletion or withdraw consent for pending processing; this manual request cannot undo processing already completed by the external provider.

Cloud is not directed at children under 16 and we do not knowingly collect their data.