Privacy Policy

Last updated: November 11, 2026

1. Overview

This policy explains what information Tempr Software LLC ("Tempr," "we," "us") collects, why we collect it, and the choices you have. It covers Tempr's extensions for Visual Studio, VS Code, and JetBrains IDEs, the Tempr CLI, the Tempr Gateway API, the customer portal at portal.temprhq.io, and this website, temprhq.io (together, the "Service").

Tempr is a bring-your-own-key (BYOK) product. Every AI request you make through the Service goes through our servers to the provider you choose, using your own API key. Your keys are never pooled or shared with other customers.

2. Information we collect

• Account and sign-in data: your email address, an optional username, a hashed password, and your two-factor authentication settings (authenticator secrets are stored encrypted). We also keep your license key, plan, and subscription status, and a record of each sign-in to the portal: the time, the IP address, whether it succeeded, and the method used. We work out the approximate location of that IP address on our own servers, from a copy of the free DB-IP Lite database, so the address isn't sent to anyone for this. We also include the IP address in the new-sign-in alert emails we send you. The apps sign in with your license key, or through your browser, where you approve the app on the portal; for each sign-in we store a hashed token, not your device's name or any hardware identifier. A browser sign-in waiting for approval is stored as a code, a hash of the app's secret, the name the app gives itself, and when it was requested.
• Provider API keys and credentials: the keys you add in the portal for the AI providers you use, and any credentials for your own model endpoints ("custom models") or for MCP servers you store in Tempr. They're stored encrypted on our servers, not in the apps. We use provider keys to relay your requests, to check that a key works when you add it, and to list the models it gives you access to.
• Credentials sent with a Gateway request: with plan logins on (the default for personal accounts; organizations turn it on themselves), an app such as Claude Code or Codex can send its own credential with a Gateway request instead of using a key you stored: a Claude or ChatGPT sign-in, a coding plan's key, or a provider API key. We pass it to the provider it belongs to for that one request, and never store it or write it to a log. The request's log records that your own credential was used, which plan paid, what the request would have cost at API prices, and the usage figures the plan sends back, such as how much of its 5-hour or weekly allowance is used and when that resets.
• MCP server sign-ins: when you sign in to a remote MCP server through Tempr with your own account (OAuth), we store the access and refresh tokens the server's sign-in gives us, encrypted on our servers, and the account name it reports, which you and your organization's admins see next to the sign-in. We use the tokens only to relay your own tool calls to that server and to renew them when they expire. We delete them, and ask the server to revoke them where it supports that, when you sign out, an admin revokes them, you leave the organization whose server it is, or you close your account. We also keep the name, description and input schema of each tool a server lists, so a change to a tool can be flagged to you or your admins.
• Apps connected to your MCP servers: when you sign an app such as claude.ai, ChatGPT or Claude Desktop in to your MCP servers through Tempr, we keep a record of that grant: the app's name and the address it returns to, the organization it's for, when you connected it and when it was last used. You see it under Connected apps, and so do your organization's owners and admins for its servers. For each token we issue the app we keep its type, when it was issued and expires, and whether it has been used or revoked, not the token itself; a record is deleted once its token has expired or been used or revoked and it's two weeks old. To show you which app is asking, we fetch the details the app publishes about itself from its own website, or keep the name and return addresses an app gives when it registers itself; an app's record that no one is signed in with is deleted a day after those details expire, or 30 days after a self-registered app registered. If your organization uses Enterprise Managed Auth, we read its identity provider's public signing keys, and keep the ID of each sign-in assertion the provider issued until it expires, so it can't be used twice. A grant lasts until you or an admin disconnect the app, you leave the organization, the organization closes, or you close your account. You can also connect an app, or give a management key, to the Gateway's own MCP server: it can then read your Gateway's usage, request logs (with the session IDs, end-user IDs and metadata your apps sent) and, when it asks for them, a request's captured content with secrets and personal data masked. What it reads goes to that app, and to the AI model the app uses, under the app's own terms. For an organization, an app reads its Gateway only for an owner or admin, and each read of captured content is recorded in its audit log. If you let an app or a management key make changes, it can also propose ones it may not make itself, such as a higher budget or a change to your Gateway's settings: we keep each proposal (what it would change, the note the agent gave, and who proposed it) until 30 days after it was approved, declined, withdrawn or expired, and, for an organization, record each proposal and decision in its audit log. When a management key proposes a change, we email you, or the organization's owners and admins, a link to it, at most once an hour.
• Billing data: Stripe processes payments. We store your Stripe customer and subscription IDs, and we send Stripe your email address and plan. We never see or store your full card details. Invoices and payment records are kept by Stripe, not by us.
• Usage data: for each AI request, the provider, model, token counts, estimated cost, and time, and the ID of the agent run or Gateway session it belonged to, when it had one. For a Gateway request that names one of your app's end users, it also holds that end-user ID. We use it for usage reporting (including what each agent run cost), plan limits, budget alerts, and the per-end-user budgets you set on a Gateway key.
• What the apps send with your requests: to answer a request, the apps send our servers the content it needs: your messages and the conversation before them, instruction files such as AGENTS.md or .github/copilot-instructions.md, the names and descriptions of skills in your project's and your own skill folders (and a skill's files when the agent reads one), and in Ask mode the path of the file you're working in with your selection or the lines around your cursor. The IDE extensions also send a list of up to 500 file paths in your project with its README and manifest files; the CLI and Tempr Code send your operating system and shell, and the projects they find in your workspace with their folders and build and test commands. In agent mode the apps also send the contents of files the agent reads, the output of commands it runs, and, in Visual Studio, debugger state when the agent uses the debugger. Inline completion, which is off until you turn it on, sends the file's language and up to 4,000 characters before and after your cursor. The VS Code extension's commit-message feature sends your staged changes and recent commit subjects.
• Voice input: when you dictate a message in Tempr Code, the CLI or Tempr Chat in VS Code, a JetBrains IDE or Visual Studio, the app records from your microphone only while you dictate, and sends the recording to our servers, which pass it to OpenAI or Groq under your own key to turn it into text and send the text back to the message box. We don't store or log the recording or the text; we record the provider, model, length and cost like any other request. The provider handles the recording under its own privacy policy. Your computer's own dictation (Win+H, or Fn twice on a Mac) sends nothing to us.
• The Tempr app and remote control: when you make a chat available on your phone from Tempr Code or the CLI, the computer sends our servers what the app shows: the last 30 messages of the conversation, which turn is running, and the approval, plan or web page waiting for your answer, with the command, change or address it's about. We store this encrypted. To list the chat, we also keep its title, your computer's name and the project folder's name as they are. All of it is deleted 24 hours after the chat leaves your phone. The app reads the turn itself from the agent run (see below), and sends back what you do: a message, an approval, a stop. We keep what you sent, encrypted, until your computer has it, then only a record of what was done (an approval, a message, a stop) and when, for 30 days, so you can see a phone's recent actions where you sign phones out. For each phone signed in to the app we keep its platform, model name, app version, when it was last seen, your notification settings, and its push token. Notifications go through Apple's push service on iPhones and Google's (Firebase Cloud Messaging) on Android phones; they say which chat needs you and why, never code or commands, and only "A chat" when you hide titles. The app stores your sign-in in the phone's Keychain or Keystore. The chats, records and phones are deleted when you close your account.
• Agent runs: the agent's tool-calling loop runs on our servers, so a turn survives a dropped connection. While a run is active we store its conversation, the tool calls, and their results, which can include your code. We delete a run 72 hours after it finishes. Timing, token, and cost records for each step are kept for your Gateway log retention period (7 days by default), with error text passed through redaction. When the agent reads a web page or looks up a package, our servers make that request, not your machine: only the page's address, or the package's name, goes out. Pages we fetch are held in memory for 10 minutes and registry answers for 15, so a run doesn't fetch the same page twice; what the agent reads is kept with the run like any other tool result.
• Synced chats and settings: on Standard and higher plans, the Visual Studio, VS Code, and JetBrains extensions sync each chat session to our servers so it follows you between machines, along with your custom agents and, in Visual Studio, your tool preferences. Cloud sync is on by default, and you can turn it off for your whole account (see section 8). Session content and titles are stored encrypted. Deleting a session in the extension deletes the synced copy. The CLI keeps sessions on your machine only. If you create a share link for a session, anyone with the link can view that session without signing in.
• Code search index: to search your code by meaning, the apps send chunks of your code to our servers, which turn them into embeddings (numeric representations) and don't keep the text. In Visual Studio on Standard and higher plans, while cloud sync is on, the embeddings are also stored on our servers, together with a hash of each file's path, line ranges, and symbol names, so your index is available on your other machines. Embeddings aren't used to train models.
• Gateway request logs: if you use the Gateway, every request is logged with metadata: the model you asked for and the one that answered, the reasoning level applied, status, latency, token counts, cost, and any metadata, session IDs, or end-user IDs your app sends. By default the request and response content is also stored, each capped at about 256 KB, so you can inspect it in the logs viewer. For requests made with a Teams organization's keys, the organization's owners and admins can read it too (see section 4). For an embeddings request, that's the text you sent to be embedded; the vectors that come back aren't stored, only how many there were and their size. Logs are kept for your plan's retention period (7 days on Free, 30 on Pro, 90 on Scale) and then deleted automatically. Hourly totals made from them for your dashboard (request counts, errors, cost, tokens, latency, the prompt templates used and the guardrail categories flagged, per key and model) are kept and deleted on the same schedule. In the portal you can shorten that period to as little as one day, turn on pattern redaction, or turn content logging off for your account or for individual virtual keys. When the Gateway refuses one of your keys before anything is logged, because it expired, was revoked or was used from an address it doesn't allow, we keep only the time of the last refusal and its reason on the key, to tell you about it; the address isn't kept. We also keep a few dates on your account that outlast the logs: when you first added a provider key and when you last removed one, when your keys first sent a request and first got an answer, and the last time an app listed your models while you had no provider key for them (at most hourly). We use them to see where new accounts get stuck, and they're deleted with your account. If you ask the Gateway to cache responses (with the x-tempr-cache-ttl header), cached responses are kept for up to 24 hours. When your Agents seat comes with a Gateway Pro or Scale plan, each model call it makes is logged there too, with metadata only (the model, status, latency, token counts, and cost), never the request or response content, and kept for the same retention period.
• Error reports: when the Visual Studio or VS Code extension hits an unexpected error, it sends us a report by default: the error and its stack trace, your IDE and extension versions, and, if you're signed in, a sign-in ID. The Visual Studio extension also sends its current sign-in token, which links the report to your account. Visual Studio extension versions up to 2.2.28 sent your license key instead; we remove it before storing the report, and have removed it from the reports we already held. Versions up to 2.3.5 also sent a report when another extension in Visual Studio crashed; we have deleted those, and from 2.3.6 the extension reports only its own errors. The JetBrains plugin sends one by default too, with the error, its stack trace and your IDE and plugin versions but no sign-in ID, and also when you click "Report to Tempr" on an IDE error. The CLI sends one only if you opt in. See section 8 to turn these off.
• Feature requests and support: what you submit through the feature request form, including your IDE and extension versions, and anything you email to us.
• Teams organizations: if you're a member of a Teams organization, we store your membership and role, and a log of actions taken by the organization's admins. If your organization uses single sign-on, WorkOS handles the sign-in and we keep only your email address from it. The rules, skills, personas and slash commands your organization's admins publish for its agents are stored for the organization, with every earlier version and who made it. A deleted rule or skill is kept as an earlier version so an admin can restore it. All of it is deleted when the organization is closed. They're added to the agent turns of the members they reach, and sent to the model with each of those turns. If you ask for an MCP tool your organization's Tool Packs leave out, we keep the request with the reason you give, and the decision, who made it and any note, for the organization's owners and admins, who are emailed your email address, the tool and your reason. The request stays with the organization until it's closed, or until you close your account.
• Server logs: our web servers keep access logs with your IP address, the address requested, and your browser's or app's user agent, for security and troubleshooting. When the servers hit an unexpected error themselves, they record it with the address that was requested, so we can find and fix it.
• Update checks: once a day, the CLI and Tempr Code ask our servers for the latest version number, sending their own version and your operating system and processor type (for example "windows-x64"). We add one to a count of installs by product, version, platform and day, and keep nothing else: no IP address, account or other detail. To count each install once a day, a one-way hash of your IP address with that version and platform is held in memory for a day and never written down. If our servers don't answer, the CLI reads the version from temprhq.io instead. Setting TEMPR_NO_UPDATE_CHECK=1 turns the check off, and so does turning off automatic update checks in Tempr Code's settings.
• This website: if you accept analytics cookies, temprhq.io uses Google Analytics to measure visits; until you do, it isn't loaded (see our Cookie Policy). The contact form sends your name, email address, and message to us through Web3Forms. On the models page, your browser loads the public model list directly from OpenRouter. When you download the CLI or Tempr Code from the downloads page, we count the download by product, platform, version and day; we don't keep your IP address, a cookie or your browser's details with it. To count one download per visitor, a one-way hash of your IP address is held in memory for an hour and never written down.

