privacy policy

what we process for the website, your account, the coding agent and the ads that fund it, why, and your rights

The short version. We store an account, a credit balance and a list of the credit movements behind it — plus, so we can tell whether earning credits actually works, a note when a request is refused because you are out, when you open an offerwall, and when an attempt there ends without credit (sections 4 and 5). We do not store your code, your prompts or the replies — for each request we record which model you used, how many tokens it consumed, which provider served it and what that cost us, never their content. Advertisers never receive any of it. The text itself is passed to the model provider to answer the request, and what they may keep is the one thing here that is not ours to promise, so section 4 sets it out rather than summarising it. Two things leave your machine without passing through us, and both show the network on the other end your IP address the way any website would. One is an offerwall, which you open in your browser; two networks run them, and section 5 names each one and what it is sent. The other is the sponsored line in the terminal, which is fetched from an ad network directly. Section 8 sets out exactly what that request contains, and the switch that stops it being made.

1. controller

Florian Rappold
Maikäferstraße 3f
85551 Kirchheim bei München, Germany
Phone: +49 151 61893139
Email: info@clixad.io

2. visiting this website

• Technical server data. When you open this site our hosting provider processes data such as your IP address, the requested page, timestamp, referrer and browser identifier. This is standard web server logging, needed to deliver and secure the site.
• Aggregate visit statistics. We use Vercel Web Analytics to count page views and referrers. It sets no cookies and stores nothing on your device. Instead Vercel derives a pseudonymous visitor identifier by hashing incoming request data (such as IP address, browser identifier and requested page). That identifier is rotated at least daily, so you cannot be recognised across days or across other websites. We only ever see aggregate counts, never individual visitors.

We use no cookies, no cross-site tracking and no advertising pixels on this site, and we do not build profiles of visitors. You can read this site, and the whole blog, without an account.

3. your account

An account is created when you sign in with GitHub, either from the command line, using GitHub's device flow, or in the browser on our own site, using GitHub's ordinary sign-in page. Both lead to the same account: the one that belongs to your GitHub user. We ask GitHub for your user id, your login name and your email address. From that we store:

• Your GitHub numeric id and login name, which is how we recognise you on the next sign-in.
• Your email address, so we can reach you about your account. If you keep your address private on GitHub, we never receive it; a @users.noreply.github.com placeholder is stored instead.
• An access token for your account, and the model it was set up with. A model you pick later is saved on your own machine, and we see it only on the requests you make with it.
• Your preferences, if you set any on the account page, in the chat or with /model and /effort in the terminal: the model a new conversation starts on, the reasoning setting per model, what Clixad should call you, the instructions you want every answer to keep in mind, and whether the terminal shows the sponsored line. They are kept with your account so they hold in the browser and in the terminal alike. The name and the instructions are sent with every model call you make, as part of the request.
• Your credit balance and the entries behind it — one row per signup bonus, earned reward, purchase, reversal and metered request, each with the amount, the reason and the time.

We never receive your GitHub password, and the permissions we request are read-only (read:user, user:email). We cannot see your repositories through them.

4. your code and your prompts

The agent runs on your own machine and reads the files you point it at. To answer a request it sends the conversation — your instructions, the file contents it has read, and the results of the commands it ran — through our gateway to the model provider.

The chat on our site works the same way. To answer a message your browser sends the conversation — your messages, the text of files and PDFs you attach, which the browser reads itself, and images you attach — through our gateway to the model provider. When you switch on web search, the search terms the model chooses go through our gateway to the search provider. The conversations themselves are kept by your browser (section 11), not by us.

