AI Tools Police
Reader-supported — we may earn a commission from links, at no cost to you. Rankings are never sold. How we investigate →

Analysis · Consumer policy · Wave 1 data

AI Credits Need an Exchange Rate

Europe's consumer authorities set out a non-binding principle for games: show what a virtual coin costs in real money. Forty-seven of the 73 active products in our audit meter through the same structure, with two problems games do not have, and no rule at all.

By Mucahit Kaya · Founder and EditorAug 19, 2026~7 min read

The claim

A product priced in credits should have to publish the real-money value of a credit and the credit cost of each operation, because a price quoted in a currency with no published exchange rate is not a price a buyer can compare.

Forty-seven of the 73 active products in our pricing audit are documented as metering what you get through a currency the vendor invented. You buy credits, tokens, minutes, generations or units, and you spend that currency inside the product at a rate the vendor sets and, in many cases, does not publish.

Twenty-five operate no such system at all, so this describes a large part of one publication's coverage, not the market. Within that part, the structure has a consequence that survives every argument about whether AI is overpriced: when the denomination is private, the headline price stops being comparable. Two products at $20 a month are not comparable if one gives you 400 credits that buy an unstated amount of work and the other 1,000 credits that buy a different unstated amount.

Our Pricing Transparency Audit coded 76 products across 15 categories against a pre-registered instrument, 2,812 coded values in total, from vendor documents only. 72 carry a published score.

What the documents answer

Headline price

Products it applies to
72 scored
Published in full
67 (93.1%)

Credit unit defined

Products it applies to
48
Published in full
38 (79.2%)

Rollover or expiry of credits documented

Products it applies to
48
Published in full
38 (79.2%)

Credit-to-output rate published

Products it applies to
48
Published in full
20 (41.7%)

Whether a failed generation is charged

Products it applies to
64
Published in full
7 (10.9%)

The 48 needs explaining: it is not a count of products with a credit system. 47 active products are documented as operating one. The 48th is Google Veo, sold through two live surfaces that answer the question differently, one metering through a credit unit, one billing per second, with nothing in the codebook deciding which governs. It stays in the denominator as an open question, not a vendor withholding anything. The 64 is a different question: products with a metered generation step, which makes the failure question askable.

Read down the column and the shape is clear. Vendors in this corpus say what a credit is called. They mostly say whether unused credits survive the month. What they are markedly less likely to say is the number connecting the two: how much output a credit actually buys. Of the 48, 20 publish that rate in full and 18 publish it partially. Nine publish nothing on it, and the 48th is the record our own instrument could not evaluate.

The failed-generation figure is the sharpest thing in the dataset. 57 of the 64 products with a metered generation step leave a buyer without a usable answer on whether a failed output costs anything. Failure is a foreseeable outcome rather than an exotic one: a model can refuse, a render can break, an output can arrive unusable. This study measured no failure rates and does not need to: a foreseeable outcome that consumes the currency is a term the documents must settle, whatever its frequency.

For seven the documents settle it, which establishes it is writable. Five state that a failed generation is not charged. Recraft AI's terms state the opposite outright: credits already consumed are not returned where a request does not complete. The seventh, Apify's robots.txt checker, we coded as charging on its platform's pay-per-event billing documentation, not a statement about failed generations. For the remaining 57 no publishable answer exists in the documents, and they are not one thing: 54 are vendor silence, one a help-centre article we could not retrieve, one a keyword check too thin to attribute, one a record our instrument could not resolve. The 54 are the finding, and they leave a buyer unable to plan.

Europe's consumer authorities set out a principle for the easier case

In March 2025 the EU's Consumer Protection Cooperation Network published Key Principles on In-game Virtual Currencies (21 March 2025, Ref. Ares(2025)2303808). Its first principle addresses exactly the structure described above. The action point reads: "When in-game virtual currency or in-game digital content or services are offered for sale, their price in real-world money should be clearly and prominently displayed".

The reasoning transfers: a virtual currency adds a layer that makes the true cost harder to assess, and price information is material information a consumer needs to decide. It goes further than the headline rule, treating mixing several currencies and requiring several conversions before a purchase as practices that obscure cost.

Two qualifications, and they matter more than the quotation.

This guidance is not binding. It is a set of non-exhaustive principles for traders in the gaming sector. Its force comes from asserting that existing European consumer law already applies, and it names the provisions the price principle rests on: Articles 6(1)(d) and 7 of the Unfair Commercial Practices Directive, and Article 6(1)(e) of the Consumer Rights Directive.

It covers video games. The scope is explicit and it has not been extended to AI. Nobody should read the principle as already governing a credit-metered image generator.

The related instrument is the Digital Fairness Act, still in preparation and not formally proposed. There is no legislative text to point at. But its evidence base, the fitness check published on 3 October 2024, SWD(2024) 230 final, already carries the problem.

Its glossary defines in-app currencies as virtual currencies, excluding crypto and central bank money, used in apps such as video games and social media as a type of payment (p. 6). Its representative consumer survey of 10,000 consumers across 10 Member States found that 29% of respondents had met a situation where the real price of a virtual item was not clear because it was shown only in the app's own currency (p. 27, repeated at p. 162). Its public consultation records that "53% supported more price transparency when buying virtual games with intermediate virtual currency" (p. 138, n=221 stakeholders), a games-scoped finding in the source's own words. And on what the recent EU digital Acts leave untouched, it states the practices it identified are "either not addressed at all (e.g. problems related to video games such as the use of in-game currencies) or are addressed only insofar the role of platforms is concerned" (pp. 67-68).