Apart from what's described above, we don't keep your prompts or code after relaying a request.

3. How we use information

• To provide the Service: signing you in, relaying your requests to the providers you choose, running the agent, and syncing your chats and settings.
• To process payments and manage subscriptions through Stripe.
• To enforce plan limits (for example agent step limits and model access windows) and provide usage reporting and budget alerts.
• To keep your account secure, including your sign-in history, new-sign-in alerts, and two-factor authentication.
• To diagnose and fix problems, using error reports and server logs.
• To respond to support and feature requests.
• To send service emails: license keys, sign-in codes and password emails, security alerts, billing notices, budget and quota alerts, the Gateway alert rules you set up, and the Gateway weekly report, daily digest, key setup email (when a key keeps failing for a reason you can fix, at most once a week per key) and onboarding tips (a welcome email when you verify a new Gateway account, and one reminder about a day after signup if no request has worked yet) while you have them on. We don't currently send marketing emails.
• To understand how people use this website, through Google Analytics, if you accept it.
• To improve the Service.

We don't use your prompts, code, or chats to train AI models.

4. How information is shared

• AI providers and endpoints you configure: your requests go to the provider you added a key for (for example OpenAI, Anthropic, or OpenRouter), using your own key, and likewise to any custom model endpoints and remote MCP servers you set up. When a Gateway request names one of your app's end users, the provider receives a hash of that ID, made with a secret kept for your account, in place of the ID itself; Tempr's own logs keep the ID as your app sent it. Alerts you configure are sent to the webhook addresses you choose. Each provider's own privacy policy governs how it handles your requests.
• Web pages and package registries the agent reads: when the agent fetches a page, our servers request it from that website, which sees our servers' address and the page's address, not yours. Without asking, the agent opens only an address that appeared in your messages, in its tools' results, or as a link on a page it has already read, a page of a well-known documentation site, or a site you allowed; anything else, the apps ask you first (earlier versions of the IDE extensions than VS Code and JetBrains 1.1.8 and Visual Studio 2.2.34 refuse it instead), so it can't make up an address to carry your data somewhere without you seeing it. To let it follow a link from an earlier turn, the apps keep the links it may open and send them, and the sites you allowed, with each request: the CLI and Tempr Code save them with the session on your machine, and the IDE extensions keep them only while the chat is open. Package lookups go to the public registries: npm, PyPI, crates.io, the Go module proxy, NuGet, and Maven Central.
• Web searches: on an Anthropic, OpenAI or xAI model, the agent can search the web with that provider's own search tool. The provider runs the search, with the query the model writes, under your key for that provider and its own privacy policy. On other models, if you or your organization saved a Perplexity key, we send the query the model writes, and any site or date limits it adds, to Perplexity's Search API under that key and Perplexity's privacy policy. If there's no Perplexity key but a Tavily key, we send the same to Tavily's Search API (Tavily is a Nebius company) under that key and Tavily's privacy policy. We don't send searches anywhere else. The results come back inside the model's answer, or from Perplexity or Tavily as a tool result, and are kept with the agent run like any other tool result, and the pages they list become ones the agent may open. The CLI doesn't search in scripts (--json, piped input, or CI) unless you pass --search, and tempr config set-web-search off turns it off in interactive sessions too. In VS Code, JetBrains IDEs and Visual Studio, the Web search switch under Settings, Tools & agents turns it off.
• Service providers that help us run the Service:
  • Amazon Web Services: hosting, database, and email delivery (Amazon SES).
  • Apple Push Notification service and Google's Firebase Cloud Messaging: delivering the Tempr app's notifications to your phone.
  • Stripe: payments and subscriptions.
  • WorkOS: single sign-on for Teams organizations; it receives the organization's name and handles the sign-in. When your organization requires single sign-on and you type your email address on Tempr's sign-in page, we pass that address on so your identity provider can fill it in. If your organization connects its user directory, WorkOS tells us the email addresses of the people it gives access to Tempr, and when that access ends, so we can add and remove them. Tempr also stores the names of the directory groups an admin chooses to mirror, and which members are in them, to give those groups Tool Packs; we remove them when the admin stops mirroring a group or the directory is disconnected.
  • Google Analytics: measuring visits to temprhq.io, if you accept analytics cookies.
  • Web3Forms: delivering messages sent through this website's contact form.
  • Public content delivery networks, such as jsDelivr, that serve some of the portal's scripts and icons to your browser and so receive your IP address.