• We do not store any of it, unless you rate an answer. What we write down for a request is the model id and the number of input and output tokens, because that is what a request costs, and the name of the provider OpenRouter routed it to with what that provider charged us for it, so we can check that we are not paying more than we charge. For a paid request we also write down how many of the credits it cost were bonus credits, because that decides what you can still spend on which model (terms, section 6). The content is held only for as long as it takes to pass it on and stream the answer back. The one exception is the next bullet, and it happens only when you say so.
• If you rate an answer, we keep that exchange. Every fiftieth turn the terminal asks whether the last answer was any good, and offers credits for either answer. If you pick one, we store the rating, the model, what you asked and what the agent replied — each side cut to about 4,000 characters. We keep it to build a set of real cases we can test future versions against, which a bare score cannot do: “71% thumbs-up” is a number to watch go down, and a question with a bad answer next to it is something we can fix. Skipping stores nothing at all — no request leaves your machine — and both answers pay the same, deliberately, because paying more for a thumbs-up would buy us thumbs-ups instead of the truth.
• If a request is served free, we record that it was. A few of the cheapest models are free to use up to a daily limit, and because that limit and the budget behind it have to be counted, we keep one row per free request: your account identifier, the time, which model, the number of input and output tokens, what the request would have cost had you paid for it, and which provider served it and what it cost us. That is the same handful of facts a paid request already leaves in your credit history — it is in its own table only because a free request moves no balance and does not belong in a record of money. Not the request itself, which is covered by the first bullet and is no different here. We also record it when a request that could have been free was not, and why — the model, the time, the reason and your balance — because that is the moment the free allowance hands you over to the offer wall, and we cannot tell whether that works without it.
• If a request is refused for lack of credits, we record that it was. The request is stopped before it reaches a model, so there is nothing to meter; what we keep is your account identifier, the time, which model was asked for, your balance and what the request would have cost. Not the request itself. We keep it to see how often people run out mid-task and whether earning credits gets them going again — without it we cannot tell an empty wallet from a lost user.
• We send no account identifier with it. The request carries the conversation and the name of the model, not who you are.
• Advertisers receive none of it. Neither of the two places an advertiser is involved is given your code, your prompts or the name of your project: the offerwall is a separate page in your browser (section 5), and the sponsored line is a request that carries a category tag and an opaque token and has no field content could travel in (section 8).

Where it goes is the part worth reading properly. Requests are routed by OpenRouter, Inc., a company in the United States, to the operator of the model you selected. We have no separate data processing agreement with OpenRouter: their privacy policy (version of 6 July 2026) applies one only to customers who have signed it, and we have not. The relationship rests on those published terms, under New York law, with their servers in the United States; transfers out of the EU rest on adequacy decisions and the European Commission's standard contractual clauses.

Under that policy, OpenRouter does not use inputs or outputs to train models. It does transmit your inputs to the model provider serving the request, and those providers are separate companies with their own terms: they may retain what they receive and use it for their own purposes, which can include training. OpenRouter requires them by contract to comply with data protection law, but does not control what they do with it independently of that. Requests about data held by OpenRouter go to privacy@openrouter.ai.

Against that, here is how our own account is set. We do not permit routing to endpoints that train on request data, on paid and free endpoints alike, and we do not permit endpoints that publish prompts to public datasets. OpenRouter offers a discount in exchange for sharing request data with it; we have not taken it. Every model we offer is a paid endpoint in any case, so there is no free tier in our catalogue for that setting to reach.

One thing we deliberately do not claim. We do not restrict requests to zero-data-retention endpoints, and we do not restrict which providers may serve one. A provider can therefore still hold on to what it receives — to detect abuse, or to meet an obligation of its own — for as long as its own terms allow, even where it may not train on it. Not training on something and not keeping it are two different promises, and only the first is one we are in a position to pass on.

5. earning credits on the offerwall

Credits are earned by completing a survey on an offerwall. Two networks run the walls we send you to, and each wall is their own page, loaded by your browser straight from them. So whichever one you open, that network sees your IP address and the other details any website receives from your browser. What we put into the link itself differs by network:

• CPX Research, operated by Make Opinion GmbH, Elfenallee 5, 13127 Berlin, Germany, receives an internal, randomly generated account identifier (a UUID), a signature, and the email address on your account. Make Opinion GmbH uses the address to recognise the same person across their panel; when we do not send it, their own page asks you for it before a survey starts.
• TheoremReach, operated by TheoremReach Inc., 500 Westover Dr. #33399, Sanford, NC 27330, USA, receives the account identifier, a visit reference we generate each time you open it, our API key, the rate at which their payouts convert into credits and the name to show for them, and a signature over the whole link.

Only CPX Research is sent your email address. Neither network is sent your GitHub login or your name.

The list of surveys shown on our page comes from CPX Research alone. It is asked for on your behalf, by our server rather than by your browser, and it is the only request our server makes to either network. That request carries the same account identifier, signature and email address, and it also carries your IP address and your browser identifier, because Make Opinion GmbH decides which surveys are open to you from where you are and what you are browsing with — a list fetched with our server's address would offer everyone surveys for a data centre in Frankfurt. Those two are the same details they would receive directly from your browser the moment you opened one of the offers, and they are the only additional details we pass on. We do not store the list; it is held for at most two minutes so the page can be drawn, which is also the longest their own terms allow it to be kept.

