Skip to content
Kotoshu Kotoshu 言修

Documentation

Comparison

Kotoshu next to hunspell, cspell, and LanguageTool — an honest feature table and guidance on choosing.

Four tools with overlapping names for the job and different centers of gravity. This table is written to be fair.

Compare

Feature by feature

DimensionKotoshuhunspell CLIcspellLanguageTool
ImplementationRuby and Rust twins (byte-identical), wasm, native extC++TypeScript / NodeJava
DictionariesHunspell-format, downloaded on demand (~98 staged); local .aff/.dic welcomeSystem-installed .aff/.dicMany bundled, plus project dictionariesBundled per language
Semantic rerankingYes — FastText-to-ONNX embeddings, opt-in—— (case- and code-aware, not semantic)ML-ranked suggestions; no embedding rerank
Grammar rulesRoadmap — rule packs planned—— (spelling only)Yes — thousands of rules, the benchmark
Editor integrationLSP server — VS Code, Neovim, Emacs, JetBrainsWhatever your editor bundlesOfficial VS Code extension; community elsewhereExtensions for most editors, Office, Google Docs
CI & SARIFSARIF 2.1.0, JSON, stable exit codes, GitHub ActionText output; wire it yourselfGitHub Action, JSON; SARIF via wrappersCommunity actions; SARIF via wrappers
HTTP API / SDKskotoshu-server, plus Python, JS, Go SDKs—— (JS library)First-class HTTP API, Docker
Offline / self-hostYes — two-stage setup, then KOTOSHU_OFFLINE=1Yes, fully localYes, local runYes — desktop app or self-host server
LicenseBSD-2-Clause (dictionaries vary)GPL / LGPL / MPL tri-licenseApache-2.0 (dictionaries vary)LGPL-2.1+
Size on disk~5 MB per language; ONNX model optional (~230–460 MB)A few MB per languageTens of MB with NodeHundreds of MB with Java and rule data

Choosing

Choose Kotoshu if you want provable engine correctness — two independent implementations held to a frozen, CI-enforced conformance contract — on whichever channel fits your stack: a library or CLI in Ruby, an embedded engine through wasm, Python, or Rust, a self-hosted HTTP service, or a GitHub Action with baselines and SARIF. Choose it too if fetching dictionaries, frequency lists, and models on demand beats vendoring them, and if you want suggestions reranked by context.

Choose the incumbents when tooling maturity matters more than semantic ranking: hunspell for the smallest, fastest, most ubiquitous binary, and cspell if committed-in-repository configuration for a polyglot codebase is the deciding factor, which is its strength today.

Choose LanguageTool if grammar breadth is the requirement. Nothing else in this table approaches its rule library, and pretending otherwise would not make it true.

Migrating from any of these? The per-tool notes are in Migrating, and the sixty-second install path is on the install page.