CLTK: a Python NLP library for pre-modern languages

The gap CLTK fills: NLP built for languages nobody speaks

General-purpose NLP tooling is designed around living languages. Tokenizers assume whitespace conventions and modern orthography; taggers are trained on contemporary corpora; sentence splitters expect punctuation that historical editions do not always use. The CLTK paper cited in the README states the problem directly: the vast majority of NLP algorithms and software is created with assumptions particular to living languages, which neglects characteristics of largely non-spoken historical languages. The same paper notes that scholars of pre-modern languages often have different goals than living-language researchers.

CLTK is the response to that mismatch. It is a Python library, MIT licensed, whose centerpiece the paper describes as a modular processing pipeline that balances algorithmic diversity with pre-configured defaults. The README says the project currently provides pipelines, including models, for almost 20 languages. The audience is narrow and identifiable: classicists, historians, philologists and computational linguists working on texts in Latin, Ancient Greek, Sanskrit, Hebrew, Arabic and Chinese, all of which appear as keywords in pyproject.toml. If your text is a modern newspaper, this library is not aimed at you.

How the pipeline works and where the models actually run

The public entry point is a single class. You construct an NLP object with a language identifier and, optionally, a backend, then call it on text. The README's examples use 'lati1261', which is the ISO 639-3 style code for Latin, and the constructor accepts backend='openai', backend='ollama', backend='ollama-cloud' or the Stanza route installed through the stanza extra.

That design choice is the interesting part. Older versions of CLTK bundled its own trained models. In the 2.x line the annotation work is delegated: either to a hosted large language model through the OpenAI client, to a local model served by Ollama, or to Stanford Stanza's discriminative models. The pipeline still owns the language-specific logic, but the heavy lifting happens in whichever backend you select. Two consequences follow. First, results depend on the model you choose, not only on CLTK, so the same Latin sentence can be annotated differently under gpt-5-mini, llama3.1:8b or a Stanza model. Second, the offline story is now tied to Ollama: if you want no network calls, you install the ollama extra and run a server locally.

The repository layout supports the multi-backend claim. There are separate optional dependency groups for openai, stanza, ollama and mistral in pyproject.toml, plus an evaluation/ directory containing a compare_all_models.py script wired into the Makefile as modelComparison. That script exists because comparing backends is a routine task for this project, not an afterthought.

Installing CLTK and running a first Latin pipeline

The README gives a plain pip install for the core library. Note the Python floor: pyproject.toml sets requires-python to >=3.13, so an older interpreter will refuse the install before anything else happens.

pip install cltk

Optional extras pull in a backend. Stanza gives you discriminative models from Stanford; the openai extra adds the OpenAI client. They can be combined in one command.

pip install "cltk[openai,stanza]"

For fully local annotation, install the Ollama extra and make sure an Ollama server is running on the same machine. The README states that backend='ollama' defaults to the model llama3.1:8b.

pip install "cltk[ollama]"

With a backend installed, the first real use is three lines. The README shows constructing the pipeline for Latin and passing a model name for the Ollama route.

from cltk import NLP

nlp = NLP('lati1261', backend='ollama', model='qwen2.5:14b')

The OpenAI route needs an API key in the environment, for example through a .env file or a shell variable, since python-dotenv is a core dependency and the README mentions OPENAI_API_KEY explicitly. The default model there is gpt-5-mini. If you prefer to install from source rather than from PyPI, the README points to the development page in the docs and the Makefile exposes uv-based targets such as install and installDev. The Makefile also has a simpleCheck target that runs scripts/example_greek_readers_guide.py as an end-to-end smoke test of the Greek pipeline.

Where CLTK stops being the right tool

The most concrete limitation is the backend dependency. Local inference requires an Ollama server; cloud inference requires an API key and sends your text to a third party. For a fragment of an unpublished papyrus or a licensed critical edition, that is a real constraint, and the README does not document a data-retention policy for the OpenAI route. If your project forbids text leaving the machine, your only path is Ollama or Stanza.