Everything after that happens between you and the network on its own page, under its own privacy policy: which offers you are shown, the demographic questions their partners ask, and whatever they store about your participation. For CPX Research that is Make Opinion GmbH’s privacy policy. For TheoremReach it is TheoremReach Inc.’s privacy policy, and their data protection officer is Mel Montano, privacy@theoremreach.com. Make Opinion GmbH is a German company, so opening their wall involves no transfer out of the EU on our side. What applies to TheoremReach is set out in section 14.

From each network we receive the result: a transaction id, that internal identifier, the payout, and whether it credited or was charged back. We store it so the same reward cannot be paid twice and so the daily limit can be applied. The reports from CPX Research and TheoremReach also carry a field for an IP address, named ip_click at CPX Research and ip at TheoremReach. We do not keep it: it is removed before a report is stored, and blanked out of the request addresses our server writes to its log. TheoremReach’s report also names the offer, and that name is written to our server log along with the result.

On our side we also note, each time you set off for the wall, that you did: your account identifier, the time, which offerwall, and whether you opened the whole wall or one of the surveys listed on our page — in that second case, which survey, since we picked it and can tell. When you set off from one of the sections of our page (short surveys, longer surveys), we note which section it was. Nothing about what happens inside an offer, which we never see. We keep these apart because the list is only worth showing if it works better than the whole wall, and the sections only if we can see which kind of offer people actually finish, and recorded as one thing none of that can be compared. We also count the walls you opened today, at least three minutes earlier, against the offers you completed today: each attempt that earned you nothing opens one more of our own surveys for that day (terms, section 8). That count is read when you look at the offers page or start one of our surveys, and nothing new is stored for it.

Opening TheoremReach adds one more row: the visit reference we put into that link, against your account identifier and the time. It exists so that a completed offer can still be matched to your account if the identifier they send back is missing or garbled. It says nothing about what you do on their page.

CPX Research and TheoremReach also tell us when an attempt ended without a completion — a screenout, where a few questions in you turn out not to match who the advertiser is paying for and the survey stops. We record that too: your account identifier, their transaction id, which offer it was, the time, and the report itself as the network sent it, without its signature and without the IP address described above. For TheoremReach that report also holds the name of the offer. Not your answers to their surveys, which we never receive — our own surveys are a different arrangement, and section 6 covers them. This is the ordinary outcome of starting a survey rather than a rare one, and we would rather measure it than assume it — without it, nobody earning and everybody being screened out look identical from here. The record itself credits nothing and moves no balance, and it is kept apart from the credit records for exactly that reason. Some networks do pay a small amount for a screenout; when one does, that payment is stored as a reward like any other.

6. answering one of our own surveys

Some surveys on the offers page are ours rather than a network’s, and this section is the exception to almost everything section 5 says. Nobody else is involved: the questions are ours, the page is on our own domain, and we receive and keep your answers. For these, we are the controller in the ordinary sense — not a party passing an identifier to somebody else.

When you open one we record that you started it and when. When you submit it we store the answers you gave, the time, whether they passed the survey’s attention check, and what was credited, against your account identifier. Answers are stored whether or not they are credited — including when a check was failed, or when the day’s budget ran out while you were typing.

Purpose and legal basis: to run the survey, credit it, and understand how people use Clixad so we can improve it. This is part of what you get an account for, so the legal basis for the answers and the credit is the contract between us, Art. 6 (1) (b) GDPR. Answering is entirely voluntary — nothing about your account changes if you never do.

Your answers never leave us as your answers. We do not sell them, and we pass no individual answer to anyone — not to an advertising network, and not to a company that sponsors a question, is considering sponsoring one, or has asked to see what our users think. What a third party is ever shown is counts and proportions across accounts, with no account identifier attached, and no free-text answer quoted where the wording could point back at whoever wrote it.

Putting several surveys together is what makes that rule necessary. On its own, “deploys on one particular cloud” says very little. Beside a team size, an employer type and who signs off on tools, it describes a person — and because every answer sits against the same account identifier, we can put them together whether we set out to or not. So we treat survey answers as personal data throughout, and we do not report a figure that rests on fewer than five accounts: below that, a proportion stops being a statistic and becomes a description of the people in it.

Answers are stored with everything else about your account and are deleted with it — see section 15.

7. answering a sponsored survey

