The desktop never got T9: why, and how LLMs could fix it

Most of our work text is written on a computer: emails, documentation, tickets, code, code comments. Yet smart autocorrect stayed on the phone. There, a word is fixed as you type, while on a PC the user gets a red wavy line and a context menu on right-click.

The gap has been visible since smartphones got touch keyboards, more than a decade and a half ago. A recent Habr analysis returns to the question: why the desktop never learned more, and whether LLMs can fix that. Below we look at the causes and at what language models actually change here.

The original RSS publication provides only a teaser, so what follows relies on the well-known architecture of text input and the current state of the market.

Why phones got autocorrect and PCs did not

On a smartphone, the keyboard is an app. It sees the coordinates of every touch, the probability of hitting neighboring keys, and the context of the phrase being typed. Autocorrect is a necessity there: a finger is bigger than a key, and typing is impossible without it. The keyboard developer controls the entire input layer, so it can substitute words, change earlier ones, and learn from the owner's habits.

On the desktop the picture is the reverse. A physical keyboard is more accurate, errors are generally fewer, and there is no acute need. Besides, text lands in browsers, IDEs, messengers, terminals and office suites, each with its own text engine. There is no single point where input can be intercepted and a word cleanly changed. You have to work through accessibility APIs or system-level hooks. That is fragile, differs for each OS, and often breaks in protected fields.

There is also the question of trust. A program that reads everything you type resembles a keylogger by definition. For work data this is a serious obstacle: lawyers and security teams will readily ban such a tool.

What language models change

Classic autocorrect relies on a dictionary and n-gram statistics. It fixes typos within a word well, but understands context poorly: it cannot tell the Russian «ложить» from «класть» by the meaning of the phrase, and it stumbles on professional jargon. A language model looks at the whole sentence and judges which word fits. Apple has already moved autocorrect in iOS to a transformer-type model, and macOS now has built-in continuation suggestions. So the major vendors are ready to bring this to the desktop, though for now they do it cautiously and mostly for a limited set of languages.

The main change concerns size. Models with a few billion parameters, for example the Phi-3-mini class with 3.8 billion, already run on a laptop without the cloud. This removes part of the privacy problem: the text does not leave the machine. Latency and resources remain.

The benchmarks for such a tool look like this:

• suggestion latency: around 100 ms, otherwise it lags behind typing;
• model size: from hundreds of millions to a few billion parameters, quantized;
• offline operation, with no text sent to a server;
• support for Russian, with its cases and free word order, where weak models make more mistakes;
• configurable exceptions for passwords, the terminal and code.

What to do about it in practice

If you need smart correction on a PC right now, there are three workable paths. First: use spelling and style checking in the browser and office suites. It does not replace T9, but covers some tasks. Second: install a local tool built on a small model and test it on your own texts, paying attention to latency and to how it behaves in an IDE and a terminal. Third: if you are building such products, start with narrow scenarios, such as correction in one app or one field, and only then move to the system level.

Whichever you choose, check three things. Where the text is processed: locally or in the cloud. Which apps the tool does not touch. And how it behaves in Russian, not only in English. Desktop T9 is still a niche, but there are noticeably fewer technical obstacles to it than a few years ago.