What Should an AI Tutor Charge For? The Case Against Selling Tokens

Open the pricing page of almost any generative AI tool today and you will find a variation of the same equation:

• "50 credits per day"
• "1,000 message turns per month"
• "Unlimited tokens (fair use policy applies)"

For a chatbot or a code-completion plugin, metering by tokens makes sense. You are reselling raw compute, so you bill for compute consumed. The unit you sell is the unit you buy, and the accounting is honest.

For a tutor, that equation starts to look wrong — and the more of our own cost data we collect, the less defensible it gets.

We should say up front what this post is and is not. HeyPapin does not charge anyone anything today. There is no payment page, no subscription, no card on file. What follows is our thinking in the open, with the numbers we actually have, about a question we have not settled: what should an AI tutor charge for?

---

1. Metering compute makes a student ration their curiosity

Start with the part that has nothing to do with margins.

When a student sits down before an exam, their problem is never:

"I wish I had 100 API prompt credits today."

It is specific, stressful, and urgent:

"I have an exam at 2:00 PM and I still don't understand how Raft handles a network partition."

Sell them credits, and you install a second calculation on top of the one they came to do. Will asking about this error message burn three of my remaining credits? Should I save the last five for tonight? Every question now has a price tag attached, and the cheapest move is always to stop asking.

That is precisely the wrong incentive for Socratic teaching, which runs on fearless exploration — interrupting mid-sentence, testing a wrong hypothesis, asking the small embarrassing question you would never raise in a lecture hall. A meter ticking in the corner suppresses exactly the behaviour the method depends on.

HeyPapin does have a daily turn limit. It is 13, and we want to be clear about what it is: an abuse guardrail that keeps one automated script from draining a student project's API budget overnight. It is not a product, it is not a currency, and we have been steadily removing the word "credits" from the interface because that word frames it as one.

---

2. What our own cost data says so far

Here is what sixteen days of real sessions produced, from 69 visitors and 4,080 turns:

┌──────────────────────────────────────────────────────────────┐
│  20 Aug – 4 Sep 2026                                         │
├──────────────────────────────────────────────────────────────┤
│  Total model spend (estimated)                    ~$15       │
│  Measured window (28 Aug – 4 Sep, 1,961 turns)     $7.21     │
│  Last four days                            $0.74 per day     │
├──────────────────────────────────────────────────────────────┤
│  Spend per visitor:  p50 $0.00   p80 $0.00                   │
│                      p90 $0.15   heaviest $2.79              │
└──────────────────────────────────────────────────────────────┘

The distribution has a long tail, which is ordinarily good news for a subscription: most people cost almost nothing, and a handful cost real money. Averages survive that shape comfortably.

However, we do not get to draw that conclusion yet, and it is worth explaining why rather than quietly rounding it off. A single account accounts for 53% of all turns, and that account is almost certainly our own testing. Meanwhile a p50 of exactly $0.00 most likely describes visitors who opened the page and left, not thrifty learners. Strip both groups out and the number of students who genuinely studied here is small.

So the figure that decides a price — cost per active student per month — does not exist yet. We can compute what it would need to be: for a $7.99 subscription at a 60$3.20 per person, and the number to watch is the p90, not the median. What we cannot do is claim we have measured it.

---

3. Per-lesson pricing feels right and dies on arithmetic

The intuitive alternative is to sell the thing the student actually wants. Not tokens, not turns — one concept, understood. Charge fifty cents for a lesson, and both sides know exactly what was bought.

We liked this idea a great deal, and then we did the payment maths.

A card charge costs roughly $0.30 in fixed fees plus 2.9$0.50 transaction that leaves about $0.19 — before a single token has been spent on the lesson itself. Roughly 63% of the price disappears into payment processing, and that is a structural cost that no amount of model efficiency will recover. The lesson could cost us nothing to generate and the economics would still be poor.

There are ways around it: bundling several lessons into one charge, prepaid packs, wallet top-ups. Every one of them reintroduces something that looks a lot like credits, which is where this post started. That tension is unresolved, and we would rather say so than publish a pricing table we already know is wrong.

---

4. The part that is actually built

One piece of this is not speculative, because selling learning outcomes only means anything if you can tell whether learning occurred.

Most tools cannot. Chat eight times and a progress bar fills, regardless of whether you said anything substantive. Our first version was no better: it estimated progress from how much had been said, which meant eight lines of small talk registered as a finished lesson.

That is gone. Progress is now computed from board events rather than prose:

• Planned steps come from plan_board.steps — the tutor's own plan for the lesson.
• Questions asked are counted when a blank challenge node appears on the board.
• Questions answered are counted only when the student's reasoning replaces that node.

A lesson cannot reach Mastered unless asked > 0 && answered >= asked. Read that condition carefully, because it constrains the tutor more than the student: if HeyPapin never tested you, it is not allowed to record that you understood. The progress bar also pauses while a question is open, so drawing more boxes cannot advance it while you still owe an answer.

This exists for pedagogical reasons — we built it because the old bar was lying. But it also happens to be the prerequisite for ever charging by outcome, since an outcome you cannot verify is just a word in a marketing sentence.

---

5. What we have not decided

Three directions are open, and each has a real objection we have not answered:

Our current bias is toward a subscription, with lessons as a way to structure learning rather than a unit of billing. But that is a working position, not an announcement, and it will change if the cost-per-student number comes back badly.

Products fail when their business model fights their user experience. Charging per question does exactly that to a tutor. Knowing what to charge instead requires data we are still collecting — and publishing a confident pricing page before that data arrives would be its own kind of dishonesty.

---

#UnitEconomics #EdTechBusiness #PricingStrategy #SaaS #MasteryLearning #HeyPapin