Some surveys on the offers page are written by a company that pays us for the answers. They say “Sponsored by” and the company’s name before anything is answered. They are answered on our own domain, and we receive and keep your answers; the company does not. For these we are the controller, exactly as for our own surveys in section 6.

When you start one we record that you started it and when, and which of our check questions you were shown. When you submit it we store the answers you gave, the time, whether they passed the check, and what was credited, against your account identifier. A counted response is also kept as a delivery record for the company’s campaign, and that record holds your account identifier for 30 days, for checking for fraud and settling the campaign, after which only the count remains.

Two checks stand in front of a sponsored survey, because a company is paying for genuine answers: the account has to have made at least three model calls, and its GitHub account has to be at least 30 days old. The first time you start a sponsored survey, our server asks GitHub when your GitHub account was created, using the GitHub user id we already hold from your sign-in, and we keep that date with your account.

What the company receives is counts. For each question it sees how many people chose each answer, and nothing at all until at least ten responses have been counted. It never receives an answer, a time, an account identifier, your email address or any way to put two of your answers together. There is no free text in a sponsored survey, so nothing you typed about yourself can reach it.

If the survey offers a link to the company’s site after your response is counted and you follow it, our server counts the click against the campaign, with no account identifier, and sends your browser on. From there you are on the company’s site and its own privacy policy applies.

Purpose and legal basis: to run the survey and credit it, which is part of what you have an account for, Art. 6 (1) (b) GDPR; and, for the two checks and the 30-day delivery record, our legitimate interest in keeping paid answers genuine and in settling the campaign correctly, Art. 6 (1) (f) GDPR. Answering is voluntary. When your account is deleted your answers stay without anything that identifies you, because the counts the company paid for are made from them; see section 15.

8. the sponsored line in the terminal

While the agent is waiting for a model, the command line tool shows one dim line above the input box. Most of the time it is our own text — a usage tip, a keyboard shortcut, what the model you picked costs — which is built into the tool and involves no network at all. Sometimes it is an advertisement instead, fetched from ADtention (adtention.ai), an ad network for terminal tools. An advertisement says so on the row itself, with an Ad mark ahead of the text rather than after it; our own content never carries that mark, and it is the last part of the row to be dropped on a narrow terminal.

An advertisement can also appear in two further places: a small card beside the working line, shown only on a terminal at least 90 columns wide, and a row of its own under the status line. Both show only advertisements, marked with the same Ad, and only while the model is working. Each place is fetched separately, so with all of them in use a single model call can mean up to three requests to ADtention. Everything below applies to each of those requests in the same way.

That request goes from your machine to ADtention directly, and not through us. It used to go through our server, which would have kept your address out of it altogether; their network refuses requests coming from our server, so that arrangement does not work. The consequence is worth stating plainly rather than in a euphemism: when a sponsored line is fetched, ADtention see the connection, which in practice means your IP address — the same thing any website sees the moment you open it.

What the request carries is the whole of what it carries:

• Our publisher id, which says the impression belongs to Clixad rather than to some other application. Each of the places described above has its own, and each one is the same for every user of the tool.
• One fixed category tag, which says what kind of tool this is — a developer tool used in a terminal — so the advertisement is not wildly off. It is set by us and is the same for everyone. It is never derived from your prompts, your files, your project or anything else you typed.
• An opaque token that stands in for your account, described below.
• A one-off value (a timestamp and a few random bytes) that makes each request distinguishable from the last. It identifies nothing and is not reused.

Your prompts, your code, your file contents, your paths, your repository names and your command output are not sent, and there is no field in the request they could travel in. Neither is your account identifier, your email address or your GitHub login.

The token is a one-way hash (SHA-256) of your internal account identifier, mixed with a value that we hold and that is specific to us. It is computed on our server, and the tool is handed the finished token rather than the ingredients. Two things follow, and it is worth separating them. ADtention receive the token and never the identifier, so they cannot work backwards from it to an account, and because the mixed-in value is ours, the same person appears as a different token to every other application using this network — that is what stops one being followed around. What does not follow is that the link is unknowable to us: we hold both halves, so we can recompute the token for a given account. It exists to keep you uncorrelatable to third parties, not to hide you from us.

The token is stable, deliberately, because ADtention’s own rate limits and daily caps are applied per person. A fresh token each time would defeat them. For the same reason it is one token for all of the places an advertisement can appear, so ADtention see one person rather than several.

