DEV Community: Sergey Levine

Stop opening a second app to rewrite one sentence on Mac

Sergey Levine — Mon, 05 Oct 2026 18:13:27 +0000

Most AI writing tools still make you do the same annoying loop:

Select text in the app where you are writing
Copy it
Open a chat tab or separate writing app
Explain what you want
Copy the result back
Fix the formatting that got weird
Try to remember where you were

That is fine for a full essay.

It is terrible for the small edits that happen 50 times a day.

make this sentence clearer
soften this reply
turn this rough note into a real paragraph
shorten this comment
make this sound less robotic
autocomplete the next few words without leaving the field

The problem is not that the AI is bad. The problem is the context switch.

The best writing UI is usually the text field you are already in

For most day-to-day writing, I do not want another editor.

I want help inside the app I already chose.

If I am writing an email, the email composer is the right place. If I am writing in Notes, Notes is the right place. If I am writing a support reply, the support tool is the right place.

A separate AI editor can be powerful, but it turns every small edit into a task.

That friction changes behavior. Instead of improving ten small things, you only use AI for the big obvious ones.

Local AI makes this feel different

Cloud AI is useful, but there are plenty of situations where I do not want to ship my half-written text to another service just to clean up a sentence.

Local models are not perfect, but for small writing operations they are getting good enough:

rewrite selected text
finish the current sentence
shorten a paragraph
change tone
turn fragments into a clean draft

The real unlock is not just privacy. It is speed and comfort.

When the model runs locally and the command is available from the keyboard, the interaction starts to feel more like a writing feature than a separate product.

The Mac has one annoying constraint

There is a catch: macOS does not give every app the same clean text access.

Tools that work inside existing text fields usually rely on Accessibility APIs. That means they work best in normal native text fields and may be limited in custom editors, secure fields, terminals, code editors, or apps that render their own text surface.

That limitation is worth being honest about.

But even with that constraint, there is a big category of writing where in-place AI help is simply a better workflow than copy/paste/chat/copy/paste.

What I want from this kind of tool

My ideal version is simple:

select text, hit a shortcut, rewrite it
type a command like “make this shorter” without opening a new app
keep private drafts on-device where possible
avoid subscriptions for basic writing help
stay out of the way until needed

That is the direction I think Mac writing tools should go.

Not another inbox. Not another dashboard. Not another blank document.

Just better words, in the field where the words already live.

I have been building DraftKey around that idea: private AI writing help for Mac that works in compatible text fields, with local autocomplete/rewrite and a little mechanical keyboard feel built in.

If that sounds useful, the site is here: https://www.getdraftkey.com/

Curious how other Mac users think about this. Do you prefer a dedicated AI writing app, or commands inside the text field you already use?

Codex usage tracking on Mac should not wait for the invoice

Sergey Levine — Thu, 01 Oct 2026 17:33:47 +0000

If you use Codex, Claude Code, Cursor, ChatGPT, or the OpenAI API for real work, token usage has a weird visibility problem.

You usually find out what happened after the session is over.

That is fine for a receipt. It is bad for a tool you are actively steering.

The problem with after-the-fact AI usage

AI coding work is full of loops that feel small in the moment:

retrying the same failing task
pasting a huge file when a smaller excerpt would work
asking an agent to scan more context than it needs
switching models without noticing the cost difference
letting a session run because the output is almost right

None of those moments feels like a billing event.

But together, they are exactly how AI spend creeps up.

By the time a dashboard or invoice shows the total, the useful decision point has already passed.

A token counter belongs where the work is happening

For Mac users, the best place for AI usage visibility is not another analytics tab. It is the menu bar.

A menu bar token counter gives you a small ambient signal while you are still working:

how much context this session is burning
whether a Codex or Claude run is getting expensive
whether retries are starting to stack up
when a prompt should be trimmed before sending
whether usage is normal or drifting into bill shock territory

That is the difference between usage reporting and usage control.

What I would track during Codex or Claude work

For AI coding sessions, the useful numbers are not complicated:

Tokens used in the current session
Approximate cost before the bill arrives
Provider and model visibility
Usage over time, not just at the end
A fast way to notice runaway context or retry loops

That is enough to change behavior.

If the number is visible, you make smaller prompts. You split tasks earlier. You stop asking an agent to reread the whole repo when one file would do.

TokenBar

I built TokenBar for this exact reason: a Mac menu bar app for seeing AI token, cost, and usage signals while you work.

It is aimed at people using tools like Codex, Claude, OpenAI, and other AI workflows where spend can hide inside long sessions.

Link: https://tokenbar.site/

The goal is simple: know what your AI work is costing before it turns into bill shock.

The practical takeaway

If you use AI coding tools every day, do not treat token usage like a monthly receipt.

Treat it like a live instrument.

