Chonkie is a Python and TypeScript library for the chunking stage of a RAG pipeline — split a document, optionally embed and refine, push to a vector store. It is genuinely well-built, and its marketing numbers are genuinely misleading. This leaf is the honest read: what the Rust core actually buys you, why the headline throughput and the real throughput differ by four orders of magnitude, and a peer-reviewed reason to reach for the cheap chunkers, not the clever ones.
Chonkie handles ingestion-stage chunking: take a document, split it into passages a retriever can index, and optionally embed and refine them. It ships in Python (chonkie, MIT) and TypeScript, is actively developed (v1.6.4, April 2026), and is maintained by a small YC-backed company that also runs a hosted product.
The architecture is the thing to understand first, because it explains every number downstream. The Python package is a thin wrapper over a separate Rust crate. chonkie-inc/chunk (Rust, dual MIT/Apache-2.0) does the SIMD boundary detection; chonkie-inc/chonkie (Python) wraps it. Two repos, two licences, two release cadences — and the fast part lives on the far side of a foreign-function boundary from the code you call.
The chunker menu is broad: fixed-token, a byte-based SIMD chunker (FastChunker), sentence, recursive, semantic, late, code, a fine-tuned-BERT neural chunker, and an LLM-driven one ("Slumber"). Worth knowing before you plan a container build: only two of them — FastChunker and TokenChunker — are in the default install. The semantic, late, neural, and LLM chunkers each require extras.
The fastest chunker is fast because it never invokes a tokenizer — it counts bytes. That is the tradeoff, and it is stated plainly in Chonkie's own docs: it is the right default only if you don't need to know how many tokens a chunk holds.
Byte size, not token count. FastChunker limits chunks by byte length, and its output reports token_count = 0 — always. If you are fitting an LLM context window precisely, this chunker cannot tell you whether a chunk fits; you find out when the request overflows in production. Reach for TokenChunker when the token budget is the constraint.
from chonkie import FastChunker # chunk_size here is BYTES, not tokens — token_count in the output is always 0 chunker = FastChunker(chunk_size=2048, delimiters=[". ", "\n\n"]) chunks = chunker(text) # chunks[0].token_count == 0 — by design; use TokenChunker if you need real counts
The default-install boundary is where a build bites. pip install chonkie gives you the two cheap chunkers; the interesting ones pull in extras (model weights, an embedder, an LLM client). Decide which chunker you are shipping before you size the container, not after. And note one gap in the hosted path: FastChunker, the fastest one, is not available through the hosted API — you get it in Python and JS only.
The FFI point, stated once. The SIMD throughput number describes the Rust boundary-detection loop in isolation. Every call from Python crosses the FFI boundary and returns Python str objects, and that crossing — allocation, decoding, object construction — is where the real per-call cost sits. The Rust core is fast; the pipeline around it is ordinary Python.
The headline, attributed to Chonkie's own docs, is "SIMD-accelerated chunking at 100+ GB/s". The vendor's own end-to-end benchmark, on 100,000 Wikipedia articles, measures 4.82 MB/s. That is roughly four orders of magnitude, and it is not dishonesty — it is the distance between a micro-benchmark of a Rust boundary-detection loop and a Python pipeline doing tokenization, allocation, and FFI crossing. State it plainly and let it sit. Note too that the same component is advertised at 1 TB/s in one repo and 100+ GB/s in the docs; when a vendor's two headline figures for one component differ tenfold, neither is a specification.
The honest comparison is against LangChain, the realistic alternative. On the same token-chunking task Chonkie is about 1.18–1.21x faster — a real, defensible improvement, and a long way from the "33x" the README leads with (that figure is against LlamaIndex on the smallest dataset). Chonkie's genuine edge over LangChain is arguably footprint and dependency hygiene rather than raw speed — though even there its own two sources disagree about installed size (15 MiB in the benchmark file, 49 MB in the docs), so quote the direction, not the number.
The larger question is whether the expensive chunkers earn their compute at all. Qu, Tu and Bao (Findings of NAACL 2025) evaluated semantic chunking across document retrieval, evidence retrieval, and answer generation, and found the computational cost is not justified by consistent gains — fixed-size chunking often matched or beat it on realistically structured documents. That finding lands directly on SemanticChunker, LateChunker, NeuralChunker, and SlumberChunker. The practitioner reading is clean: the cheap chunkers are the right default, and the burden of proof is on the expensive ones for your corpus. Chonkie is a reasonable choice partly because its cheap chunkers are good — not because of its clever ones. Chunking is a component you should be able to swap and measure, not a strategy you commit to.
Chonkie is a good small dependency for a specific job. The disqualifiers are real, not softened.
FastChunker — it returns zero, and you won't notice until context overflows.Chunking is one stage of RAG ingestion. It sits directly after parsing and directly before embedding — and it is the stage most often over-engineered.
The two repos and the benchmark file let you check the vendor's numbers against themselves. The NAACL paper is the external anchor for the whole honest read.