How Clixad is funded: the arithmetic, and where it strains

Clixad, a terminal coding agent with no subscription, funds model API calls through an offerwall where 100,000 credits equal one US dollar of advertiser payout, with a fixed exchange rate in code. The platform keeps one third of each completed offer's payout and uses the remaining two thirds to cover model costs at a 1.5× markup, yielding a 33% gross margin on purchased credits and a profit-positive model per completed offer. However, most survey attempts end in screenouts that pay nothing, and a single completed offer at the low end (40,000 credits) buys 166 turns on GPT-5 Nano but only one turn on Claude Opus 5 and zero on GPT-5.2 Pro, highlighting the strain at the high end of the model lineup.

How Clixad is funded: the arithmetic, and where it strains Clixad https://clixad.io is a terminal coding agent with no subscription. You earn credits by completing tasks on an offerwall in your browser, and credits pay for real model API calls through a gateway. The exchange rate is fixed in code: 100,000 credits is one US dollar of the payout an advertiser hands over. A new account starts with 5,000 credits, and a free account can earn at most 500,000 credits a day. The uncomfortable half, up front: most survey attempts end in a screenout that pays nothing. That is normal across the offerwall industry, not a fault in our integration, and it is the single thing worth knowing before you sign up. This post is the arithmetic behind all of that, and the places the model is thin. The exchange rate and the two levers There are only two numbers that decide whether Clixad makes money, and they live in one file, packages/pricing/src/config.ts . Everything else is derived from them so usage can never be sold below cost. The first is a markup of 1.5, which applies when someone buys credits with a card: $1 buys 100,000 credits, and those credits are charged against real API cost at 1.5× that cost, so a bought dollar carries a 33% gross margin. Buying is optional and never required; it is a shortcut past the wait, not the funding model. The second is the one that matters here: a platform margin of one third. For a completed offer that pays the platform some amount, a third of that amount is kept and the other two thirds fund model usage at cost. Because the markup and the margin cancel exactly — 1 - 1/3 × 1.5 = 1 — the arithmetic collapses to one clean identity: one dollar of offer payout becomes 100,000 credits , and those credits buy the two thirds of a dollar of raw model calls that the platform did not keep. That identity is also the currency factor configured on the offerwall's side, so the two are cross-checked on every postback. So the model is profit-positive per completed offer by construction: the platform keeps a third of whatever an offer paid, whether that is four cents or three dollars. What the construction does not promise is that offers get completed, or that a third of a small payout is worth much. Both of those are further down. What a turn actually costs A turn is one model call: your prompt and the context go up, a reply comes back. The table below prices a turn of 20,000 input tokens and 1,500 output tokens — a normal coding exchange with a few files in context — on every model Clixad offers, straight from the pricing engine. The models are ordered cheapest turn first, which is also the order the /model picker shows them in. | Model | Credits per turn | Turns per completion | |---|---|---| | GPT-5 Nano | 240 | 166 | | Gemini 2.5 Flash-Lite | 390 | 102 | | DeepSeek V4 Flash | 484 | 82 | | Gemini 3.1 Flash-Lite | 1,088 | 36 | | Kimi K2 | 2,228 | 17 | | Kimi K2.7 Code | 3,038 | 13 | | Claude Haiku 4.5 | 4,125 | 9 | | Gemini 3.6 Flash | 6,188 | 6 | | Claude Sonnet 5 | 8,250 | 4 | | GPT-5.2 | 8,401 | 4 | | Kimi K3 | 12,375 | 3 | | Claude Opus 5 | 20,625 | 1 | | GPT-5.5 | 21,750 | 1 | | GPT-5.2 Pro | 100,800 | 0 | The spread is the point. The most expensive turn, on GPT-5.2 Pro, costs 420 times the cheapest, on GPT-5 Nano. That is not a Clixad number, it is the providers' own price list; ad funding only decides who pays it. It is also why the bottom of that table is where the model is comfortable and the top is where it needs a real offer behind every few turns. What one completed offer buys Read the third column of the table as the honest unit. One completed offer at the low end of what the wall has paid — 40,000 credits — is 166 turns on the cheapest model and a single turn on Claude Opus 5. On GPT-5.2 Pro it rounds to zero: one completion does not buy one turn of the most expensive model, and the table says so rather than hiding the row. The other two figures frame it. The signup bonus is 5,000 credits , which is roughly twenty turns on the cheapest model and about one on a mid coding model like Kimi K2.7 Code — enough to try the tool before you ever open the wall, and deliberately not enough to lean on. The daily cap is 500,000 credits , the credits from $5 of payout, which is around 24 turns on Claude Opus 5 or a couple of thousand on GPT-5 Nano. A free account cannot earn past that in a day, on purpose. What offers actually pay Everything above converts a payout into credits at a fixed rate. What that hides is how little the payout itself is predictable. These are amounts I have actually seen credited on the CPX wall in Germany, on completion, grouped by how long the offer claimed to take. | Claimed duration | Credited on completion | |---|---| | 3 minutes | 40,000–42,000 | | 4 minutes | ~70,000 | | 6 minutes | 45,000–107,000 | | 8 minutes | ~137,000 | | 12 minutes | 101,000–142,000 | | 16 minutes | ~300,000 | Duration barely predicts payout. Two six-minute surveys have differed by more than a factor of two, and an eight-minute survey has paid more than a twelve-minute one. The reason is that the advertiser is buying a respondent who fits a profile, not the minutes you spend, so the price attaches to who you are rather than to the clock. That is why every payout on the site is quoted as a range, never as a "3 minutes = 40,000 credits" point value: a point value would be a number I cannot stand behind for the next person. The screenout, said plainly Here is the part a pitch would bury. The most common outcome of starting a survey is not a payout. It is a screenout : a few questions in, the survey decides you are not the respondent it is paying for, and it ends with no credit. You spent the minutes and earned nothing. This is normal. It is how survey offerwalls work across the whole industry, because the advertiser only pays for completes that match the panel it commissioned, and matching is decided partway through rather than at the door. It is not a bug in the Clixad integration and I cannot engineer it away, because it happens entirely on the offerwall's side before any postback reaches us. What follows from it is that the credits in the tables above are per completion , and a completion can take several attempts. A user who wants a steady, predictable top-up will be happier buying credits than grinding surveys, and a user who is fine treating the wall as intermittent will do well on the cheap models where one completion is a hundred turns. Both of those are real and I would rather write them down than let someone learn the screenout rate the hard way. The signup bonus exists partly so the first thing you meet is the tool, not the wall. The Lootably experiment I didn't ship Clixad's code carries a second offerwall, Lootably, wired in behind the same postback contract as CPX. It is built and it is verified end to end. It is also not live, and the reason is worth putting in the open rather than leaving as a dead code path someone finds later. When I looked at the actual Lootably catalogue for German desktop web — the audience most likely to be running a terminal coding agent — it was almost entirely purchases, subscriptions and app installs. Those are fine offers for a rewards app; they are a bad fit for "earn a few credits to keep coding", because they ask the user to spend money or install a phone game. The one category that read as low-friction, a "one click" section, led out through TimeWall into a third wall, whose single available campaign paid $0.023 — about 2,300 credits — for yet another signup. So I finished the integration, confirmed a real completion credited correctly, and then left the wall unlinked. No screen in the product opens it. Shipping a second wall that offered our users worse choices than the first would have been motion without improvement, and the honest state of the code is: the abstraction proved it was the right size when a second network arrived, and the second network did not earn its place in the UI. CPX is the only live wall. Where this model can fail Three ways, none of them hypothetical. Crediting is unreliable across the industry. The whole earn path depends on a third party firing a server-to-server postback correctly and on time. Postbacks get delayed, dropped and disputed; a conversion can be charged back long after the credits were spent, which is why the code has to let a claw-back push a balance negative. When a network simply does not credit a completion, the user did the work for nothing and the fix is not on my side of the wire. I can make our handling correct and idempotent; I cannot make the other end reliable. Ad-funded developer tooling is contested. A fair number of developers think ads have no place near a coding tool at all, and the best-resourced entrant in this category stepped away from advertising inside six months. I am not going to argue that ads in a dev tool are fine. The trade is concrete: you pay with attention and completed offers instead of money, the ad is a page in your browser rather than anything in your editor, and no code or prompt leaves for the advertiser. Whether that trade is acceptable is a judgement I would rather you make with the numbers than with my reassurance. The margin is thin where the payouts are small. A third of a completed offer is real profit, but a third of forty cents is thirteen cents, and a funnel where most attempts screen out means the platform sees many wall opens per credited completion and earns nothing on the rest. The unit economics are sound per completion and lossy per attempt. That is survivable at the cheap end of the model table, where one completion is a hundred turns, and it is genuinely tight at the expensive end, where one completion is a single turn or none. The daily cap is partly an admission of that: it bounds the platform's exposure as much as the user's earning. None of that is a reason the model cannot work. It is the set of things I would want to know if someone else had built it and asked me to trust it. The books are the argument; there is no other one. Sources - Credit rate, markup, platform margin, signup bonus and daily cap: Clixad's own pricing engine, packages/pricing/src/config.ts and credits.ts creditUsd = 1e-5 , markup = 1.5 , platformMargin = 1/3 , signupBonusCredits = 5000 , maxAdRewardUsdPerDay = 5.0 . - Per-turn credit figures: creditsForUsage over the catalogue in packages/pricing/src/models.ts , prices read from OpenRouter on 26 July 2026, recomputed by the test beside this post. - Offer payouts: amounts observed on Clixad's own CPX wall in Germany, credited on completion, July 2026. The same measurements the demo clips use, in apps/video/src/numbers.ts . - CPX Research, integration documentation https://www.cpx-research.com/main/en/doc.php , for the offerwall and postback mechanism the earn path is built on. Read 6 August 2026. - The Lootably integration and its unshipped state: the postback route and wall builder in this repository, and the observation that no screen in the product links the Lootably wall.