• Your Teams organization: if you're a member, its owners and admins can see the member list (email addresses and roles), spending by member, model, and provider, budgets and limits, usage analytics and request logs for organization keys, including the request and response content when the organization stores it (which it does by default), the metadata of the model calls you make on an Agents seat that comes with its Gateway plan (never their content), summaries of agent runs (tools used, model, tokens, cost, and errors), and the admin audit log. Each time an owner or admin opens a request that holds content, it's recorded in that audit log. Admins can't see your personal Gateway logs or your synced chats. If the organization's owner closes their account, the organization closes and your Team access ends, but your own account stays.
• Log streaming your organization sets up: on the Gateway Enterprise plan, an organization's owners and admins can have us send its Gateway request logs, agent run summaries, and admin audit log (which names the members who made each change by email address) to an observability service or web address they choose, as the activity happens. Request and response content is sent only if they choose that too, and only where the organization stores it. Once sent, it's held under that service's terms, not ours: we can't recall it, and closing your account or the organization doesn't delete it there.
• Legal requirements: if required to comply with law or legal process, or to protect the rights, property, or safety of Tempr or others.

We don't sell your personal information.

5. Where your information is stored

Tempr is based in the United States. We store and process information with Amazon Web Services in its US East (N. Virginia) region. If you use the Service from outside the US, your information is transferred to and processed in the US.

