Home/Legal/Data Retention Policy
Data Lifecycle

Data Retention Policy

The prompts and responses of your model requests pass through short-lived caches, and we keep request content longer only to fix failed requests and check routing quality. Everything we keep — from support chats to billing records — has a defined period. This is the authoritative schedule for how long data lives inside AirLLM.

Effective: October 23, 2026 Last updated: October 23, 2026 Version 1.2

At a glance — the plain-language version

Model requests: short-lived caches

Prompts and responses pass through short-lived caches that generally expire within 24 hours of last use. Failed requests (secrets removed) and samples of responses are kept until your account's data is deleted.

What we do keep

Usage metadata, failed-request records and engineering tickets, routing-quality samples, Alina support chats, AirCode session control records, and — only if a safety check is triggered — safety records.

No training by AirLLM

Our commitment: AirLLM never uses any prompt to train models, on any plan, and never sells your content. On the Free plan, model providers may use your prompts to train models and may retain them.

Closed accounts: 1 year

A closed account and its data are deleted 1 year after closure. Billing records and Terms-acceptance records are kept 7 years, and auto-renewal consent records 3 years.

01Purpose & scope

This Data Retention Policy defines how long JettySoft LTD, the company that provides AirLLM, keeps each category of data processed by the Services, why, and how it is disposed of. It applies to the Services — including the AirLLM platform, Air Router, AirGPU, AirCode CLI, AirCode Studio, and Alina — and to all environments where customer data may reside on our side, including caches, databases, logs, and backups. Data that AirCode CLI or AirCode Studio keeps on your own machine is under your control and outside this schedule. This policy supplements the Privacy Policy and forms part of the commitments in our Data Processing Addendum.

02Retention principles

  • Minimization. We keep the least data, for the shortest time, that still lets us run a reliable, safe, and billable service. Content is the most sensitive class of data we touch. AirLLM doesn't store prompts to train models: to run the service, request content passes through short-lived, account-scoped caches that expire automatically, generally within 24 hours of last use, and we keep it longer only in the failed-request records, engineering tickets, and routing-quality samples listed in Section 3.
  • Purpose limitation. Every retention period below is tied to a specific purpose. When the purpose ends, so does the retention.
  • Separation of content and metadata. Long-lived records (billing, usage metadata) contain no content. Where we do keep content — failed-request records, engineering tickets, routing-quality samples, Alina support chats, instructions administrators type into AirCode sessions, and safety records — we keep it only for the purpose and period in Section 3. Caches that may briefly hold content exist only to serve your requests faster and at lower cost. None of it is ever used for training or sold.
  • Automated disposal. Deletion with a fixed period is enforced by automatic expiry and scheduled jobs, not manual processes — expiry is the default behavior. Records kept only "as long as needed" (engineering tickets, support communications, Alina support chats, and the operator audit log) are deleted when that need ends. Retention beyond the schedule requires an explicit legal or safety hold.
  • Defense in depth. Retained data is protected by the safeguards described in our Privacy Policy, including access controls. Stored data may be encrypted at rest where our hosting providers support it. Deleted data may remain in backups for a limited time until they're overwritten in the normal cycle.

03Retention schedule

The table below is the authoritative schedule. Where a shorter contractual commitment exists (for example an enterprise ZDR agreement), the shorter period wins.