Nothing is written to your disk for it. The tool is not a browser: there are no cookies, no local storage and no file kept on the ad network’s behalf. A line that has been fetched is held in the running program’s memory and shown again for a short window rather than fetched afresh every few seconds — which is fewer requests, not more — and it goes when you close the tool.

ADtention decide for themselves what they do with a request they receive, so for this step they are a separate controller and not a processor acting on our instructions; what they keep is governed by their own terms rather than by an agreement with us. They operate from Switzerland, which the European Commission has recognised as offering an adequate level of data protection, so no additional transfer safeguard is required — and in any case the connection is made by your computer, not by our server.

On our side, an impression is recorded against your account only if it earns you credits. When it does, the tool tells our server that a line was shown, and we store the same kind of row we store for any other earning: your account identifier, the network’s identifier for that impression, which of the places it was shown in, what it paid, what we credited, and the time. It appears in clixad wallet as “sponsored line shown”. The identifier is kept for the reason the offerwall’s is: it is what stops the same impression being paid twice. Along with it we receive the network’s own identifier for the advertisement, which we write to our server log and do not keep in your account records. We never receive the text of the advertisement, and we are never told who placed it.

An impression that earns nothing — the ordinary case, since crediting is capped and paced — adds nothing to your account or to your balance. It is not silent, though, and it would be wrong to say so: the report still reaches our server, and the fact that it was refused and why is written to the server log, which is kept for the short period described in section 15.

Every report, whether it earned you anything or not, is also added to a daily count for the place it was shown in: how many reports arrived that day, how many of them the network said it pays for, and the sum of what it said they were worth. The count holds no account, no identifier and no time of day, so it says nothing about you. It is how we know what the line earns.

Recent versions of the command line tool also ask our own server, once per model call, whether a business has booked one of these places for a line of its own. The question names the places that fit your terminal right now and its width in columns, and nothing else. We add it to a daily count per place, which again holds no account, no identifier and no time of day. So that nobody sees the same booked line more than ten times a day in one place, we also count per account for the current day, in the server’s memory only: that count is never written to a database and is gone at midnight UTC or when the server restarts. While nothing is booked the answer is always no, and the line works exactly as described above.

When a business has booked a place, the line comes from our server, not from ADtention. The answer carries the business’s line, a link address on our server and a token our server signed for your account; for that place your machine makes no request to ADtention at all. The line is marked Ad like every other advertisement. When the agent’s turn is over, the tool tells our server which booked lines it actually drew. A line that passes the same checks as an ADtention line is counted towards that business’s week and earns you credits in the same way, recorded as “sponsored line shown” like any other. For each counted line we store your account identifier, the booking, the place and the time, so that one line cannot be counted twice and the count can be checked. After 30 days the account identifier is removed and only the count is kept.

In terminals that support links, a booked line is a link to our server. Opening it counts one click for that line, without your account: the address names the booking, never you. Our server then sends your browser on to the business’s website, which sees your visit the way any website does. The business receives, for each week and place, how many lines were counted and how many were clicked, and nothing that identifies anybody.

Turning it off stops the request, not just the line. Set CLIXAD_SPONSOR=0 for a single run, or put { "sponsor": false } in ~/.clixad/config.json to keep it off. The switch is checked before anything is fetched, so with it off your machine never contacts the ad network at all, and does not ask our server for a booked line either. The line is also silent on its own whenever output is piped or redirected, in CI, and under NO_COLOR.

9. buying credits

Buying credits is optional and never required. Payment is handled by Stripe Payments Europe, Ltd. on Stripe's own payment page. When you start a purchase, we send Stripe the following and nothing else about you:

• our internal account identifier;
• the pack you chose, with its name, price and number of credits;
• the version of the terms of service you are asked to accept;
• the time you made the two declarations about your right of withdrawal, as your device reported it, or the time our server received them if it reported none.

Your email address is not on that list; Stripe asks for it on its own page. You choose how to pay on that page, and your payment details are entered there or with the provider of the payment method you choose; we neither see nor store them. Stripe tells us that a payment succeeded, and we store the payment's identifier, the amount and the credits granted, as the record of the transaction.

Some payment methods are provided by a company other than Stripe. If you choose one of them, that company also receives the data it needs to carry out the payment and processes it under its own privacy policy. Where a method pays from a card or a bank account, the bank that issued it receives the payment as well. The companies involved depend on the method:

