Privacy & your code
The short version
- Your code is not used to train any model. Not ours, not the model providers'.
- We do not store the code you submit. It lives in memory for the length of your review session and is gone when you disconnect.
- We do save what a review found: the issues, the discussion and the final document, so a reload doesn't lose it. Never the files themselves.
- We do store metering data: how many tokens a review used, which model, and what it cost us. Never the content.
- To review your code, we must send it to the model providers. That is the product. Who they are, and what they may do with it, is set out below.
1. Who we are
Apex Directive is operated by StackForge Labs, LLC. If you want to reach a human about anything on this page, write to privacy@theapexdirective.dev.
2. What happens to code you submit for review
This is the section you came for, so it goes first and it is specific.
While a review is running
The files you attach are held in memory by our engine, for the lifetime of one WebSocket connection. They are sent to the model providers that make up your panel, and their responses come back to your browser.
We write no part of your code to disk, to a database, or to a log. There is no table it lands in, and there is no backup of it, because there is nothing to back up.
When the review ends
When you close the tab, sign out, or lose your connection, the engine's copy of the session is destroyed and the files go with it. They are never written anywhere.
Saved reviews: the findings, not the code
Your browser saves what a review produced to your account, so a reload does not lose work you paid for and you can reopen a review from last week. That means the issue list, the discussion, and the final document.
It does not mean your code. Saved reviews record the names of the files reviewed and nothing of their contents. There is no setting that changes this and no plan on which it differs.
The consequence is real and we would rather state it than quietly widen what we keep: a reopened review can be read, searched and exported, but re-running it needs the files attached again. That is the cost of the promise above, and we think it is the right way round.
You can delete any saved review from the History screen. It goes immediately. There is no trash we quietly keep.
Reviewing straight from GitHub
You can connect a GitHub app and review a pull request without downloading and re-uploading its files. What the app may read is decided by you, on GitHub, and it is narrow: repository contents read-only, and pull requests read and comment, on only the repositories you choose. It cannot write to your code, open anything, or see a repository you did not select.
The app comments on a pull request only when you press Post to PR on a finished review. It posts that review: one summary comment, and a comment on each changed line a finding points at. Issues you dismissed are left out. Nothing is posted on its own, and pressing it again updates the summary rather than adding another.
Code pulled from GitHub follows exactly the same path as a file you upload: held in memory for the life of one connection, sent to your panel, and never written down. Connecting GitHub does not create an exception to anything above it on this page.
A review pulled this way additionally records where it came from (the repository name, the pull request or branch, and the commit), so a reopened review can tell you what it read. That is a label, not a copy: the code itself is no more stored than any other attachment.
When you connect, GitHub gives us a sign-in token for you, and we keep it, encrypted, so that before every read or post we can ask GitHub which of the app's repositories you can see. We read and post only there, even when the app has been installed on more. The token is used for nothing else, is never shown to your browser, and is deleted when you remove the app or delete your account. You can revoke it at any moment from GitHub's settings, without asking us, and from then on we can read nothing until you reconnect.
Everything we store, in one table
This is the whole list. None of it contains your file contents: the one row that touches a review holds what the review produced, never what you submitted.
| What | Why | Kept for |
|---|---|---|
| Email address, and a hashed password if you use one | To sign you in | Until you delete your account |
| Your settings: review templates, custom prompts you have saved, which models sit in which chair | So the app looks the same next time | Until you delete your account |
| Your own provider API keys, if you are on the BYOK plan | So the engine can run the panel on your keys | Until you remove the key or delete your account |
| Saved reviews: the issue list, the discussion transcripts, the final document, the names of the files reviewed, and, when the review came from GitHub, the repository, branch or pull request, and commit | So a reload does not lose a review, and so you can reopen an old one | Until you delete the review or your account |
| If you connect GitHub: which installation of our app belongs to your account, the organisation or username it was installed on, and your GitHub sign-in token, encrypted. No list of your repositories | So we know whose app to read a pull request through, and can check with GitHub that you may read it | Until you remove the app on GitHub or delete your account |
| Metering: per model call, the number of input and output tokens, the model, which phase of the review it belonged to, and what it cost | To enforce your plan's budget, and to know whether the business works | Retained after account deletion, with your identity removed (see section 7) |
| Which account emails we have sent you (welcome, trial ending, trial ended) and when | So you get each one once | Until you delete your account |
| Subscription state, and the customer id our payment provider (Polar) gives us | To bill you and to know what you have access to | As required for tax and accounting records |
3. Training: the explicit statement
Apex Directive does not use anything you send to train, fine-tune, or evaluate any machine learning model. We do not do it, and we do not permit it downstream.
We have no training pipeline, no evaluation set built from customer data, and no arrangement with anyone to supply them. We could not train on your code if we wanted to: as described above, we do not keep it. Saved reviews are not an exception: they hold findings, and they are not used for this either.
Your code does reach the model providers, because that is how a review happens. We access those providers through their commercial APIs, whose terms exclude API content from training by default. We do not opt in to any program that would change that, and we do not enable any provider feature that retains your content for model improvement.
We are describing third parties here, so read this carefully: we can tell you which contractual terms we operate under and which settings we have chosen, and we do. We cannot personally guarantee another company's internal conduct. If that distinction matters to your organisation, and for some regulated work it should, the providers' own policies are the primary sources, and we have linked them below.
4. Who else sees your data
We use the following sub-processors. This list is exhaustive at the date above.
| Who | What reaches them | Their terms |
|---|---|---|
| Anthropic, OpenAI, Google | Your prompt and attached files, when a seat on your panel runs their model | Anthropic · OpenAI · Google |
| OpenRouter | Your prompt and attached files, when a seat on your panel runs a model we reach through OpenRouter (for example DeepSeek, Qwen, Llama, Grok or Kimi). OpenRouter passes the request to a company that hosts that model. Every such request tells OpenRouter to use only hosts that do not store or train on it. On a paid plan this runs on our OpenRouter account; on the BYOK plan, on yours. | OpenRouter |
| Supabase | Your account, settings, saved reviews and metering rows. Never the files you attached. | Supabase |
| Hetzner | Runs our servers. Your prompt and attached files pass through them in memory while a review runs, as described in section 2. Nothing is written to their disks. | Hetzner |
| Polar | Your email and payment details. Polar is the merchant of record: it sells you the subscription, takes the payment and handles sales tax. Card numbers go to Polar and its payment processor directly and never touch our servers. | Polar |
| Crisp | Live chat on the public pages of this site, and only if you agree to it when asked. Whatever you type into the chat, and the browser storage the widget needs to keep one conversation together. It is never loaded on the app itself, so it cannot see your code, your prompts or the model’s answers. | Crisp |
| Resend | Your email address and the text of the few emails we send about your account: a welcome when you sign up, and a reminder near the end of your free trial and when it ends. Replies come to a person, not to Resend. | Resend |
| Sentry | Crash reports from the app and our servers: the error, where in our code it happened, the app version, and your browser and operating system. Built from a fixed list of fields, so never your code, your prompts, the model's answers or your keys. | Sentry |
We do not sell your data, and we do not share it with advertisers. There is no advertising and no third-party analytics anywhere. The chat widget runs on the public pages only (never on the app), and only after you allow it.
Cookies, and what is kept in your browser
We set no cookies. What the site keeps, it keeps in your browser’s own storage, and it never leaves your device except where this page says otherwise:
- Your sign-in session, so you are not asked to log in on every page. Strictly necessary: without it the app cannot work at all.
- Small preferences: the light or dark theme you picked, and whether you closed the announcement at the top of the page.
- Your answer to the chat question, so we ask once rather than on every visit.
- Crisp’s own storage, but only once you have said yes. Decline, or ignore the question, and the widget is never loaded.
To change your mind, clear this site’s data in your browser: the question is asked again on your next visit, and anything Crisp stored goes with it.
5. Your API keys, if you bring your own
On the BYOK plan your provider keys are encrypted and stored in a vault that our application database cannot read directly. The browser can write a key and can ask whether one exists; there is no path by which the browser can read a key back, so a stolen session cannot be used to extract your keys. Only the engine can decrypt them, and only to make the model call you asked for.
Deleting a key deletes the encrypted secret, not just the reference to it.
6. Security
- Everything is encrypted in transit. The app refuses to connect to a review engine over an unencrypted connection unless that engine is on your own machine.
- Data is isolated per account at the database level, so one account's rows are unreachable from another's session.
- Dependency, container, secret and static analysis scans run against every change.
No system is perfect, and anyone who tells you otherwise is selling something. If you find a security problem, please write to security@theapexdirective.dev. we would much rather hear from you than not.
7. Deleting your account
You can ask us to delete your account at any time by writing to privacy@theapexdirective.dev. When you do, your settings and your stored API keys are destroyed, along with the encrypted secrets behind them.
Your metering rows are kept, with your identity detached from them. What survives is token counts, model names, phases and dollar amounts: the record of what the business spent, not who it was spent for. We are telling you this rather than claiming a clean sweep, because destroying those rows would silently rewrite our own financial history.
Depending on where you live you may also have rights to access, correct, export or object to the processing of your personal data. Write to the same address and we will action it.
8. Changes
If we change this policy in a way that affects what happens to your code, we will email you before it takes effect, rather than merely update the date at the top and consider you notified.