Every proofreading vendor publishes a price. Almost none of them publish the number you actually need, which is what this feature will cost me per user per month. The gap between the two is where budgets die: a pricing page says "$25 per million characters," your product re-checks a 40,000-character document every time someone pauses typing, and the invoice arrives with a digit you didn't plan for.
This article models the real bill. It covers the four billing models you'll encounter, the four multipliers that quietly inflate every one of them, and worked cost math for three products at three different scales. Disclosure: we build AmberPen, and its pricing appears below alongside everyone else's — including where a competitor is cheaper.
The four billing models
Per character is the model most proofreading APIs use, including AmberPen and Sapling. You pay for the text you send. The advantage is that the unit maps directly to something you can measure and cap in your own application before you ever make the request: you know the length of the document. Watch for the definition of "character" — Unicode code points, UTF-8 bytes, and grapheme clusters give different answers for emoji and non-Latin scripts, and CJK text often carries a multiplier (Sapling weights it at 2.5×; AmberPen does not weight by script).
Per token is what you pay when you build proofreading on a general-purpose LLM. The unit is the model's tokenizer, not your text, and you pay on both sides of the request: your document goes in as input tokens, and the corrected rewrite comes back as output tokens at a higher rate. This is the model with the widest gap between demo cost and production cost, for reasons covered below.
Per seat is Grammarly's model, and it's a fundamentally different product shape — you're buying licenses for humans, not capacity for an application. It's the right model if you're deploying a writing assistant to employees. It cannot price a feature inside your own software, where "users" may be a hundred thousand anonymous visitors.
Free, plus your infrastructure covers self-hosted LanguageTool and embedded Harper. The license costs nothing; the VM, the redundancy, the upgrades, and the engineer who owns all three do not. We priced that route separately in the true cost of self-hosting — the short version is that it wins at extreme volume, in air-gapped environments, and at zero budget, and loses almost everywhere else.
Why per-token pricing surprises people
If you prototype on a chat model, your intuition anchors to the input price. Three things then multiply it.
You pay for output, too — at roughly the volume of your input. A proofreading response is a rewritten version of the document. Correct a 4,000-character page and the model emits ~4,000 characters back. Output tokens are typically billed at three to five times the input rate, so the return trip is usually the larger half of the bill.
Reasoning tokens are invisible and billed. Reasoning-enabled models generate internal tokens you never see and always pay for. Their volume varies with the input, which means the same document can cost meaningfully different amounts on two different days.
Retries and failures are billed. A response that fails JSON validation, arrives truncated, or drifts from the source text still consumed tokens. Any production LLM proofreader has a retry path, and every retry is a second full-price request.
A rough conversion for planning: English runs about four characters per token, and a rewrite roughly doubles that (input plus output). So 1M characters of proofreading is on the order of 500K tokens of billable traffic before reasoning and retries — say 600–800K in practice. At an illustrative mid-tier rate of $0.60 per million input tokens and $2.40 per million output, that's roughly $0.75–$1.10 per million characters of raw model cost — genuinely cheap, and the reason the prototype looks so attractive.
Then the variance arrives. The same workload with a reasoning-heavy model at $3/$15 per million lands closer to $6–$9 per million characters, and the number moves when you change models, when a provider deprecates the one you standardized on, or when a document happens to trigger long reasoning. You're not buying a price; you're buying a distribution. The other failure modes of that architecture — drifting offsets, mangled proper nouns, non-determinism — are covered in where ChatGPT breaks as a grammar checker.
The four multipliers that inflate every model
Whichever unit you're billed in, these apply.
Re-checks. This is the big one. A writing app doesn't proofread a document once — it proofreads on every pause. A 40,000-character chapter checked 80 times in an afternoon's writing session is 3.2M characters billed for one document. Naive implementations routinely bill 50–100× the size of the corpus they're checking. Incremental proofreading is the structural fix: send a stable textId and only the changed regions are re-processed, which on a typical editing session cuts the billed volume by an order of magnitude or more.
Non-Latin text. CJK characters carry a 2.5× weight at some vendors, Sapling among them, on the grounds that they carry more information per character. If your product serves Japanese or Chinese users, check for that multiplier or you'll be off by more than double. AmberPen bills every Unicode code point the same, whatever the script.
Ancillary fields. Dictionaries and proper-noun lists count toward your billed input on some per-character APIs. Sending a 500-term product glossary with every 200-character comment then inverts your cost structure. AmberPen bills the text field only, but it does count those fields against test-key quotas, so a glossary-heavy request can exhaust a test allowance faster than you expect.
Higher-quality modes. Two-pass modes cost more by definition — AmberPen's evaluate mode, which returns an explanation for every edit, bills twice the characters of the same request in correct mode. That's the correct trade for an education product and the wrong one for a comment box.
Published prices, August 2026
| Provider | Model | Entry price | Notes |
|---|---|---|---|
| AmberPen | Per character | Starter €5/mo, 500K chars included, then €9/M | Pro €49/mo with 9M included, then €6/M; no script multiplier; evaluate mode 2× |
| Sapling | Per character | From $25/M characters | Volume tiers; CJK 2.5× |
| GrammarBot Neural | Usage-based | Published per plan | Check current rates directly |
| LanguageTool | Free tier + premium, or self-host | Free tier is rate-limited | Self-hosting shifts cost to infrastructure |
| Harper | Free, open source | $0 licence | In-process; you ship the binary |
| Trinka | Custom / enterprise | Not published | Quote-based |
| General LLM | Per token | ~$0.75–$9 per M characters | Wide range by model; varies with reasoning and retries |
| Grammarly | Per seat | Enterprise | No corrections endpoint — see what its API does |
Prices are list rates as of August 2026 and change without warning; treat this table as a shape, not a quote, and verify on each vendor's own pricing page before you commit. AmberPen's current rates are on the pricing page.
Worked example 1: a note-taking app
50,000 monthly active users, average 800 characters checked per session, 12 sessions per month. That's 9,600 characters per user per month, or 480M characters per month.
- AmberPen: Pro at €49 covers 9M; the remaining 471M at €6/M is €2,826. Total ≈ €2,875/month at list — but Scale pricing starts at 50M characters, so this workload should be quoted rather than paid at list.
- Sapling: At published volume tiers, the first 10M costs $250, the next 40M costs $800, and the remaining 430M costs $6,450. Total ≈ $7,500/month — negotiate a tier well before this size.
- LLM: roughly $360–$4,300/month in raw model cost depending on the model, plus the engineering to make it deterministic and the retries when it isn't.
Two things to take from this. First, the spread between per-character vendors is real at volume, and it is worth an hour of arithmetic before you commit. Second, and more useful: this workload is 480M characters because every session re-checks from scratch. Cut the re-checks and the same product lands an order of magnitude lower, which is a bigger lever than any rate card. Run the same model at 4M characters a month — a smaller app, or the same one with incremental checking — and every option here costs less than a laptop, at which point quality and latency should decide, not price.
Worked example 2: a long-form writing app
This is where the models diverge violently. 5,000 writers, each with a 60,000-character manuscript, each writing four sessions a week with a check on every pause — call it 60 checks per session.
Checked naively: 60,000 × 60 × 4 × 4.3 weeks × 5,000 = 310 billion characters per month. That number is not a typo, and it is why "just call the API on debounce" quietly kills long-document products. At any per-character rate, that's an unshippable bill.
With incremental proofreading, only the changed regions plus surrounding context are re-processed. On a typical editing session that's low single-digit percentages of the document — call it 3%, matching what we see in practice. The billed volume drops to roughly 9.3 billion characters, a 97% reduction, and lands in enterprise-contract territory rather than the absurd.
The lesson generalizes past any one vendor: for long documents edited over time, your architecture sets your bill, not your vendor's rate card. Pick the pricing model second and the re-check strategy first.
Worked example 3: an education platform
2,000 students, 30 submissions per term, 3,000 characters each, checked in evaluate mode for explanations. That's 180M characters per term — but evaluate mode bills at 2× the input, so 360M billed characters, or about 120M per month across a term.
- AmberPen: Pro plus overage lands near €715/month at that volume; Scale pricing starts at 50M characters, so this workload should be quoted rather than paid at list.
The relevant comparison here isn't per-character rates at all — it's that most alternatives don't return per-edit explanations, so the cheaper option doesn't do the job. We covered why explanations are the product in grammar feedback that teaches.
How to model your own bill in ten minutes
- Instrument first. Log the character count of every proofread request in your existing product (or your prototype) for a week. Do not estimate this — teams are consistently wrong about it by an order of magnitude.
- Separate first-checks from re-checks. The ratio between them tells you whether incremental processing is worth adopting. Above roughly 5:1, it dominates every other cost decision.
- Apply the multipliers. Your vendor's script weighting, whether ancillary fields are billed, and mode. Then add 20% for retries and growth.
- Price that number at three vendors. Include the plan's included allowance, not just the overage rate — at low volume the base subscription is the bill.
- Compare against quality, not in isolation. A 30% cheaper API that surfaces suggestions users dismiss costs you more than it saves. How grammar correction is measured explains how to read the quality claims, and the grammar checker API comparison puts price and quality side by side for all seven options.
The cheapest proofreading request is the one you never send. After that, it's the one billed in a unit you can predict. You can measure both against your own text with a free test key — no paid plan, and the dashboard shows the exact character counts your product would be billed for.