Python 3.13 as a hard minimum is a second practical barrier. Research groups often run pinned environments on older interpreters, and requires-python will block the install outright rather than degrade gracefully. That is a deliberate choice by the maintainers, but it narrows the set of machines that can run the current release.

The release history is worth reading before you build on the API. The latest release listed is 2.0.0a3, an alpha, dated 2025-09-21, while v1.5.0 and v1.4.0 are stable releases from 2025-05-04. The pyproject.toml version field reads 2.5.1, which does not match any published release in the list, so the development tree is ahead of the tagged artifacts. Anyone depending on 2.x should expect interface movement between the alpha and a stable tag. Pre-1.0 code lives on the v0.1.x branch with documentation at legacy.cltk.org, installable as pip install "cltk<1.0"; the README does not describe a migration path from that branch to 2.x.

Finally, CLTK is not a general NLP library. It has no interest in English sentiment analysis, and the keyword list in pyproject.toml is entirely historical languages. Using it as a wrapper around a modern-language model would add a layer without adding capability.

CLTK compared with NLTK and Stanza

The comparison people reach for is NLTK, and the topic list in the repository metadata includes nltk, which invites it. The difference is scope, not quality. NLTK is a general-purpose teaching and research toolkit for natural language processing, and its model coverage is oriented toward modern languages. CLTK is the same idea restricted to pre-modern languages, with the language-specific preprocessing and model choices made for you. If your corpus is English, NLTK is the tool; if it is Ancient Greek, NLTK gives you machinery you would have to retrain.

Stanza is the more interesting comparison because CLTK uses it. Stanza is a Stanford NLP library with discriminative models for a set of languages, and CLTK exposes it as one backend among several. So the relationship is partly layered: choosing the stanza extra inside CLTK means your annotation comes from Stanza's models while CLTK handles the pre-modern language conventions around them. Going directly to Stanza is reasonable if your language is supported there and you do not need CLTK's pipeline defaults; staying inside CLTK buys you the historical-language handling and a consistent interface across backends, at the cost of an extra dependency layer and the version constraints CLTK imposes.

The GenAI backends have no real equivalent in either NLTK or Stanza. Routing classical text through a hosted or local LLM is a newer approach, and it trades reproducibility for flexibility: a Stanza model produces the same output every run, while an LLM backend may not, and the README does not make any determinism guarantee for the OpenAI or Ollama routes.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-08-01, which is recent enough that the project is being worked on. The release cadence visible in the release list is uneven: two stable releases on the same day in May 2025, then an alpha in September 2025, then development commits through mid-2026 with no matching stable tag in the list. That pattern suggests active development on the 2.x line without a settled release.

The practical upgrade cost sits in two places. The Python 3.13 requirement means upgrading CLTK may force an interpreter upgrade across your whole environment. And the backend abstraction means an upgrade can change your annotation output if the default model for a backend changes; the README documents gpt-5-mini as the OpenAI default and llama3.1:8b as the Ollama default, so those defaults are worth pinning explicitly in your own code rather than relying on them.

On licensing: the project is MIT licensed, copyright 2014 to present Kyle P. Johnson, per the README. MIT is permissive, but it covers CLTK's code, not the models you route text through. Stanza, Ollama models and OpenAI outputs carry their own terms, and the README does not summarize them. That is a question for your institution, not for this article.

Editorial conclusion

Adopt CLTK if your corpus is Latin, Greek or another language the project ships a pipeline and models for, and if you accept Python 3.13 as a floor. Do not adopt it for modern-language NLP or as a drop-in NLTK replacement. Before committing, check the installation docs for the language code you need, confirm whether your annotation route is OpenAI, Ollama or Stanza, and read the v0.1.x branch notes if you depend on pre-1.0 APIs.

Frequently asked questions

Official sources

1. cltk/cltk on GitHub
2. License: MIT
3. Project website
4. README
5. Releases