• A card: the card network.
• Apple Pay: Apple.
• Google Pay: Google.
• Amazon Pay: Amazon.
• Revolut Pay: Revolut.
• Satispay: Satispay.
• Kakao Pay, Naver Pay, PAYCO or Samsung Pay: the company behind that wallet.
• Bancontact, BLIK, EPS, MB WAY or Pix: the company that runs that method.
• Link: Stripe itself. Link is Stripe's own service for saving payment details, and Stripe keeps what you save in it under Link's own terms.

Which methods you are offered is decided on Stripe's page. A method not listed here works the same way: the company that provides it receives what it needs to carry out the payment, under its own privacy policy.

What you buy, and your right of withdrawal, are set out in the terms of service.

10. advertising with us

This section is about people who book advertising on behalf of a business. If you only use Clixad, none of it applies to you.

Advertisers sign in with GitHub. We receive your GitHub user id, your login and, if your GitHub account shares one, an email address, and we store them as your advertiser account, which is separate from any Clixad user account you may also have. You then give us your company’s name, a contact email address, its country and, optionally, its VAT number, and you write the terminal lines or the surveys you want to run, with the weeks a line should run in. Everything you submit is read by a person before it can go live, and we keep the reviewer’s note. The sign-in token your browser holds is stored on our side only as a one-way hash. If your company is in an EU country other than Germany and you give a VAT number, we send that number to the European Commission’s VIES service when you go to pay, to confirm it is valid, because it decides how the invoice is taxed; we log only whether it was confirmed and when.

Payments are taken by Stripe, which also issues the invoice and any credit note for a refund. We receive the identifiers of the payment, the invoice and the refund, and Stripe receives the billing details you enter on its page.

Purpose and legal basis: to provide the advertising you book, invoice it and refund what is not used, Art. 6 (1) (b) GDPR; and, for keeping invoices and payment records, the retention duties under German tax and commercial law, Art. 6 (1) (c) GDPR. See section 15 for how long.

11. what stays on your computer

The command line tool keeps a folder at ~/.clixad: your access token, your settings, your prompt history, and a copy of each session's conversation so you can resume it. That folder is on your machine and is never uploaded to us. Deleting it, or running clixad logout, removes the token from that machine.

The chat on our site keeps your conversations in your browser's own database for our site (IndexedDB), attachments included, and never sends them to us to store. Deleting a chat in the chat, “Delete all chats in this browser”, or clearing the site's data removes them from that browser; they are not on any other device.

When you sign in on our site in a browser, the browser keeps the same access token in its local storage for our site, so you stay signed in there. To get it there without putting it in an address, the browser holds a random value for the length of the sign-in in its session storage. “Sign out of this browser” on the account page, or clearing the site's data, removes the token from that browser.

12. the old waitlist

Before signups opened we collected email addresses on a waitlist. The form is gone, but the addresses collected then are still held. They are used for nothing except telling those people that Clixad is open, and can be deleted on request at any time.

13. purpose and legal basis