The earlier you can see usage drift, the easier it is to fix the prompt, switch models, stop a retry loop, or break the task into something cheaper.

A private Grammarly alternative for Mac should work inside the text field

Sergey Levine — Thu, 01 Oct 2026 14:34:07 +0000

Most writing tools make the same tradeoff.

They are useful, but they pull your words away from the place you are already writing.

You write in Mail, Notes, Slack, Linear, a browser textarea, or some internal company tool. Then the workflow becomes:

Select the rough sentence
Copy it
Open another tab or app
Paste it into an AI chat
Explain what you want
Copy the result back
Check whether the tone still sounds like you

That works, but it is not a great Mac writing assistant workflow.

For short writing moments, the interruption is often larger than the writing problem.

The real job is not just grammar

A lot of people search for a private Grammarly alternative for Mac because they do not only want grammar checks.

They want help with tiny writing decisions:

Make this sentence clearer
Make this reply less blunt
Shorten this paragraph
Rewrite this selected text for a customer email
Finish the next few words without opening another app

Those are small tasks, but they happen all day.

If the assistant lives in a separate browser tab, you start ignoring it for anything under 30 seconds. The cost of switching context is too high.

That is why I think the better direction for AI autocomplete on Mac is not a bigger writing dashboard. It is a smaller assistant that stays close to the text field.

Local AI matters for everyday writing

Cloud writing tools are convenient. They are also easy to overuse for text that may include private work, customer names, internal plans, or half-written thoughts.

Not every sentence is a secret. But a lot of writing is personal enough that sending it to another service should be an explicit choice, not the default path.

A local AI writing assistant Mac app has a different shape:

The model can run on the Mac when supported
Drafts can stay closer to the device
Rewrite text Mac workflows can feel more like editing than outsourcing
The assistant can be available in many places without becoming another SaaS tab

There are tradeoffs. Local models need hardware, storage, and patience. They are not magic. They also cannot work perfectly in every macOS text field because different apps expose text differently through Accessibility APIs.

But the default posture is better for a lot of everyday writing: help me here, on this Mac, without turning every sentence into a cloud round trip.

The text field is the product surface

The most interesting part of a private Mac writing assistant is not the settings screen.

It is what happens when your cursor is already in a compatible text field.

For autocomplete, the assistant should feel like a quiet continuation of what you were already typing.

For rewrite, the flow should be:

Select text
Press a shortcut
Choose the instruction
Replace or insert the result

No copy and paste loop. No separate document. No pretending every two-sentence reply needs a full editor.

That is the behavior I care about while building DraftKey: https://www.getdraftkey.com/

DraftKey is a Mac app for private AI autocomplete, selected-text rewrite, and optional keyboard sounds inside compatible macOS text fields.

What I would measure

If I were evaluating any Mac writing assistant, I would ignore the landing page claims at first and ask:

Can it help in the apps where I already write?
Does it make short edits faster, or only long documents?
Can I rewrite selected text without moving it to another tab?
Does it clearly explain privacy and local processing?
Does it admit where macOS compatibility has limits?

That last one matters. Any tool that claims perfect support across every Mac app is probably hiding the hardest part.

The useful version is more honest:

It works in compatible text fields, improves the small writing moments, and keeps private writing closer to your Mac when possible.

The direction I want

I do not think the future of writing software is one giant AI editor where every sentence lives.

For a lot of Mac users, the better tool is ambient:

AI autocomplete Mac users can trigger where they already type
Rewrite text Mac users can apply to a selected sentence
Private Grammarly alternative Mac users can keep the workflow local-first
Mac writing assistant behavior can become a shortcut, not a destination

That is less flashy than a huge AI workspace.

But for everyday writing, less movement is the feature.

The best AI writing assistant for Mac should not be another tab

Sergey Levine — Wed, 30 Sep 2026 15:12:38 +0000

Most AI writing tools still assume the same workflow:

Stop writing
Copy the sentence
Open a browser tab or side panel
Ask for a rewrite
Read three versions
Paste one back
Fix the tone so it sounds like you again

That is fine for long documents. It is terrible for everyday writing.

The highest-friction writing is usually not a polished essay. It is the sentence inside the app you are already using:

a GitHub comment
a Linear ticket
a Slack message
an email reply
a support response
a changelog note
a product update
a docs paragraph

For those moments, the expensive part is not generating text. The expensive part is breaking flow.

The real problem is context switching

When writing help lives in a separate tab, it becomes another task.

You have to decide what to copy, decide how much surrounding context to include, ask for a rewrite, inspect the output, then move it back into the original field.

That sounds small, but it changes the psychology of the tool. Instead of being a writing assist, it becomes a writing detour.

