beta sevenk.ai runs in beta, and that covers this document too: prices and terms change as capacity grows. The version block below states what is in force today.
Service Policy
Version 1.1 · Effective 2 October 2026 · Owner: the operator of sevenk.ai
This policy explains what sevenk.ai is, how it is operated and, most importantly, what it does not do with your data. It is written to be read rather than to impress: where a number or a commitment appears it is an operational fact, and where something is weak or uncertain it says so. Two commitments shape everything below: privacy by design, and honest disclosure of what the models can and cannot do.
1. What the Service Is
sevenk.ai is an inference service for open-weight language models. It speaks the OpenAI API, serves every paying seat the same models at the same speed, and charges one flat fee per seat per month with no per-token metering (the pricing page has the details). It exists for people and agents who value low latency and predictable cost over frontier-model quality.
2. How the Service Runs
sevenk.ai runs today as a single deployment in one location, operated by one person. There is no failover target and no battery backup yet, so power interruptions, network faults and hardware failures stop the service immediately; it returns when the operator brings it back. That is shrinking stage by stage: the roadmap (SLA §9) adds battery backup and further serving nodes, and each addition makes more of the service available and retires one point of failure. Maintenance runs most nights in a scheduled window of up to four hours starting at 9:00 PM US Eastern, which the SLA accounts for exactly.
That is a deliberate trade for now, and the roadmap unwinds it in the right order. While the hardware grows, you already get a service that has never kept a copy of your prompts, pricing that does not change with your usage, and interactive decode speeds that large shared platforms rarely offer an individual seat.
3. Zero Retention
The service retains no request data. No prompts, no completions, no attachments, no transcripts.
3.1 What is not recorded
Prompt and message content, including system prompts, is not stored. Completions and streamed output are not stored. Uploaded files and images are not stored. And no per-request metadata (timestamps, headers, token counts) is ever joined to user content, because there is no content to join it to.
3.2 Enforced by design, not by a deletion schedule
This is not a retention promise backed by a purge job. Request data is processed in memory and the request path never writes it to non-volatile media: buffers are released as soon as a response completes, anything still in memory is destroyed by a restart or a power loss, and there is no request-logging pipeline, no debug mode, and no archive. A deletion promise depends on someone remembering to delete; a design that never writes the data does not.
3.3 What remains in flight
While a request is in flight the gateway holds in memory only what it needs to deliver that request (the connection and the tokens) plus anonymous operational counters such as concurrency, queue depth, and aggregate tokens per second. Those counters are never persisted and never associated with any user or any content.
3.4 Account data
Billing needs a few facts, and those are stored: the seat list, API key hashes, plan status, and invoices. A key hash authorizes requests; it is never joined to request content, because none exists. A submission through the key-request form (a name and an email address) is kept until the key it asks for has been issued.
3.5 What zero retention means for you
We cannot recover an output you failed to save, so keep your work client-side. We cannot investigate a past incident with request data, so incident reports describe system state only. A breach of our storage cannot expose your conversations, because they were never on it. And we cannot offer per-user usage analytics beyond the live anonymous counters, a limitation we gloriously accept.
4. The Models, Honestly
The served models are open-weight, and the lineup changes as capacity and the models themselves improve; whatever the landing page and GET /models show at the moment you connect is what you get. We do not pin a model version as a contractual commitment, and quantization or serving parameters may change with upgrades.
We will not pretend the models are frontier-class. They are not, and that is not the bargain. They answer at interactive speed, and they never keep your data. Use sevenk.ai when latency, cost and privacy matter more than peak reasoning power; look elsewhere when you need frontier quality.
Vision input is offered as an experimental flag with no availability or quality commitment: its day-to-day status is not verified. Assume text for anything you depend on. If the experimental parts are broken, we will leave them flagged rather than imply support we cannot verify.
5. Acceptable Use
You are responsible for what you send through the service. Three categories are prohibited outright: content that is unlawful, including material for CSAM, non-consensual intimate imagery, or targeted harassment; attempts to defeat the zero-retention design, such as pressing the operator to log or mirror traffic; and attempts to take more than a seat's share, such as deriving other tenants' keys or running denial-of-service load beyond the fair-use allowance in Pricing §4.
Because nothing is retained, we generally cannot moderate, review, or police content, and we do not try to. Enforcement is limited to suspending the seat. Legal claims about your own inputs and outputs are handled on the shared acknowledgment that no evidence of the exchange exists on our side.
6. Security Posture
The attack surface is small by construction: one deployment, one gateway, and no store of request data for an attacker to aim at. The API key is the only credential on the public surface: treat it like a bearer password. The realistic worst-case breach is service interruption rather than data disclosure, because what a conventional breach exfiltrates simply does not exist here; request content lives in memory only while its request is in flight, and a power cut ends it.
7. Liability
The service is provided as is. Availability and performance are governed by the SLA, and total liability is capped at the fees you paid in the trailing month. We are not liable for outputs you failed to save (we could not restore them, per §3), for lost revenue during outages, or for the quality of model output.
8. Changes to This Policy
Material changes, above all anything touching §3, are announced at least 30 days in advance. The zero-retention claim is load-bearing for this service: if request logging is ever introduced for any reason, this policy is rewritten, the change is disclosed before it takes effect, and the zero-retention promise is retired with it rather than quietly softened.