The glossary definition is app-wide rather than game-specific, naming social media alongside games. The Commission's own evidence base already treats in-app currency pricing as an identified problem that the recent digital Acts do not address. What does not exist is a rule. Anyone claiming AI credits are already regulated in Europe is claiming more than the record supports, and anyone claiming the problem is unrecognised is claiming less.

Why AI is the harder case

The intuitive reading is that AI is the easier case: less impulse design, more business buyers. This study coded documents, not users, so take that as an assumption rather than a finding. Grant it anyway: on disclosure AI is still harder, for two reasons that do not apply to a game.

A game item's price is posted before you buy it. Whatever the sword costs in coins, and whatever discounts move that figure, the number is on the screen in advance. An AI operation's cost is not posted that way, because it varies with the model, the length of the output, the resolution, the duration. A single published number cannot describe it honestly, which is a genuine problem and not an excuse.

And a posted game item is delivered: you buy the sword at its posted price and you have the sword. A paid random draw is different, and the loot-box problem is one European authorities have long worked on. But a draw returns something from a disclosed pool, and the randomness is the product. An AI generation can consume the currency and return nothing, and the failure is not the product. That is the loss 57 of 64 applicable products give no publishable answer on.

So AI cannot simply adopt the game rule. It needs one built for variable cost and for failure.

An AI Credit Disclosure Standard

Specific enough for a vendor to adopt and a regulator to point at. Six clauses.

1

Clause
Unit value
What it requires
The real-money value of one credit at each purchase tier, as a number, undiscounted
What a buyer can then do
Convert any credit figure into money

2

Clause
Operation cost
What it requires
Credits consumed per model and per operation, in a table, not prose
What a buyer can then do
Price the work before buying

3

Clause
Variance band
What it requires
Where cost varies, a stated minimum and maximum, and the factor that drives it
What a buyer can then do
Budget the worst case, not the marketing case

4

Clause
Failure and retry rule
What it requires
Whether a failed, refused or errored generation consumes credits, and whether a retry does
What a buyer can then do
Know the cost of a bad run

5

Clause
Expiry and rollover
What it requires
When credits expire and whether unused credits carry forward
What a buyer can then do
Value the balance actually held

6

Clause
Rate history
What it requires
A dated, public log of every change to clauses 1 to 5
What a buyer can then do
See whether the rate is stable

Clause 3 answers the variable-cost problem. A band is not a fudge. A vendor that said, say, 12 to 90 credits for a video depending on duration has told a buyer everything needed to budget, and told the truth, which a single averaged number would not.

Clause 6 does the most work. A rate that can be changed silently is not a disclosure, because the number compared at purchase can differ from the number billed later. Publishing the price and quietly moving the rate would satisfy every other clause and defeat all of them.

Clause 4 costs a sentence to write. Six in our corpus wrote it squarely, and a seventh's platform billing documentation settles it.

What transparency should mean

The AI Act's transparency duties run in several directions, but the one that reaches the buyer of these products is about marking output. Article 50 requires providers to mark synthetic audio, image, video and text as artificially generated in a machine-readable format, and deployers to disclose deepfakes and AI-generated text published on matters of public interest. It contains no provision about what generating that content costs.

That is a real obligation and a narrow definition: a marking duty on the seller, a disclosure duty on the buyer who publishes, and nothing in either about what the seller must tell the buyer about price. A corpus where 67 of 72 products publish a headline price and 20 of 48 publish in full the rate that gives that price meaning is one where the most visible number is the least informative.

Transparency in AI should mean disclosing that content was generated by a machine, and disclosing what generating it costs.

What would change our mind

The strongest objection is that our instrument cannot see the place the rate is most likely to be shown. The variable we use to record where a credit rate lives permits only document locations — pricing page, docs or help centre, terms, several of these, or absent — and has no value at all for a rate displayed in-product at the point of generation, which is exactly where a vendor would naturally put it: a live credit balance beside the button, and a per-action cost next to it. A documents-only audit therefore cannot distinguish a rate that is not published from a rate published in an interface we never signed into.

If the 27 products that publish the rate partially or not at all — the 18 partial and the 9 that publish nothing, setting aside the single record our own instrument could not evaluate — turn out to display per-operation credit costs inside the product, then buyers at the point of use are not facing the information asymmetry this piece describes, and our finding is about where a disclosure lives rather than whether it exists.

What would settle it is a wave-2 in-product check: sign into those 27 and record whether a per-operation credit cost is visible at the moment of generation. If a clear majority show it, our claim should narrow to pre-purchase comparability, which is a real problem but a substantially smaller one than the piece argues.

Where these numbers come from

Every figure in this piece is drawn from the Pricing Transparency Audit, read from the reports its own tooling generates rather than recomputed here. The full dataset, the codebook, the protocol and the log of every correction are published open, so any number below can be checked against the data it describes.