• Sponsored surveys: to run and credit them, Art. 6 (1) (b) GDPR; and to keep paid answers genuine and settle the campaign (the GitHub account age and the 30-day delivery record), our legitimate interest, Art. 6 (1) (f) GDPR. Section 7 sets out both.
• Advertiser accounts: to provide, invoice and refund the advertising a business books, Art. 6 (1) (b) GDPR, and to keep its invoices, Art. 6 (1) (c) GDPR. Section 10 sets out what that covers.
• Your account, your balance and the ledger behind it: to provide the service you signed up for, to meter what you spend, and to make sure a reward is credited once and only once. Legal basis: performance of a contract, Art. 6 (1) (b) GDPR.
• Passing your requests to the model provider: this is the service itself. Legal basis: performance of a contract, Art. 6 (1) (b) GDPR.
• Your account identifier in an offerwall link, and the TheoremReach visit reference: so that an offer you complete is credited to your account. Legal basis: performance of a contract, Art. 6 (1) (b) GDPR.
• Purchase records: to complete the payment, and afterwards to satisfy the retention duties that apply to accounting records. Legal bases: Art. 6 (1) (b) GDPR and, for the retention, Art. 6 (1) (c) GDPR together with German tax and commercial law.
• Server data, rate limits and abuse prevention: to operate the service securely and stably, and to stop a single account or address from draining the reward budget. Legal basis: our legitimate interest, Art. 6 (1) (f) GDPR.
• Refused requests, offerwall opens and screenouts: to understand whether the way credits are earned actually works — how often people run out mid-task, how often an attempt at the offerwall ends without credit, and whether the surveys we list are a better use of your time than the wall in full. The whole service is funded by that loop, so we need to know when it breaks. Legal basis: our legitimate interest in understanding and improving our own service, Art. 6 (1) (f) GDPR. You can object to this at any time under Art. 21 GDPR; see section 17.
• Counts from our own surveys, shown to companies: to show businesses, advertisers among them, what developers use and decide, as counts and proportions across accounts, never for fewer than five accounts and never an individual answer (section 6). Legal basis: our legitimate interest in financing the service, Art. 6 (1) (f) GDPR. You can object at any time under Art. 21 GDPR; see section 17.
• Offerwall opens, for one more of our own surveys: to give you the extra surveys terms section 8 promises after an attempt that earned nothing. Legal basis: the contract between us, Art. 6 (1) (b) GDPR.
• A deleted account's GitHub id, as a hash: so that deleting an account and signing in again is not a way to a second signup bonus and a fresh free allowance, which would spend what pays for everybody else's. Legal basis: our legitimate interest in preventing that, Art. 6 (1) (f) GDPR.
• The sponsored line: to fund the service. Advertising is what pays for the model calls your credits are spent on. Legal basis: our legitimate interest in financing our own service, Art. 6 (1) (f) GDPR. You can object at any time under Art. 21 GDPR, and you do not have to write to us to do it — CLIXAD_SPONSOR=0, or { "sponsor": false } in the config file, stops the request being made at all. Because nothing is stored on or read from your device for it, this does not require consent under § 25 TDDDG either.
• Waitlist email: to notify you once that Clixad has opened. Legal basis: your consent, Art. 6 (1) (a) GDPR, given when you submitted the form.
• Visit statistics: to understand how many people reach the site and where they come from, so we can improve it. Legal basis: our legitimate interest in a needs-based design of our website, Art. 6 (1) (f) GDPR. Because no information is stored on or read from your device, this does not require consent under § 25 TDDDG (the act renamed from TTDSG in 2024).

14. processors and hosting

We use the following service providers:

• Vercel Inc. for hosting and delivery of this website, and for the aggregate visit statistics described above.
• Supabase for the database holding accounts, balances and the credit ledger (EU region, Ireland).
• Render Services, Inc. for running the service that the command line tool talks to (EU region, Frankfurt).
• OpenRouter, Inc. for routing each request to the operator of the model you selected, on the footing set out in section 4.
• Stripe Payments Europe, Ltd. as payment service provider, if and when you buy credits, and for the payments, invoices and refunds of advertisers (section 10).
• The European Commission, which runs the VIES service, for confirming an EU VAT number an advertiser gives (section 10).
• Make Opinion GmbH (CPX Research) as operator of the CPX Research offerwall, as described in section 5.
• Mailjet, a brand of the Sinch group (Sinch AB (publ), Sweden), for sending the one email that tells waitlist subscribers that Clixad has opened, as described in section 12.

Render Services, Inc. is engaged as a processor under a data processing agreement pursuant to Art. 28 GDPR, which forms part of their terms of service. Where a provider in that list processes data outside the EU or EEA, the transfer is safeguarded by an adequacy decision or the European Commission's standard contractual clauses.

ADtention is deliberately not in that list, and the reason is not an oversight. They do not process anything for us or on our instructions: your own machine connects to them, and what they do with that request is theirs to decide, which makes them a separate controller rather than a processor. Calling them a processor would describe a relationship that does not exist. Section 8 sets out what the request contains, what they can and cannot infer from it, and how to stop it.

TheoremReach is not in that list either, and for the same reason. Our server makes no request to them. Your browser opens their wall and connects to them directly, carrying the link section 5 describes, and the page it loads is theirs. What they do with that visit is theirs to decide, which makes them a separate controller rather than a processor, so the transfer sentence above does not cover them.

TheoremReach Inc. is established in the United States. Its privacy policy names the European Commission’s standard contractual clauses as the safeguard for transfers of personal data from the EEA.

15. how long we keep it

