DraftKey brings offline LLM autocomplete and rewrites to any macOS text field

What the app does

According to a write-up published on dev.to, a developer has shipped DraftKey, a writing assistant built as a native macOS application. Its distinguishing feature is not the model itself but where it runs and how it reaches your text: the app uses macOS Accessibility integration to work inside text fields across other applications, and it runs a language model the developer sizes at roughly 1.1 GB entirely on the machine. Autocomplete and rewrite suggestions therefore work offline, with no cloud API in the loop.

The post is brief — more a shipping announcement than a technical deep dive — but the developer signals a willingness to go deeper on two fronts later: the quirks of working through Accessibility, and the details of on-device inference.

Accessibility as the integration layer

Most AI writing assistants pick one integration point: a browser extension, an editor plug-in, or their own document editor. DraftKey's approach is broader. macOS Accessibility, the subsystem built to support assistive technologies such as screen readers, exposes a programmatic view of interface elements — including text fields — to apps that have been granted permission. By sitting on that layer, DraftKey can in principle attach to text inputs in any application rather than shipping per-app integrations.

That ubiquity comes with trade-offs the post only gestures at. Accessibility behaviour varies from app to app, controls built with non-standard frameworks often expose incomplete metadata, and an app that both reads and writes text on your behalf across the whole system is, by definition, extremely privileged software.

Deliberate limits

The developer notes two explicit exclusions: DraftKey does not act on secure input fields, and it stays away from the fields password managers use. For a tool whose core capability is observing and modifying arbitrary text fields, treating credential entry as off-limits is a sensible baseline — though users still have to trust the app with everything else they type.

Part of a broader shift

The first wave of consumer local-LLM software mostly treated the model as the product: chat interfaces and terminal tools where enthusiasts fetched quantised weights themselves. DraftKey represents a different genre — a focused utility where local inference is an invisible implementation detail, closer in feel to spell-check than to a chatbot. The roughly 1.1 GB figure is a file size rather than a parameter count, and the post does not name the underlying model, which places it firmly in the small-model class that recent quantised releases have made viable at interactive speeds on modern Mac hardware.

Why it matters

DraftKey is a useful data point in the maturation of local-LLM applications. If a solo developer can wrap a compact on-device model in native macOS plumbing and deliver system-wide writing help, the gap between enthusiast tooling and shippable product is closing. The privacy argument here is structural rather than policy-based: text that never leaves the device cannot be logged on a server. And the Accessibility-based approach previews a pattern other builders will likely copy — one that works well, but that also asks users to hand a third-party app one of the most powerful permissions macOS offers. How developers and Apple manage that trust boundary may determine whether system-wide local assistants become a real category or remain a curiosity.