"Why pay for a grammar API when LanguageTool is free?" Every team evaluating proofreading infrastructure asks it, and the answer is never "you shouldn't." Sometimes self-hosting is exactly right. But "free and open source" describes a license, not a total cost — and the true cost has three line items people systematically underestimate: the quality ceiling, the operations bill, and the engineering time.

This article prices all three honestly, using the two credible self-hosted options — LanguageTool and Harper — and identifies the workloads where each beats a managed API.

The two real options

LanguageTool is the veteran: a Java server built on thousands of hand-written rules plus statistical spell checking, with broad multilingual support. You run the server, point your app at its HTTP endpoint, and get structured matches — offsets, lengths, replacements, rule descriptions. For best results you download the n-gram dataset (many gigabytes on disk) that powers its confusion-pair detection.

Harper is the modern lightweight: a Rust engine you embed in-process — via JavaScript bindings, editor plugins, or its language server. No server at all, no network hop, responses in about 2 ms per sentence. English dialects only.

Both are genuinely good engineering. Both are also rule-based at heart, which is where the ceiling comes from.

Cost line 1: the quality ceiling

Rules catch what rules anticipate. When we ran public benchmarks over identical inputs (methodology on the benchmarks page), the recall gap was stark: on CWEB web text, LanguageTool found 18.3% of the errors human annotators marked, and Harper found 13.8%. A neural API found two-thirds.

The precision numbers are just as instructive. Harper's 5.8% CWEB precision comes from a characteristic failure mode: unfamiliar names and terms get "corrected" into dictionary words. From our AmberPen vs Harper comparison, an acronym like "CTA" became "Cat," and the footballer "Nemanja Matic" became "Newman's Magic." In a product with user-generated content, those aren't misses — they're actively wrong suggestions your users will remember.

LanguageTool is far more disciplined — its 37.8% CWEB precision is excellent — but an error that no rule encodes is invisible to it. The AmberPen vs LanguageTool comparison lists five ordinary contextual errors ("He poured over the documents," a dangling modifier, present perfect with a past time) that a live LanguageTool server reported as perfectly fine.

If your users mostly make mechanical mistakes — its/it's, their/there, "could of" — the ceiling may never matter. If they write real prose, it will.

Cost line 2: operations

The server itself is the visible part: a JVM with several gigabytes of heap, the n-gram data on disk, a process supervisor, log rotation, TLS, and enough headroom for your peak concurrent load. A VM comfortable for that footprint typically runs somewhere in the $40–$100 per month range at major clouds — modest, and often cited as proof that self-hosting is nearly free.

The invisible part is everything around the server:

  • Availability. Your writing feature now has a new single point of failure. Redundancy means a second instance and load balancing; the VM cost doubles.
  • Updates. Language data and rules improve on LanguageTool's release cadence. Somebody upgrades the deployment, diffs behavior, and rolls back when a new rule floods your UI with false positives.
  • The wrapper. You still need authentication, rate limiting, request validation, and monitoring between your product and the checker — the API surface a managed service already provides.
  • Multilingual scaling. Each enabled language costs memory and CPU; broad language support is a capacity-planning exercise, not a config flag.

None of this is hard. All of it is somebody's job, forever.

Cost line 3: engineering time

This is the line item that dwarfs the other two. Integrating the raw checker is a day. Building the product around it is weeks: suggestion UI, accept/dismiss flows, per-user and per-product vocabulary (LanguageTool's custom words live in configuration, not per-request fields), regression tests on correction behavior, and the update playbook above.

Then there's the feature gap you can't close with effort at all, because it doesn't exist in the self-hosted stack: incremental re-checking of long documents, streamed edit batches, per-edit explanations for learners. If your roadmap includes any of those, you're not choosing between free and paid — you're choosing between building an ML product and buying one.

When self-hosting genuinely wins

  • Air-gapped and regulated environments. If text legally cannot leave your network, a self-hosted checker isn't cheaper — it's the only option. (Worth noting: some managed vendors satisfy similar constraints without self-hosting — Trinka offers an on-premise deployment, and AmberPen retains no submitted text once a response is returned.)
  • Offline-first desktop software. Harper in-process is unbeatable here: no latency, no connectivity, no cost.
  • Enormous volume with a modest quality bar. If you check hundreds of millions of characters of mechanically simple text, owned compute can undercut per-character pricing — if the recall ceiling doesn't hurt your users.
  • Zero budget, real constraints. A student project or a community tool with no revenue should absolutely self-host.

When a managed API wins

Flip those conditions. Quality is user-facing and trust-sensitive; the team is small; time-to-market matters; you need explanations, streaming, incremental checking, or per-request dictionaries; you'd rather meter by character than staff a service. At moderate volumes the math is short: AmberPen's Starter plan costs €5 per month with 500K characters included, then €9 per million — less than the VM you'd run for LanguageTool, before counting a single hour of the engineer babysitting it.

The decision, compressed

Self-host when data locality is mandatory, when offline operation is the product, or when volume is extreme and quality expectations are calibrated to rule-based checking. Buy when correction quality is part of your product's promise and your engineers are more valuable than your vendor's invoice.

The worst outcome is the accidental middle: three months building around a self-hosted checker, only to discover the recall ceiling after users stop trusting the underlines. Avoid it by testing quality first — run your own representative texts through both options. Our benchmark methodology is public, the corpora are public, and a free test key makes the managed side of the comparison cost nothing to measure.

Two companion pieces close the loop: how grammar correction is measured explains what the recall and precision numbers above actually mean, so you can judge the ceiling for yourself, and the grammar checker API comparison covers the managed options alongside the self-hosted ones. For the money side, what you'll actually pay puts per-character, per-token, and per-seat billing on the same axis.