For developers and technical writers, that matters. Most of the writing we do is embedded inside another workflow. We are not opening a blank page to write prose for its own sake. We are explaining a bug, clarifying a decision, answering a teammate, documenting a behavior, or turning a messy thought into something shippable.

If the tool pulls you away from that surface, it is already costing attention.

Autocomplete and rewrite should be close to the cursor

The best version of AI writing help on a Mac is boring:

suggest the next phrase when I am already typing
rewrite the selected text when I ask
stay out of the way when I do not need it
work in normal macOS text fields where possible
avoid turning every small edit into a chat session

That is the key difference between "AI as a destination" and "AI as an input layer."

A chat window is a destination. You go there, ask for something, then bring the result back.

An input layer is different. It helps at the point of writing. The cursor stays where the work is.

Local AI matters more for writing than people admit

Writing often contains sensitive fragments even when the whole document is not secret.

A half-written email can include names, plans, customer context, private opinions, internal wording, or unreleased product details. A bug report can include implementation details. A support reply can include personal information. A journal note can be private by default.

Cloud AI tools are useful, but a lot of everyday writing assistance should not require sending text somewhere else just to clean up a sentence.

Local AI is not always the right answer for every task. Big cloud models are still useful for heavy reasoning, research, or large drafts. But for quick autocomplete and instruction-based rewriting, local-first is a strong default because the text does not need to leave the machine for small edits.

There are honest Mac limitations

This is also where Mac writing tools need to be honest.

System-wide text help is not magic. macOS apps expose text fields differently. Some fields work cleanly through Accessibility APIs. Some custom editors expose less context. Some web apps behave differently depending on the browser, editor, and focus state.

A good Mac writing assistant should not pretend every text box is identical. It should work where macOS allows it, explain the limits, and avoid making privacy claims that depend on hidden server behavior.

That is the product shape I want more of: native, local when possible, close to the cursor, and honest about what the operating system allows.

What I am building

I am working on DraftKey, a native Mac app for private on-device AI autocomplete, instruction-based rewriting, and mechanical keyboard typing sounds in existing macOS text fields.

It is for people who want writing help without turning every sentence into a browser-tab workflow.

The practical version is simple:

keep typing where you already are
use autocomplete when it helps
select text and rewrite it with an instruction
keep the local AI work on your Mac
accept that some text fields will have platform limits

It requires macOS 14+, Apple Silicon, and 8GB memory for AI. The local model download is about 1.12GB.

The direction I think wins

The next wave of writing tools should feel less like separate apps and more like quiet infrastructure.

Not another dashboard.
Not another tab.
Not another place to paste your half-finished sentence.

Just help where the sentence already is.

That is the difference between a tool you admire and a tool you actually use every day.

A private Grammarly alternative for Mac should be local first

Sergey Levine — Wed, 30 Sep 2026 00:14:38 +0000

A lot of writing tools are built around one quiet assumption: if you want help with your writing, the draft has to leave the place where you are writing it.

That can mean opening a browser tab, pasting into a chatbot, using a cloud editor, or installing an extension that reads the page you are typing into.

For some writing, that is fine.

For other writing, it is not.

Client emails, internal notes, personal messages, support replies, private docs, and half-finished thoughts are not always things people want to send to a cloud writing service just to clean up one sentence.

That is why I think the useful Grammarly alternative for Mac is not just "AI grammar correction." It is local writing help that stays close to the cursor.

The problem is the round trip

Most AI writing workflows still have the same shape:

Write something awkward.
Copy it.
Open another app.
Paste it.
Ask for a rewrite.
Copy the result.
Paste it back.
Edit it again because the tone is not quite right.

That is tolerable once.

It gets annoying when the job is a short email, a support answer, a GitHub comment, a note, or a message you are already writing in a normal Mac text field.

The better interface is not always a new AI document editor. Sometimes the better interface is the text box you already picked.

Local writing help feels different

A local Mac writing assistant has a different set of tradeoffs.

The model has to run on your machine. Setup is heavier. There may be a model download. Performance depends on the Mac. The app has to ask for macOS permissions, and it has to be honest about where it can and cannot interact with text.

But the upside is important: the text does not need to become a cloud request for every completion or rewrite.

For everyday writing assistance, that changes the feeling of the tool. You can ask for a shorter version, a clearer version, or the next few words without treating every rough paragraph like something you are submitting to a remote service.

The honest Mac limitation

The tempting marketing line is "works everywhere."

For a Mac text-field assistant, that is not honest.

macOS apps expose text differently. Standard text fields are usually more cooperative. Custom editors, web views, terminal panes, secure fields, and heavily sandboxed apps can behave differently.

So the realistic promise is narrower:

autocomplete in compatible macOS text fields
rewrite selected text where the app can safely access and replace it
let the user review changes
avoid pretending every app exposes text the same way

