clixad back

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 the 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 and how many tokens it consumed, 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: the offerwall, which you open in your browser, and the sponsored line in the terminal, which is fetched from an ad network directly and therefore shows them your IP address the way any website would. Section 7 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

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 from the command line with GitHub, using GitHub's device flow. We ask GitHub for your user id, your login name and your email address. From that we store:

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.

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 an action — a signup form or a survey — on the CPX Research offerwall, operated by Make Opinion GmbH, Elfenallee 5, 13127 Berlin, Germany. When you open the wall we hand it 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. We do not send your GitHub login or your name.

The list of surveys shown on our page is asked for on your behalf, by our server rather than by your browser. 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 Make Opinion GmbH on their page, under their own privacy policy: which offers you are shown, the demographic questions their partners ask, and whatever they store about your participation. They are a German company, so this part involves no transfer out of the EU on our side. We only receive the result — a transaction id, that internal identifier, the payout, and whether it credited or was charged back — and we store it so the same reward cannot be paid twice and so the daily limit can be applied.

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. Nothing about what happens inside an offer, which we never see. We keep the two apart because the list is only worth showing if it works better than the whole wall, and recorded as one thing they cannot be compared.

Make Opinion GmbH also tells us when an attempt ended without credit — 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, and the time. 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. It credits nothing and moves no balance; it is kept apart from the credit records for exactly that reason.

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 13.

7. 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.

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:

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.

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 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, 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 13.

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. The line is also silent on its own whenever output is piped or redirected, in CI, and under NO_COLOR.

8. buying credits

Buying credits is optional and never required. Payment is handled by Stripe Payments Europe, Ltd. on Stripe's own payment page. We send Stripe only our internal account identifier and which pack you chose; the card details are entered with Stripe, and 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.

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

9. 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.

10. 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.

11. purpose and legal basis

12. processors and hosting

We use the following service providers:

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 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 7 sets out what the request contains, what they can and cannot infer from it, and how to stop it.

13. how long we keep it

14. 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 12, 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.

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. (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 7 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 the offerwall you are dealing with CPX Research directly, 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.

15. your rights

Under the GDPR you have the right to:

To exercise any of these, email info@clixad.io. No particular form is required. There is no self-service delete button in the tool yet, so account deletion goes through that address; write from the address on the account, or tell us your GitHub login, so we can tell which account to delete. 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.

16. changes to this policy

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