6. Data security

Provider keys and other credentials, synced chat content and titles, and two-factor secrets are encrypted at rest. Connections between your devices and our servers, and between our servers and AI providers, are encrypted in transit. The apps store your license key and sign-in tokens encrypted on your machine. No method of storage or transmission is 100% secure, so we can't guarantee absolute security.

7. Data retention

• Account, license, and usage data, and your sign-in history: until you close your account. Stripe keeps invoices and payment records for as long as tax law requires.
• Browser sign-in requests: deleted a day after they expire, ten minutes after they're made.
• Agent runs: deleted 72 hours after the run finishes. Per-step timing and cost records follow your Gateway log retention period.
• Gateway logs: your plan's retention period (7, 30, or 90 days, or what an Enterprise contract sets), or shorter if you set it. Cached responses: up to 24 hours. The record of each alert a Gateway alert rule sent (which rule, when, the value, and whether the email and webhook went): 90 days.
• Synced chats, settings, and the code search index: until you delete them, one session at a time in the extension or all at once with "Delete synced data" in the portal or the extension's settings, or close your account. Turning cloud sync off stops new uploads but doesn't delete what's already synced unless you choose to.
• Error reports: each report for 90 days at most, and only the latest 50 of any one error. For each distinct error we also keep, until we delete it, a summary made from its first report: the error's type, its message and the top lines of its stack trace (with keys, tokens, email addresses and the user name in file paths removed), the first and latest versions it happened in, when, and how often. Reports sent while signed in are deleted when you close your account; the summaries aren't, since they aren't linked to an account. Feature requests: until we delete them or you close your account. Support messages: until we delete them; ask us if you want yours removed.
• Server logs, including access logs: 14 days.