That is less flashy than "AI in every app," but it is a better expectation.

What I am building

I am building DraftKey around this idea: private, on-device AI autocomplete and instruction-based rewriting inside compatible macOS text fields, plus optional mechanical keyboard typing sounds: https://www.getdraftkey.com/

It is a native Mac app for Apple Silicon Macs running macOS 14 or later. The AI setup needs enough memory and a local model download, which is the cost of not making the core writing flow depend on a cloud model.

I do not think every writing tool needs to be local.

Cloud AI is powerful, convenient, and useful for a lot of work.

But for the small writing moments that happen all day, the interesting direction is different: less "open an AI app" and more "get private writing help where the cursor already is."

That is the Grammarly alternative for Mac I actually want.

I wanted AI rewriting to feel like a Mac keyboard shortcut

Sergey Levine — Sun, 27 Sep 2026 00:14:48 +0000

If you use AI to clean up writing on a Mac, the annoying part is usually not the model.

It is the workflow.

You write something in Mail, Notes, Linear, Slack, a browser textarea, or an editor. Then you copy it into ChatGPT, explain what you want, wait, copy the result back, and check whether formatting survived.

That is fine for a long document. It is clumsy for the tiny edits that happen all day:

make this less harsh
shorten this paragraph
turn this into a clearer reply
fix the tone without changing the point
rewrite this sentence before I send it

For that kind of writing, I think the better interface is a keyboard shortcut.

The best case is staying where you are

A Mac writing assistant is much more useful when it works inside the text field you are already using.

Select text, hit a shortcut, give a short instruction, accept the rewrite, keep moving.

No AI tab. No separate editor. No context switch just to make two sentences sound less awkward.

That interaction matters because most writing work is not "write me a whole article." It is small edits in existing apps.

Local AI changes the trust equation

Cloud writing tools are convenient, but they also ask you to send drafts, replies, notes, or internal work text somewhere else.

For a lot of personal writing, that is not a big deal. For work notes, client replies, unfinished ideas, or sensitive drafts, it can be enough friction that you just avoid the tool.

Local AI is not magic, but it changes the default. If the model runs on the Mac, the writing help can happen on-device instead of becoming another cloud copy/paste step.

That is the tradeoff I like for everyday rewriting: a little more local setup, a lot less trust overhead.

The honest limitation

macOS text fields are not all the same.

Some apps expose text cleanly through Accessibility APIs. Some custom editors and web apps behave differently. A system-wide writing assistant has to deal with those edge cases instead of pretending every text box is identical.

So I would not judge a Mac AI writing tool only by whether it has the biggest model or the flashiest chat UI.

I would judge it by:

whether it helps in the app where I am already typing
whether the rewrite flow is fast enough to use repeatedly
whether it is honest about text-field support
whether private drafts have to leave my Mac

What I built

I have been working on DraftKey, a native Mac app for private, on-device AI autocomplete and instruction-based rewriting in existing macOS text fields. It also has optional mechanical keyboard typing sounds, because writing tools should feel good to use, not just be technically useful.

It requires macOS 14+, Apple Silicon, and 8GB memory for local AI. The model download is about 1.12GB.

If you want local AI writing help that stays closer to the text box, it is here: https://www.getdraftkey.com/

The bigger idea is simple: for everyday writing, AI should feel less like opening a chatbot and more like pressing a key.

The hardest part of a local AI writing assistant is not the model

Sergey Levine — Sat, 26 Sep 2026 19:58:46 +0000

A lot of people assume the hard part of a local AI writing app is picking the model.

That matters, but it has not been the whole problem.

The harder product problem is making the assistant feel like it belongs in the text field you are already using.

If writing help forces you to copy text into a separate chat window, wait, copy the result back, then clean it up, the model can be good and the workflow can still feel bad.

For a Mac writing assistant, the boring details matter more than they look:

How quickly suggestions show up
Whether rewriting works on selected text
Whether the app stays out of the way when you do not need it
Whether the text stays private instead of being sent to a server
Whether the assistant works in normal macOS text fields instead of only inside one editor

That is the direction I have been taking with DraftKey.

DraftKey is a native Mac app for local AI autocomplete and instruction-based rewriting inside existing macOS text fields. It runs on-device on Apple Silicon, so the writing workflow is closer to "keep typing" than "open another AI tab."

I am not trying to turn every writing moment into a chat session. I want the AI part to feel like a small layer on top of the text box you already picked.

There are real tradeoffs with that approach. Local models need a download. Performance depends on the Mac. Some apps expose text fields better than others. But for private writing assistance, those tradeoffs feel worth it.

If you are curious, the app is here: https://www.getdraftkey.com/

The bigger lesson for me: with AI products, raw output quality is only one part of the product. The workflow around the output decides whether people actually use it.