Can I vibecode Cotypist?

KINDA · weekend project
price $6/moyou'd save $72/yrbuild time multi-daycategory ⚙️ productivity utilitiesreplaced by 0 people

The idea is simple: watch what you type, predict the rest, show it as ghost text, accept with Tab. The prediction part is genuinely easy now, a small local model or even a personal n-gram table over your own writing gets you most of the way. The hard part is everything around it: reading the current text field and caret position through the macOS Accessibility API, drawing an overlay that tracks a moving cursor, and not breaking in Electron apps, Chrome, terminals, password fields, or anything that reimplements text editing. You can build something that works in native AppKit fields in a couple of long sessions and feels magic. Getting it to work everywhere, at typing latency, without eating keystrokes or leaking into your bank login, is where the actual product lives.

the prompt
Build a macOS menu bar app called GhostType that shows inline text predictions as I type.

Stack, no alternatives: Swift 5.9+, SwiftUI for the menu bar UI, AppKit for the overlay window, one Xcode project, no external services.

Core loop:
1. Register a CGEventTap for keyDown events so we can observe typing and intercept Tab and Escape.
2. Use the Accessibility API (AXUIElement) to read the focused element's AXValue and AXSelectedTextRange, and AXBoundsForRange to get the caret rect in screen coordinates.
3. Take the last 200 characters before the caret as context and request a completion of up to 6 words.
4. Render the suggestion as dim gray ghost text in a borderless, non-activating NSPanel positioned at the caret rect. Never modify the target app's text until accepted.
5. Tab accepts: insert the suggestion by posting synthetic key events. Escape dismisses. Any other keystroke re-predicts after a 120ms debounce.

Prediction engine: ship two interchangeable providers behind a protocol.
- Provider A, default: an on-device n-gram model built from a folder of my own .txt and .md files at first launch, stored in a SQLite file in Application Support.
- Provider B: a local llama.cpp or MLX server at a URL from .env, called with a strict token limit and a 250ms timeout that is cancelled on the next keystroke.

Safety, non-negotiable:
- Never predict when secure input mode is active, when the focused element role is AXSecureTextField, or when the frontmost app bundle id is in a user-editable deny list.
- No network calls except to the local provider URL. No telemetry, no accounts, no crash reporting.

In scope: native AppKit text fields and text views, a menu bar toggle, a deny list editor, a corpus folder picker.
Out of scope: Electron and browser text fields, terminals, iOS, sync, cloud models, multi-language tuning. Detect unsupported contexts and stay silent rather than guessing.

Deliverables: the Xcode project, a README with the exact Accessibility and Input Monitoring permissions to grant and where to click, .env.example, and a plain description of what fails in Chrome and VS Code and why.

$ open in your agent (prompt prefilled, you press enter) or copy it raw · this prompt is generated from the build plan · improve it via PR

why people still pay

Because a text predictor that works in nine apps and glitches in the tenth is a text predictor you turn off. The value here is invisible reliability across an entire OS, which means quietly handling every app that draws its own caret, every accessibility API quirk, and every macOS release that changes the rules. That is maintenance work, not a build, and it is worth a small license fee to hand off.

what you lose

xCoverage: your build will work in native text fields and fail or misbehave in Electron apps, browsers, and terminals

xLatency polish: suggestions that arrive after you already typed the words are worse than nothing

xSafety rails: skipping password fields, secure input mode, and sensitive apps takes deliberate work

xPersonalization that actually improves over months of your writing rather than a one-off corpus dump

xSigned, notarized, auto-updating distribution and the permission onboarding that makes it survive OS updates

prior art · use these instead of building, if you'd rather

Nothing worth pointing at. That's why the prompt exists.

share on X ↗"I just replaced Cotypist ($6/mo) with one prompt"
questions
Can I vibecode Cotypist?

Kinda. The core of Cotypist is buildable in a weekend with the prompt on this page, but there are real gaps: Coverage: your build will work in native text fields and fail or misbehave in Electron apps, browsers, and terminals, Latency polish: suggestions that arrive after you already typed the words are worse than nothing. Read the honest list above before committing.

How much does Cotypist cost?

Cotypist costs about $6/month (Plus, checked 2026-08-18), which is $72 per year.

What do I lose by replacing Cotypist?

Honestly: Coverage: your build will work in native text fields and fail or misbehave in Electron apps, browsers, and terminals; Latency polish: suggestions that arrive after you already typed the words are worse than nothing; Safety rails: skipping password fields, secure input mode, and sensitive apps takes deliberate work; Personalization that actually improves over months of your writing rather than a one-off corpus dump; Signed, notarized, auto-updating distribution and the permission onboarding that makes it survive OS updates. If any of those are load-bearing for you, keep paying.

Is there an open-source alternative to Cotypist?

No mature open-source alternative worth pointing at, which is exactly why the one-shot prompt on this page exists.

Every week, more subscriptions die.

New verdicts, new prompts, the week's most-doomed apps.
One email. Unsubscribe in one click.

free forever · no scanner spam · the prompt stays on the site, the deaths come to you

$weekly: what got a verdict, what died.