When you close your account, it closes straight away. We cancel your subscriptions, with no refund for the rest of the period; any Gateway overage not yet billed is charged first. We delete your customer record at Stripe, including your saved card, and we delete your account and everything tied to it: your portal sign-in (email address and hashed password), two-factor settings and sign-in history, license keys and app sign-ins, synced chats and settings, the code search index, provider keys, custom models, MCP credentials and MCP server sign-ins, apps connected to your MCP servers, Gateway keys, subscriptions, and logs, agent runs, usage records, error reports and feature requests, and our records of the emails we sent you. If you own a Teams organization, it closes too: its members lose Team access and we email them (their own accounts stay), and its keys, logs, settings, and audit log are deleted. In an organization you belonged to but didn't own, the organization's own records of your activity there (its request logs, spending, and admin audit log) stay, with your account and email address removed from them. Stripe keeps the invoices and payment records for your past payments, as tax law requires, and server access logs rotate out on their usual schedule.

8. Your choices and rights

• You can remove a provider key in the portal at any time, which stops it from being used for future requests.
• You can turn off error reports. In Visual Studio, VS Code and JetBrains IDEs: the "Automatic error reporting" switch under General on Tempr's settings screen (the gear in the chat panel); in VS Code, reports are also skipped when VS Code's own telemetry is off. The CLI sends none unless you opt in, and tempr config set-crash-reports off turns them off again.
• Inline completion stays off unless you turn it on.
• For the Gateway, you can shorten log retention, turn on pattern redaction, or turn content logging off in the portal. You can also have secrets, and optionally personal data such as email addresses and phone and card numbers, replaced with placeholders in prompts before they reach the model provider, and in the model's answers before they reach you. The data-loss prevention rules you set for this are stored with your Gateway settings, including any values you list as never to be masked, such as a support address; a Teams organization can do the same for its members' own turns in the IDEs, the CLI and agent runs. A Teams organization's owners and admins make the same choices for requests made with its keys.
• You can turn cloud sync off for every machine and extension on your account: on the Profile page in the portal, or with the Cloud sync switch on Tempr's settings screen in Visual Studio, VS Code and JetBrains IDEs. While it's off, our servers don't accept or return your chats, custom agents, tool preferences, or code search index. When you turn it off you can also delete what's already synced, and you can do that at any time with "Delete synced data" in the same places. Deleting a session in the extension also deletes its synced copy.
• Google Analytics runs on this website only if you accept it, and you can change your choice at any time with Cookie settings at the bottom of any page; see the Cookie Policy.
• You can close your account on the Profile page in the portal, which deletes your data straight away (see section 7), or email us to have it deleted.
• You can request access to, correction of, or deletion of your personal data by contacting us.
• If you're in the EEA, UK, or Switzerland, you have rights under the GDPR to access, correct, delete, restrict, or port your data, to object to processing, and to lodge a complaint with your local data protection authority.
• If you're a California resident, you have rights under the CCPA/CPRA to know what personal information we collect, request its deletion or correction, opt out of the sale or sharing of personal information (we don't sell it), and not be discriminated against for exercising these rights.

9. Children's privacy

The Service is not directed to children, and we don't knowingly collect personal information from anyone under 16.

10. Changes to this policy

We may update this policy from time to time. If we make material changes, we'll update the "Last updated" date above and, where appropriate, notify you.

11. Contact

Questions about this policy, or want to exercise a data right? Contact us at contact@temprhq.io.