§ 0 The short version
Halton Meter Cloud is operated by Halton Labs Ltd (England & Wales). It is the hosted dashboard for the Halton Meter daemon — a local network proxy that observes outbound LLM API traffic on your developers' machines, computes cost, and syncs the result to your workspace.
By default we only receive metadata about your LLM calls — provider, model, token counts, computed cost in USD, project attribution, timestamp, latency. Not prompts. Not responses. Not API keys.
If — and only if — a workspace owner turns on the
store_prompt_content setting, the daemon
additionally sends prompt and response bodies to the Cloud, where
they are stored encrypted at rest in AWS London (eu-west-2). This
is off by default. See § 2a for what this changes.
You bring your own LLM provider keys. Those keys live on your developers' machines and flow straight from your daemon to the provider (Anthropic, OpenAI, Google, Groq, and so on). We never see them.
- store prompt or response bodies unless you opt in
- see or store your LLM provider API keys, ever
- sell or rent your data to third parties
- use your data, metadata, or content to train models
- run ads or third-party tracking pixels
What this means in practice. If you never touch the content-storage switch, the only thing we know about your LLM calls is what they cost and how often you made them. If you turn it on, you're telling us to keep a copy of what was said — and you take on responsibility for the legal basis to do that.
§ 1 What we collect
Account data
When you create a workspace: your email address, a display name, and your chosen workspace identifier. Authentication is handled by our identity sub-processor (see § 5). If you add a paid plan, billing is handled by Clerk Inc. (Clerk Billing); Clerk uses Stripe upstream as the card-network processor. We receive a billing reference and plan state — not raw card numbers.
Usage metadata (the default flow)
The daemon on your developers' machines watches outbound LLM API traffic and computes, for each call, a small record containing: timestamp, provider, model, input and output token counts, computed cost in USD, project attribution (a label you control), developer identifier (a hash you control), and latency. This record — and only this record — is batched up to Halton Meter Cloud over TLS. Prompt bodies, response bodies, and API keys are stripped at the daemon and never leave the developer's machine in the default flow.
Prompt and response content (only if you turn it on)
A workspace owner can switch on store_prompt_content.
When that switch is on, the daemon additionally sends prompt and
response bodies to the Cloud, where they are stored encrypted at
rest. This is described in detail in § 2a. It is off by default and
can be turned off again at any time.
Service logs
Standard web-server logs for the Cloud API and dashboard: IP address, HTTP method, path, status code, response time. Retained for 30 days for debugging, security, and abuse prevention.
What this means in practice. The default record we hold about your LLM use is roughly the same shape as an itemised phone bill: who called what, how long, how much. It doesn't tell us what was said.
§ 2 What we do not collect by default
Prompt and response bodies (in the default flow)
Unless a workspace has enabled content storage (§ 2a), the daemon does not read, log, or transmit the text content of your prompts or your model's responses. It reads token counts and cost metadata from response headers and streaming chunks only.
API keys — ever
Your provider API keys (Anthropic, OpenAI, Google, Groq, and any future provider) pass through the daemon's local proxy in request headers on their way to the provider. The daemon does not extract, log, or transmit them, and the Cloud service does not make LLM API calls on your behalf. Your LLM provider relationship is yours, not ours. What you spend with Anthropic, OpenAI, Google or Groq is governed by your own contract with each provider; Halton Meter only measures it.
Tracking pixels, ad networks, model training
We do not run third-party advertising trackers on the Cloud dashboard. We do not share usage metadata or content with any third party for advertising purposes. We do not, and will not, use any data you give us — metadata, content, account data, or anything else — to train machine-learning models, whether our own or anyone else's.
What this means in practice. Two firm commitments and one honest qualifier. Firm: we never see your API keys and we never train on your data. Honest qualifier: "no prompts and responses" is only true while you keep the content-storage switch off — and it is off until you change it.
§ 2a Content storage opt-in
What turning it on changes
A workspace owner can switch store_prompt_content to
on from the workspace settings page in the Cloud
dashboard. Until that switch is flipped, this section describes
something that does not happen. Once it is on, for every LLM call
the daemon observes in that workspace, the following is added to
the metadata record described in § 1:
- the prompt body (the text and any structured input sent to the model);
- the response body (the text and any structured output returned by the model);
- request and response headers stripped of authentication credentials.
Where stored content lives
Stored content is held in Amazon Web Services in the London region (eu-west-2): in a PostgreSQL database (Amazon RDS) and, for larger payloads, in Amazon S3. Data at rest is encrypted with AES-256. Data in transit uses TLS 1.3 minimum. Content never leaves the United Kingdom in the ordinary course of operating the service.
Who can see stored content
Stored content is visible to members of your workspace who have
permission to view trace detail. To reduce accidental disclosure
between teammates, the Cloud dashboard wraps every reveal of a
stored prompt or response in a consent gate: the
viewer must record a short reason ("debugging incident #123",
"reviewing cost outlier", and so on) before the content is
unblurred. The reason is logged against the viewer's identity and
surfaced in the workspace audit log. This is enforced in the
dashboard code by a project-specific ESLint rule
(local/consent-gated-prompts) so it cannot be bypassed
by a UI mistake.
Retention
Stored content inherits the workspace's data-retention setting
(data_retention_days), which defaults to
365 days. After that window, stored content is
deleted from primary storage on a rolling basis. You can lower the
retention window in workspace settings; you can also raise it for
compliance reasons, subject to the upper limits described in the
Cloud Terms.
Turning it off, and what happens to content already stored
Switching store_prompt_content back to off
stops the daemon sending any new content from that moment forward.
Content that was stored while the switch was on remains subject to
the retention window until that window elapses, or until you ask us
to delete it sooner. You can request immediate deletion of stored
content at any time using the contact in § 8; we will action it
within 30 days and confirm completion in writing.
End-user content and the controller / processor chain
If your application talks to an LLM on behalf of your own end-users — for example, a chatbot users converse with — then turning on content storage means those end-users' inputs and the model's responses to them will be stored by Halton Meter Cloud. In data-protection terms:
- Your end-user is the data subject.
- You are the controller — you decide why and how your end-user's content is processed, including whether to send it to us.
- Halton Labs Ltd is a processor acting on your documented instructions under the Cloud DPA.
- Our own sub-processors (AWS in eu-west-2, our authentication and billing providers — see § 5) are sub-processors to that relationship.
- The LLM providers you use (Anthropic, OpenAI, Google, Groq, and the rest) are your processors under your direct contracts with them. The daemon sits between you and them; it is not a relay we operate, and they are not our sub-processors in that path. They are listed in our sub-processor register only for transparency about the wider data flow.
You are responsible for having a lawful basis to send your end-users' content to us in the first place (consent, contract performance, legitimate interests appropriately balanced — your call, your record-keeping). Our Cloud DPA documents the processor-side commitments that flow from that.
For Team and Business+ customers, the operational Processor obligations are set out in our Data Processing Addendum.
What this means in practice. Content storage is a power tool. It is genuinely useful for debugging, prompt engineering, and audit — and genuinely riskier than the default flow. We have built reveal-with-reason and a default 365-day retention into the product so the risk is visible while you use it. Your job: only turn it on if you can lawfully store what will land in it. Our job: handle what lands in it the way this policy says.
§ 3 How we use your data
To operate the service
We use account data to authenticate you, manage your workspace, and send transactional email (password resets, billing receipts, service notices). We use usage metadata to generate the reports, dashboards, and reconciliation views that are the product.
We do not use your data to train models
Cost metadata synced to the Cloud is never used to train machine learning models, whether by Halton Labs or any third party we engage.
§ 4 Storage and retention
Where data is stored
The Cloud service runs in AWS eu-west-2 (London). Data at rest is encrypted with AES-256. Data in transit uses TLS 1.3 minimum.
Retention
Usage metadata is retained for the duration of your subscription plus 90 days. After account deletion or subscription cancellation, all usage metadata is deleted within 90 days. Account data (email, billing reference) is retained for up to 7 years for legal and accounting obligations, then deleted.
Enterprise customers on self-hosted deployments control retention entirely — data lives in their own infrastructure.
§ 5 Third parties
Sub-processors
We use a small set of sub-processors to run the service. Each one is named below, with the role it plays and the data it sees. We do not share usage metadata with any of them beyond what is technically necessary to deliver the service.
- Amazon Web Services (eu-west-2, London) — primary hosting, database (RDS PostgreSQL), and object storage (S3) for all Cloud workspace data. Halton Labs is the data controller; AWS acts as a processor under the AWS GDPR Data Processing Addendum.
- Clerk Inc. — authentication (sign-in, sign-up, session management) and billing (subscription management, checkout). Clerk holds your account email, display name, and billing reference. Clerk uses Stripe upstream as the card-network processor; raw card numbers go directly from your browser to Stripe via Clerk's hosted billing interface — they do not pass through, or get stored by, Halton Meter Cloud.
- Svix — webhook delivery for events emitted by Clerk (e.g. subscription state changes). Svix sees event payloads that may include account identifiers and plan metadata, but no usage metadata or prompt content.
- Postmark — transactional email (account verification, billing receipts, security notices). Postmark sees the recipient address and the email body.
A current, dated sub-processor list is published at cloud.haltonmeter.com/sub-processors. Material additions are announced to workspace owners with at least 14 days' notice before the new sub-processor begins receiving customer data.
What this means in practice. Your card number only ever touches Stripe (via Clerk's hosted UI). Your account email touches Clerk and Postmark. Your usage metadata and any stored prompt content (§ 2a) stays inside AWS eu-west-2 unless you explicitly export it. None of these companies are permitted to use your data for their own purposes.
We do not sell, rent, or trade your data to any third party for advertising or any other purpose.
§ 6 Your rights
Access, export, deletion
You can export all usage metadata from the Cloud dashboard at any time in CSV or JSON format. To delete your account and all associated data, email operator@haltonlabs.com with your workspace identifier. We will confirm deletion within 5 business days and complete it within 30.
If you are in the UK or EEA, you have the right to access, rectify, port, restrict processing of, and erase your personal data. Contact us at the address below.
§ 7 Changes to this policy
Material changes get a date bump
Material changes to this policy will be emailed to workspace owners at least 14 days before taking effect, and reflected in the effective date above. Continued use after that date constitutes acceptance.
§ 8 Contact