• Answers to sponsored surveys, and when your GitHub account was created: for as long as your account exists. When it is deleted, the date goes, and the answers stay without anything that identifies you, because the counts a company paid for are made from them. The delivery record for a counted response keeps your account identifier for 30 days and then keeps only the count.
• Booked lines shown to you: 30 days with your account identifier, then only as a count with no account.
• Advertiser accounts and their campaigns: for as long as the advertiser account exists. Invoices, payments and refunds are kept for the statutory retention periods under German tax and commercial law, even if the account is deleted before they expire.
• Account data, balance and ledger: until you delete the account, on the account page or by asking us. Deleting it removes your email address, your GitHub id, login and the date your GitHub account was created, your access token and your referral code. The balance and its ledger stay, without anything that identifies you, because the daily budgets every account shares are summed from them, and a purchase is also kept under the next point.
• Purchase records: for the statutory retention periods under German tax and commercial law, even if the account is deleted before they expire.
• Reward records: for as long as the account exists, and after it is deleted without anything that identifies you. This covers both ways of earning — an offer completed on one of the offerwalls, and a sponsored line that earned. The transaction id has to outlive the reward itself, because it is what stops the same reward being paid twice or charged back twice.
• Refused requests, offerwall opens, TheoremReach visit references and screenouts: for as long as the account exists, and they go with it when it is deleted. Unlike the reward records above, nothing depends on these outliving the account — they pay nothing out and prevent nothing, so there is no reason to keep them once you are gone.
• Answers you rated: for as long as the account exists, and they go with it when it is deleted. This is the only place we hold the content of a conversation, and it is there only because you chose to put it there.
• Answers to our own surveys: for as long as the account exists, and they go with it when it is deleted. Kept whether or not they were credited, because an answer that failed a check is still an answer somebody gave us.
• Your preferences: until you change them, and they go with the account when it is deleted.
• A deleted account's GitHub id, as a one-way hash: for 12 months after the deletion. For the first 30 days the same GitHub account cannot make a new Clixad account, and after that a new one is made without the signup bonus. When the 12 months are over the hash is removed.
• Waitlist addresses: until you ask us to delete them.
• Server logs: deleted or anonymised by our hosting providers after a short retention period.

16. sharing

We do not sell your data, and nothing about your code or your prompts ever reaches an advertiser. Almost everything we pass on goes to the providers listed in section 14, on our behalf and on our instructions. Three things sit outside that sentence, and all three are better named here than left for you to find: one is something we pass on for somebody else’s purposes, and the other two are not things we pass on at all.

A company that sponsors a survey receives no personal data from us. It sees how many people chose each answer once at least ten responses are counted, and nothing about who they were. Section 7 sets out the rest. A business that books a line in the terminal receives counts per week and place in the same way, as section 8 describes.

Your email address goes to CPX Research for their own purposes. We send it with the offerwall link and with the survey list — section 5 sets out exactly when — and Make Opinion GmbH uses it to recognise the same respondent across the publishers they serve, not only across ours. That is their purpose rather than ours, so describing it as processing on our behalf would be wrong. The other offerwall is not sent your email address. (Section 4 covers the other limit on that phrase: what a model provider may keep once your request reaches it.)

The sponsored line is not something we pass on at all, and that is the point. We do not send your address to the ad network; your own computer connects to them, and they see it the way any website you open sees it. What we do is ship the software that makes that connection, which is why it is written up in section 8 rather than left for you to notice, and why the switch that stops it is a switch on your machine rather than a request to us.

Beyond that, when you choose to open an offerwall you are dealing directly with the network that runs it, whether that is CPX Research or TheoremReach, and what you tell them there is theirs, under their own policy. We are not given it.

The answers to our own surveys are the third, and they are the one people expect us to sell. We do not. No individual answer goes to a sponsor or to anyone else, and what leaves us is aggregated across accounts and floored at five — section 6 sets out why the floor is there and what it is protecting against.

17. your rights

Under the GDPR you have the right to:

• access the data we hold about you (Art. 15)
• have inaccurate data corrected (Art. 16)
• have your data erased (Art. 17)
• restrict processing (Art. 18)
• receive your data in a portable format (Art. 20)
• object to processing based on legitimate interest (Art. 21)
• withdraw your consent at any time, with effect for the future (Art. 7 (3))

Two of them you can exercise yourself on the account page of our site (/account, signed in): “Download my data” gives you your account, every balance change, your rewards, your answers to our own surveys, the answers you rated, your login streak, your preferences and your model use per day as a file, and “Delete my account” deletes the account as section 15 describes. For anything else, or if you would rather not use the page, email info@clixad.io. No particular form is required; write from the address on the account, or tell us your GitHub login, so we can tell which account you mean. You also have the right to lodge a complaint with a supervisory authority, in particular in the member state of your residence, place of work, or the place of the alleged infringement.

18. changes to this policy

We will update this policy when the service changes. The current version always applies and is published on this page.