Data categoryWhat it containsRetention periodDisposal
Model-request contentThe prompts and responses of requests sent through Air Router or the AirLLM API, including the model calls AirCode makes. AirLLM doesn't store prompts to train modelsOnly in the caches and records belowPasses through the short-lived caches to serve the request
Short-lived cachesRequest data held briefly, scoped to your account, to run the service and serve your requests faster and at lower costGenerally within 24 hours of last useAutomatic expiry; never used for training, never sold
Failed-request recordsThe content of a request that failed, with secrets removed, kept with its usage record to diagnose the failureDeleted with your account's dataDeleted when the account is deleted, 1 year after closure; never used for training
Engineering ticketsThe content of a failing request, with secrets removed, attached to a ticket in our engineering issue tracker (Microsoft Azure DevOps) so we can fix the problem, and problem reports you send us from AirCode CLI or AirCode StudioAs long as needed to diagnose and fix the problemDeleted when no longer needed for that purpose, not with your account's data; access limited to our engineering staff; never used for training or sold
Routing-quality samplesSamples of responses kept to check that requests were routed to a suitable modelDeleted with your account's dataDeleted when the account is deleted, 1 year after closure; never used for training
AirCode session transcriptsThe live transcript of an AirCode session shown in the Control Plane, relayed from your machineNot storedHeld for at most about a minute to deliver it
AirCode session instructions
& control records
Instructions an administrator types into a session from the Control Plane, and session control records (pause, resume, end), kept with the session's recordsDeleted 1 year after account closureDeleted with account data
Alina support chatsYour question and Alina's answer, with the page you were on and, when you're signed in, your account ID — kept to answer you, investigate problems, and improve our support answers and documentation (never for model training)Until no longer needed for supportDeleted when no longer needed, and on request; the open conversation in your browser lasts only for the browser session
Usage metadataTimestamps, model used, token counts, cost, latency, and error codes — no content13 monthsAutomated deletion, then aggregate-only
Service-quality metricsMetrics derived from usage metadata, without content, used to improve the Services12 monthsAggregate expiry
Usage & billing recordsToken counts, costs, invoices, payment records (no content)7 years from the invoice dateDeletion after statutory period, even after the account is deleted
Billing noticesPayment-failed notices and reminders, service-paused notices, and annual renewal reminders: when each was sent, who it went to, and the invoice or plans it covered (no content)7 years, with billing recordsKept with billing records, even after the account is deleted
Auto-renewal & auto-recharge consent recordsWhen you buy or change a paid plan, turn a paid key back on, or turn on or change auto-recharge on the Token plan: the plan and price (or the recharge amount and threshold), the terms you agreed to, when you agreed, and the IP address and browser details you agreed from3 years from consentKept even after the account is deleted, then removed by the daily deletion job
Terms-acceptance recordsWhen you create an account — by signing up, accepting an invitation, or first signing in with Google or single sign-on: the versions of the Terms and Privacy Policy you accepted, how you signed up, when you accepted, and the IP address and browser details you accepted from7 years from acceptanceKept even after the account is deleted, then removed by the daily deletion job
Account dataProfile, workspace settings, hashed credentials, API-key hashes, and the other data of a closed accountDeleted 1 year after account closureDaily deletion job
Support communicationsTickets, contact-form messages, chat transcripts with our team, email threadsAs long as needed to handle your request, and for legal defenseDeleted when no longer needed for those purposes, not on a fixed schedule; access limited to the staff who handle them; never used for training or sold
Security & audit logsAuthentication events, actions by your account's administrators, security telemetry12 monthsAutomated deletion
Operator audit logAdministrative actions AirLLM staff take in AirLLM's internal administration console, each logged with the operator's name; an entry may identify the account an action concernedAs long as needed for security and legal defenseDeleted when no longer needed for security and legal defense
BackupsCopies of our databases, where backups are madeA limited timeOverwritten in the normal backup cycle
Safety recordsRecords kept if a safety guardrail or an Acceptable Use review is triggered — which may include the text that triggered it — together with related account details, usage metadata, and material reported to us, kept only for enforcement and legal defenseUp to 2 yearsDeletion after enforcement need ends
Website analytics
(only if you accept)
Pages viewed, approximate location, device and browser details, and site actions, collected by Google Analytics with a random browser ID — no content, no names or emailsUp to 14 monthsAutomatic expiry in Google Analytics; decline anytime under Cookie settings
Data on your deviceHistory, settings, and project files that AirCode CLI and AirCode Studio keep on your machineUnder your controlYou decide; outside this schedule

Periods start when the data is created (for logs and metadata) or when the triggering event occurs (account closure, acceptance or consent, the safety event or review). Cache entries expire automatically, generally within 24 hours of last use.

04Content handling & ZDR agreements

On every plan, AirLLM doesn't store prompts to train models. To run the service, request content passes through short-lived, account-scoped caches that expire automatically — generally within 24 hours of last use. When a request fails, we may keep its content, with secrets removed, to diagnose the failure, and we may keep samples of responses to check routing quality; these records are deleted with your account's data. The content of a failing request, with secrets removed, may also be attached to a ticket in our engineering issue tracker, where it is kept only as long as needed to diagnose and fix the problem, with access limited to our engineering staff. None of these records is used for training or sold. We also retain usage metadata without content (timestamps, token counts, model used), because it is required for billing and abuse prevention, plus the other records listed in Section 3: AirCode session instructions and control records, Alina support chats, and safety records.

