Can Cotypist be vibe coded?
A macOS app that suggests inline text completions as you type, in almost any app, using a local model.
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.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
What you pay today, before any DIY hosting
medium editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- A menu bar app that watches keystrokes via the Accessibility API, asks a local model for the next few words, and paints an inline ghost suggestion you accept with Tab.
- Automate one repetitive personal workflow end to end with real persistence.
- A responsive interface with real empty, loading, success, and error states.
The parts a prompt cannot buy
- 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
- The last 20 percent is sync, migration fidelity, speed, and edge cases.
- Model quality and inference operations are part of the product.
Build, switch, or keep paying
Narrower, with trade-offs
A menu bar app that watches keystrokes via the Accessibility API, asks a local model for the next few words, and paints an inline ghost suggestion you accept with Tab.
Use the build brief ↓No checked option yet
Compare the prior art below or build only the workflow you need.
$6/mo
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.
Visit Cotypist ↗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.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
Model quality and inference operations are part of the product.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Cotypist
Context
Cotypist — A macOS app that suggests inline text completions as you type, in almost any app, using a local model. It currently costs $6/mo.
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.
This brief describes a focused, single-operator replacement for the part of Cotypist that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.
What you are building
A menu bar app that watches keystrokes via the Accessibility API, asks a local model for the next few words, and paints an inline ghost suggestion you accept with Tab.
Automate one repetitive personal workflow end to end with real persistence.
A responsive interface with real empty, loading, success, and error states.
Requirements
Functional
MacOS with Xcode and a Swift toolchain.
Accessibility and Input Monitoring permissions granted manually.
A small local model via llama.cpp or MLX, or a personal n-gram corpus built from your own text.
Apple Silicon strongly preferred for latency.
Non-functional
Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
Security: server-side secrets, validated input, and no credentials in the client bundle.
Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
Portability: the operator can export their data and leave without losing it.
Implementation brief
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.
Delivery standard
Inspect the repository first, then write a short implementation plan before writing code.
Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
Add structured logs around every external call and return actionable errors without leaking sensitive details.
Write unit tests for the core logic and one automated test of the main user journey.
Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.
Acceptance criteria
A clean install starts the app using only the README and .env.example.
The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
Tests, type checking, linting, and a production build all pass with no ignored failures.
No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.
Non-goals
Do not build these, and do not claim to have replaced them:
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.
What you still own after launch
Run migrations, backups, restores, and dependency updates.
Test the critical journey after every model, API, or hosting change.
Monitor failures and fix the edge cases a first prompt will miss.
Risk
Manageable. A personal version is realistic if you test the critical journey and keep reliable backups.
Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.
Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/cotypist
You still own the product
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
Projects built from this idea
No reviewed implementation has been linked for Cotypist yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of Cotypist?Submit the project as evidence for this report.
Before you start
Can Cotypist be vibe coded?
Partly, if you narrow it. 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.
What can an AI coding agent reproduce from Cotypist?
A menu bar app that watches keystrokes via the Accessibility API, asks a local model for the next few words, and paints an inline ghost suggestion you accept with Tab. Automate one repetitive personal workflow end to end with real persistence. A responsive interface with real empty, loading, success, and error states.
What will a DIY Cotypist replacement still be missing?
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; The last 20 percent is sync, migration fidelity, speed, and edge cases.; Model quality and inference operations are part of the product.
What do I still own after building a Cotypist alternative?
Run migrations, backups, restores, and dependency updates. Test the critical journey after every model, API, or hosting change. Monitor failures and fix the edge cases a first prompt will miss.