Autocomplete Production Still Favors Classical Methods

The practical answer is still classical first, hybrid where it pays: a fast lexical candidate generator gets you the latency budget, and anything semantic usually comes later as a rerank or second pass.

• –LLMs are attractive for quality, but per-keystroke latency and cost make them hard to justify as the primary autocomplete path.
• –Prefix tries, n-grams, and popularity tables stay dominant because they are predictable, cacheable, and easy to run with tiny infra.
• –Hybrid retrieval plus reranking is the most plausible production compromise: generate a small candidate set fast, then spend extra compute only when the query is long enough or the user pauses.
• –For local or internal tools, a package like `query-autocomplete` is a good fit because it avoids a search cluster entirely; it will hit a ceiling sooner than Elasticsearch or Meilisearch on breadth and ranking quality.
• –The hard part is not suggestion generation, it's balancing typo tolerance, context awareness, and freshness without blowing the keystroke budget.