Organizations with heightened confidentiality requirements can ask about a separately negotiated Zero Data Retention (ZDR) agreement, which may, for example:

  • set out how caching applies to your traffic; and
  • ask the upstream model providers that serve your traffic for zero-retention handling where they offer it — whether a provider grants it is governed by that provider's own terms.

Any such commitment applies only as written in a signed agreement. Contact sales or your account manager to discuss one.

05Upstream provider retention

AirLLM acts as an intermediary: to generate a completion, request content is transmitted to the third-party model provider that serves it, or to third-party GPU capacity when AirGPU falls back to it. AirLLM itself keeps that content only as described in Sections 2–4. Each provider is an independent third party that processes, and may store, retain, log, or use, API data under its own terms and privacy policy — including for its own abuse monitoring and any model training it carries out under those terms. To the maximum extent permitted by law, AirLLM does not control and is not responsible or liable for a provider's storage, retention, use, or disclosure of data, or for its availability, outputs, or security.

  • Your plan. Model providers may retain prompts under their own policies, for example to monitor for abuse. On paid plans, AirLLM avoids model providers that use prompts to train models. On the Free plan, model providers may use your prompts to train models and may retain them.
  • Where your organization uses a tenant-scoped provider key, upstream calls run under your own provider relationship, and your organization's data-handling preferences with that provider apply to your traffic.
  • We list the providers we route to in the subprocessor table of our DPA; each provider's own terms and privacy policy govern its handling of data.

06Deletion & account closure

  • Export first. Export anything you need before you close your account or workspace — after closure, data may no longer be available to export.
  • Closing an account. An Enterprise Admin closes the account in the dashboard under Settings → Close Account, after paying any outstanding balance. Closing cancels every plan and API key immediately, nothing is charged again, everyone on the account is signed out, and remaining prepaid credit isn't refunded.
  • Deletion 1 year after closure. A daily job deletes a closed account and its data 1 year after closure, except billing records (kept 7 years from the invoice date, with the billing notices sent about them), Terms-acceptance records (kept 7 years from acceptance), and auto-renewal and auto-recharge consent records (kept 3 years from when consent was given), which the same job deletes when their periods end. Deleted data may remain in backups for a limited time until they're overwritten in the normal cycle. Engineering tickets aren't part of this deletion: they are kept only as long as needed to diagnose and fix the problem (Section 3). Contact-form messages and email threads with our team are kept only as long as needed to handle the request and for legal defense (Section 3). Where the law gives you the right to earlier deletion, ask our Legal Cell at legal@airllm.ai.
  • In-product deletion. Where the Services let you delete items in-product (for example API keys or workspace settings), they're removed from your account. Copies may remain in our systems and in backups until they're deleted in the normal course, and at the latest when your account's data is deleted (see above).
  • Alina support chats. We delete support chats when they are no longer needed for support. To have yours deleted sooner, ask our Legal Cell at legal@airllm.ai.
  • Verified requests. Data-subject deletion requests under GDPR, CCPA, or similar laws go to our Legal Cell at legal@airllm.ai (or through our Contact page) and are handled per the Privacy Policy; we may need to verify your identity first.
  • Exceptions. We retain data past these windows only where required for legal compliance or to establish or defend legal claims (for example billing records, kept 7 years, Terms-acceptance records, kept 7 years, and auto-renewal and auto-recharge consent records, kept 3 years), to resolve an active dispute, or under a hold described in Section 7 — and only the minimum data needed.

07Legal & safety holds

Deletion clocks pause when data is subject to a legal hold (litigation, subpoena, regulatory investigation) or a safety hold (an active trust-and-safety investigation into a suspected Acceptable Use Policy violation). Holds are scoped to the specific data at issue, documented with an owner and review date, and released — with normal deletion resuming — as soon as the underlying need ends.

08Governance & review

This policy is owned by our Legal Cell and reviewed at least annually, and whenever we launch a product or system that introduces a new category of data. Material changes are announced with the same notice commitments as the Privacy Policy. Questions can be sent to our Legal Cell at legal@airllm.ai or through our Contact page.