This post is a direct product comparison with WunderType, the free Mac App Store writing tool a lot of people try first. I'm the maker of DraftKey (Aura Technologies). I'm not neutral. I'll still be honest about where WunderType wins.

The short answer

Pick DraftKey if you want system-wide next-word suggestions as you type, a one-time $4.99 license, and a model that ships with the app.

Pick WunderType if you want $0 and you're fine without Tab autocomplete as the main loop.

What DraftKey actually is

DraftKey reads the text around your cursor through macOS Accessibility, runs a small language model on your Mac, and shows a short gray suggestion. Press Tab to accept. Press ⌘⌥ to rewrite the paragraph or selection (shorter, clearer, fix grammar, change tone, or a custom instruction). Review before insert.

It is not a chatbot and not a side panel. It's autocomplete for prose, system-wide, in compatible text fields.

Also included: clipboard history (⌘⌥V) and optional keyboard sounds.

Honest limits (read before you buy)

1. No free trial. $4.99 to try the real app. There's a free in-browser typing demo on getdraftkey.com.
2. Apple Silicon + macOS 14+ only. No Intel.
3. ~1.12 GB model download on first launch (~2.2 GB free space).
4. Accessibility-dependent. Some Electron apps, custom editors, and all secure fields won't work well or at all.
5. Not GPT-class. Small local model = fast sentence finishing, not essay writing.

Why compare to WunderType

WunderType is the obvious free alternative people find when they search "AI writing Mac local." If your main need is rewrite modes and you don't care about inline Tab autocomplete, stay on free.

If you specifically want Tab-to-accept suggestions while you type in the apps you already use, and you're willing to pay once for a bundled on-device model, DraftKey is built for that.

Price

• DraftKey: $4.99 lifetime, up to 3 Macs. No subscription. No account for writing.
• WunderType: Free (Mac App Store). Confirm current features on their listing.

Get DraftKey

getdraftkey.com — download, buy the $4.99 lifetime license, grant Accessibility, let the model download once.

I built it. Aura Technologies. If suggestions are wrong in a specific app, I want to know.

Disclosure: I built TokenBar, under my indie studio Aura Technologies. It's built on CodexBar, a free, open-source, MIT-licensed menu-bar app. The MIT license permits commercial derivatives, and TokenBar keeps the required license and attribution. If CodexBar already does what you need, use it: it's free and good.

The problem

If you use more than one AI coding tool, spend is scattered across separate dashboards, billing pages, and usage limits. You usually find out you burned through a quota or a budget after the fact: a rate-limit wall mid-task or a surprise bill at month end. An agent left looping, or five parallel sessions, can move the number fast.

TokenBar puts that number where you'll actually see it: the menu bar.

What TokenBar does

• Menu-bar usage and spend for Claude Code, Codex, and Cursor in one place.
• Click for a breakdown by tool, so you can see which one is driving cost.
• Glanceable limits, so you notice you're close to a quota before you hit it.
• One-time $15 purchase. No account with us, no subscription.

The point isn't fancy analytics. It's making spend visible constantly so you change behavior in the moment: kill a stuck session, switch a task to a cheaper model, or stop for the day.

TokenBar vs CodexBar, honestly

CodexBar is the open-source foundation. TokenBar is a paid, packaged version from Aura Technologies focused on spend tracking across Claude, Codex, and Cursor. You're paying $15 for the packaging, the cost-focused presentation, and ongoing maintenance by a developer you can email. You are not paying for something that's impossible to get for free. If you're comfortable with an open-source app and its feature set covers your tools, CodexBar is a perfectly good choice.

Honest limits

• Mac only. It's a macOS menu-bar app.
• Numbers are only as good as the sources. Usage data comes from what each tool and provider exposes. Figures can lag, and providers change formats; when they do, an update may be needed.
• It's a monitor, not a controller. TokenBar shows spend; it doesn't cap it or stop your agents for you.
• No free trial. CodexBar is effectively the free way to see if a menu-bar tracker fits your workflow.

Who it's for

• Solo developers and freelancers paying for AI coding tools out of pocket.
• People juggling Claude Code, Codex, and Cursor at once.
• Anyone who has been surprised by an AI bill or a usage limit at a bad moment.

Get it

TokenBar is $15 lifetime at tokenbar.site. If a tool you use isn't covered or a number looks off, reach out via the site and I'll look into it.

This post is a practical method for turning a long Slack thread into notes that someone who wasn't there can read in ninety seconds. It works with any tool, including pen and paper. Near the end I'll mention the Mac app I built to speed up the rewriting step, but the method is the important part.

Why thread summaries go wrong

Most bad summaries fail in one of three ways:

1. They are chronological. "First Sam said X, then Priya pointed out Y." Readers don't care about the order of the conversation; they care about the outcome.
2. They hide the decision. The actual decision is buried in paragraph four, phrased as "it seemed like people were leaning toward..."
3. They drop the open questions. The thread ended with two unresolved issues, and the summary quietly pretends they don't exist. Two weeks later they resurface as surprises.

A good summary is organized by outcome, not by time.

The five-section template

Paste this into a doc, a Notion page, or a reply in the thread itself:

**Decision:** One or two sentences. What are we doing?
**Why:** The two or three reasons that actually carried the argument.
**Rejected options:** What we considered and why we didn't pick it.
**Open questions:** What is still unresolved, and who owns each one.
**Next steps:** Concrete actions with names and rough dates.

That's it. If a section is empty, write "None" instead of deleting it. An explicit "Open questions: None" tells readers the debate is really over.

Step 1: Skim for turning points, not content

Don't read the thread top to bottom trying to absorb everything. Scroll and look for moments where the direction changed:

• Someone posts data (a benchmark, a cost estimate, a customer quote).
• A senior person or the owner of the system weighs in.
• Someone says "ok, so..." or "sounds like we're going with..."
• Reactions cluster on a message (a pile of thumbs-up is often an implicit vote).

Copy those messages into a scratch file. For a 200-message thread you usually end up with ten to fifteen.

Step 2: Write the decision first

Write the decision sentence before anything else, in plain language: "We're moving session storage from Postgres to Redis, behind a feature flag, starting with the EU region."

If you can't write that sentence, the thread didn't reach a decision, and your summary should say so: "Decision: None yet. Two options remain (below); we need a call from the platform lead by Friday." That is still a useful summary. It's honest, and it gives the thread a path to closure.

Step 3: Keep reasons short and attributable

For the "Why" section, include only the reasons that changed minds. Three bullets is plenty. If a reason came from a specific person with specific context, attribute it lightly: "(per the on-call review)" or "(from the load test)". This gives readers a way to dig deeper without turning the summary into a who-said-what log.

Step 4: Rewrite for someone who wasn't there

This is the step that takes the longest and benefits most from help. Thread language is full of shorthand, inside references, and half-sentences: "yeah the thing from last sprint would bite us again lol." Your summary needs to say "this would repeat the cache invalidation bug from the March incident."

Read every bullet and ask: would a new hire understand this? Replace pronouns with nouns, expand acronyms the first time, and delete hedging words like "kind of," "probably," and "I think" unless the uncertainty is real.

Step 5: Post it where the thread lives

Post the summary as a reply in the original thread and pin it, or post it to the channel with a link to the thread. Tag the owners listed in "Open questions" and "Next steps." Summaries that live in a separate doc nobody links to get lost.

A worked example

Raw thread fragments:

"honestly redis is fine for this, we already run it for rate limiting" "what about persistence tho, if it restarts we log everyone out" "AOF every second is fine, we lose at most 1s of sessions" "ok can we just flag it and try EU first"

Summary:

Decision: Move session storage to Redis behind a feature flag, rolling out to the EU region first. Why: We already operate Redis for rate limiting; Postgres session reads are 30% of DB load; AOF persistence limits loss to about one second of sessions on restart. Rejected options: Memcached (no persistence); keeping Postgres with a read replica (doesn't reduce write load). Open questions: Session migration for logged-in users (owner: platform team). Next steps: Flag and EU rollout plan drafted by Thursday.

Where an on-device writer helps

Step 4, rewriting shorthand into clear sentences, is where I lean on a writing tool. Full disclosure: I built DraftKey, a Mac app from Aura Technologies that rewrites and tidies text using a model that runs entirely on your Mac. That matters for this use case specifically, because Slack threads often contain internal system names, incident details, and customer information that you may not want to paste into a cloud chatbot.

DraftKey is a $4.99 one-time purchase (no subscription) at getdraftkey.com. It needs macOS 14 or later on Apple Silicon, downloads a roughly 1.12GB local model, and works on up to three Macs. There's no free trial, so check the requirements first. It isn't the only one-time-purchase AI writing app for Mac, either; tools like Charm and RewriteBar are worth a look too.

Whatever you use, the template does most of the work. Decision first, open questions explicit, and written for the person who wasn't in the room.

This guide focuses on the prose side of DocC: what to write in summaries, discussions, articles and tutorials so that people can actually use your package.

Quick DocC refresher

• /// comments above a symbol become its documentation page.
• The first paragraph is the summary, shown in lists and Quick Help.
• Subsequent paragraphs are the discussion.
• - Parameters:, - Returns: and - Throws: document signatures.
• A .docc catalog holds articles, tutorials and a landing page.
• Build with Product → Build Documentation in Xcode or swift package generate-documentation with the Swift-DocC plugin.

Summaries: one sentence, starts with a verb or noun phrase

The summary is the most-read line of your docs. Rules:

• One sentence.
• Do not repeat the symbol name.
• Say what it does or what it is, not how.

/// Retries a failed request with exponential backoff.
func retry(_ request: URLRequest, attempts: Int) async throws -> Data

Not "This function retries the request," and definitely not "Retry."

For types, use a noun phrase: "A cache that evicts the least recently used entries when it reaches capacity."

Discussions: answer the questions people actually have

After the summary, write the discussion for someone deciding whether and how to use the symbol. Good discussions answer:

• When should I use this instead of the alternative?
• What are the defaults and gotchas?
• Is it thread-safe? Is it main-actor bound?
• What does a minimal example look like?

Include a short code example in almost every non-trivial discussion. Code is what people copy.

Parameters and errors: say what is valid

"attempts: The number of attempts" adds nothing. Instead:

/// - Parameters:
///   - attempts: Maximum number of tries, including the first. Must be at least 1.
/// - Throws: `RetryError.exhausted` after the final attempt fails.

Valid ranges, units and failure behavior are what readers need.

The landing page and articles

The generated symbol list is a reference, not an introduction. Add to your .docc catalog:

1. A landing page with a two-paragraph overview and a curated Topics section grouping symbols by task ("Making Requests", "Handling Errors") rather than alphabetically.
2. A Getting Started article that goes from adding the package to a working result in under five minutes.
3. One article per major concept, such as configuration, concurrency model and migration guides.

Curated topic groups are the biggest single upgrade most DocC sites can make. Alphabetical symbol lists force readers to already know what they are looking for.

Tutorials: optional, but powerful

DocC's interactive tutorials (step-by-step with code and images) are great for UI frameworks and onboarding-heavy packages. They take real time. Write the articles first; add a tutorial once you know which workflow confuses users most.

Style rules that help

• Present tense, active voice. "Returns the cached value," not "The cached value will be returned."
• Short paragraphs. DocC renders long paragraphs as walls of text.
• Link symbols. Use double backticks, such as RetryPolicy, to link to other symbols. Broken links show as warnings; fix them.
• Consistent terms. Pick "request" or "call" and stick to it.

A fast writing workflow

Documentation stalls because it feels like a separate project. Treat it like code review instead:

1. When you add or change a public symbol, write the summary in the same commit.
2. Once per release, build docs and scan for empty or one-word discussions.
3. Fix the five most important symbols each time rather than everything at once.

For the actual sentences, I draft rough notes in the comment and then tighten them. An inline AI rewrite tool that works in Xcode's editor is handy for turning "does retry w/ backoff, max attempts incl first" into a clean summary. For code that is not public yet, I want that processing on-device.

I use DraftKey for the prose part of this: on-device AI autocomplete and rewrite that works in the text fields of most Mac apps. It is $4.99 lifetime for up to 3 Macs, needs macOS 14+ on Apple Silicon, and downloads a roughly 1.12 GB local model, so drafts never leave the machine. There is no free trial, so check the requirements before you buy. It is not the only pay-once option; Charm, RewriteBar and others exist and are worth comparing. Disclosure: I built DraftKey (Aura Technologies).

Enforce it in CI

Build documentation in CI and treat warnings seriously. Broken symbol links and missing documentation for public APIs are easy to catch automatically. Some teams fail the build on DocC warnings for public modules, which keeps docs from drifting.

Bottom line

DocC does the hard rendering work. Your job is the summary that says what a symbol does, the discussion that says when to use it, a curated landing page and one good Getting Started article. Do those four things and your package documentation will be better than most on the Swift Package Index.

Here is a practical approach, with templates you can adapt, for replying to reviews without spending your whole evening on it.

Why replies matter

• Reviewers get notified. When you respond, the reviewer receives a notification and can update their review. A fixed bug plus a polite reply is the most reliable way to turn a 1-star into a 4-star.
• Future customers read them. People scanning reviews before buying see your replies. A calm, specific reply reads better than silence.
• They are public support docs. "How do I export?" answered once in a reply helps everyone who has the same question.

Ground rules

1. Never argue. Even if the reviewer is wrong, the audience is the next customer, not the reviewer.
2. Be specific. Mention the version, the fix or the setting. Generic "thanks for your feedback" replies read as bots.
3. Keep it short. Three or four sentences. Replies have a length limit and nobody reads long ones.
4. Point to a channel. Give a support email or page for issues you cannot solve in public.
5. Do not include personal data or ask for it publicly.

Templates

1-star: bug report

Thanks for reporting this, and sorry it hit you. The crash when importing large files is fixed in version 2.3, which is live now. If you still see it after updating, please email support@[yourdomain] with your macOS version and we will dig in.

1-star: misunderstanding the product

Sorry for the confusion. [App] is designed for [use case], so [missing feature] isn't included. We've updated the description to make this clearer. If you bought by mistake, Apple can process a refund at reportaproblem.apple.com.

Pointing to the refund page is honest and often defuses anger.

2–3 stars: feature request

Thanks for the detailed feedback. Folder sync is the most requested feature right now and it's on the roadmap. Follow updates at [link]. In the meantime, the export shortcut in Settings may cover part of what you need.

Do not promise dates you cannot keep.

3 stars: pricing complaint

Understood, and thanks for being direct. We price [App] as a one-time purchase so there's no ongoing subscription. If something specific made it feel not worth it, we'd genuinely like to hear: support@[yourdomain].

4–5 stars

Thank you! Glad the keyboard shortcuts are saving you time. If you ever want a feature added, the suggestion form is at [link].

Reply to some positive reviews, not all. Replying to every five-star review with the same line looks automated.

A weekly routine

You do not need to reply in real time. A 20-minute weekly session works:

1. Open App Store Connect → your app → Ratings and Reviews. Sort by most recent.
2. Reply to every 1–2 star review that describes a real issue.
3. Reply to feature requests that you have an answer for.
4. Reply to a handful of detailed positive reviews.
5. Copy recurring complaints into your issue tracker, tagged "from reviews."

Step five is the important one. Reviews are free user research, and patterns across ten reviews tell you more than any single angry one.

After a fix ships

When you release a fix for an issue mentioned in reviews, go back and update your replies: "Fixed in 2.3, please update." Reviewers often re-rate after seeing this. It is the highest-return 10 minutes of the release.

Writing them quickly without sounding canned

The templates cover structure, but each reply still needs a specific sentence or two. The fastest workflow I have found is to type a rough, honest reply first ("sorry, that bug is fixed in 2.3, update and email if not") and then clean up the tone. Tone is where tired developers slip: a reply written at 11 PM after a bad review can come off defensive.

An inline rewrite tool helps here, particularly one that works directly in the App Store Connect text field in Safari, so you are not copying text between windows.

I use DraftKey for the prose part of this: on-device AI autocomplete and rewrite that works in the text fields of most Mac apps. It is $4.99 lifetime for up to 3 Macs, needs macOS 14+ on Apple Silicon, and downloads a roughly 1.12 GB local model, so drafts never leave the machine. There is no free trial, so check the requirements before you buy. It is not the only pay-once option; Charm, RewriteBar and others exist and are worth comparing. Disclosure: I built DraftKey (Aura Technologies).

Things to avoid

• Copy-pasting the same reply to ten reviews
• Asking for a better rating in exchange for help
• Blaming Apple, the user's Mac, or "other apps"
• Replying while annoyed; wait until the next day

Bottom line

Replies are cheap, public and permanent. Treat each one as a note to the next person deciding whether to buy, and the reviewer is a bonus. A short, specific, calm reply beats silence every time.

The test: can someone start in five minutes?

Before you hit create, imagine a teammate who was on vacation last week opening the ticket. Could they start working within five minutes, without messaging you? If not, the ticket is missing one of four things: context, the expected outcome, the boundaries, or a way to verify it is done.

A ticket template that covers all four

Paste this into a Linear template (Settings → Templates) so every new issue starts with it:

## Why
One or two sentences on the user or business problem. Link the source:
support thread, customer call notes, metric dashboard.

## What done looks like
- Observable behavior after the change
- Edge case that must work
- Anything explicitly out of scope

## Notes
- Relevant files, endpoints or feature flags
- Known risks or prior attempts
- Design link if there is one

## How to verify
Steps a reviewer can follow, or the test that should pass.

That is it. Four headings. Teams over-engineer templates with ten fields and then nobody fills them in. Four short sections get filled in.

Titles that sort well

Linear lists are scanned, not read. Write titles as verb plus object plus qualifier:

• Bad: "Onboarding bug"
• Better: "Fix skipped email verification step on iOS onboarding"
• Bad: "Performance"
• Better: "Cut dashboard initial load below 2s for workspaces with 500+ projects"

A title should make sense in a notification, a cycle report and a changelog without opening the ticket.

Write the "Why" first, even when it feels obvious

The "Why" section is where most of the value is and where most people cut corners. "Users are confused" is not a why. "Three enterprise trials last week stalled at step 2 because the verification email went to spam; see support thread" is a why. It tells the engineer what to optimize for, and it lets them push back if there is a cheaper fix.

If you are writing a batch of tickets after a planning session, draft all the "Why" paragraphs first while the conversation is fresh, then fill in the rest.

Scope is a feature

The single most useful bullet in any ticket is "Out of scope." It prevents the reviewer from asking for a redesign in the PR and stops the implementer from gold-plating. One line is enough: "Out of scope: changing the email provider."

Make verification concrete

"Test it" is not verification. Write the steps:

1. Create a new account with a Gmail address
2. Complete step 1
3. Confirm the verification screen appears and the email arrives within 60s

If an automated test should cover it, name the test file. This doubles as the QA checklist and as the PR description later.

Splitting tickets

If "What done looks like" has more than five bullets, it is probably two tickets. Split by user-visible outcome, not by layer. "Backend for X" and "Frontend for X" tickets tend to block each other; "X works for free plans" and "X works for enterprise plans" can ship independently.

Writing them faster on a Mac

The template handles structure. The slow part is the prose: turning messy notes into clear sentences. A few habits help:

• Keep a scratch note open during planning. Apple Notes or a plain text file. Dump raw bullets, then turn each into a ticket afterward.
• Use Linear's keyboard flow. C creates an issue, Cmd+Enter saves, and templates can be picked from the create dialog.
• Rewrite, don't compose. It is easier to clean up a rough sentence than to write a perfect one. Type the rough version fast, then tighten it.
• Link, don't paste. Long logs and screenshots belong in attachments or linked docs, not inline walls of text.

For the rewrite step, an inline AI writing tool helps, especially one that works directly in Linear's editor rather than in a separate chat window. Ticket text often includes customer names, internal URLs and unreleased features, so I prefer a tool that runs locally rather than sending text to a cloud API.

I use DraftKey for the prose part of this: on-device AI autocomplete and rewrite that works in the text fields of most Mac apps. It is $4.99 lifetime for up to 3 Macs, needs macOS 14+ on Apple Silicon, and downloads a roughly 1.12 GB local model, so drafts never leave the machine. There is no free trial, so check the requirements before you buy. It is not the only pay-once option; Charm, RewriteBar and others exist and are worth comparing. Disclosure: I built DraftKey (Aura Technologies).

Comments are part of the ticket

When requirements change, update the description, not just the comments. A ticket whose real spec lives in comment 14 fails the five-minute test. A short "Updated scope: …" line at the top of the description, with a date, keeps history clear.

A quick checklist

Before creating a ticket:

• Title is verb + object + qualifier
• "Why" links to a real source
• At least one out-of-scope line
• Verification steps someone else can follow
• Under five "done" bullets, or split

Good tickets are not about process for its own sake. They are about letting people start work without waiting for you, which is the whole point of writing things down.

This is a Mac-oriented workflow for writing technical specs beside the code, then publishing outward only when the shape is stable.

Put the spec in the repo from day one

Create docs/spec.md (or docs/rfcs/0007-short-name.md) in the branch that will implement the change. Same PR can carry the first implementation and the doc. Reviewers see both.

Minimal skeleton:

# Title

Status: Draft | Accepted | Superseded
Author:
Last updated: 2026-10-24

## Problem
## Goals / non-goals
## Proposal
## Alternatives considered
## Rollout / migration
## Open questions

Non-goals earn their section. Most bad specs fail by trying to solve three products at once. If a stakeholder keeps adding scope, point at non-goals instead of rewriting the proposal in chat.

Write in the editor you already use

• VS Code / Cursor / Zed: open docs/spec.md in a split next to the code you are probing.
• Neovim: same idea with a vertical split; use spell and markdown preview if you want.
• Prefer Markdown over a proprietary doc format until stakeholders demand otherwise.

If someone needs Notion or Google Docs for comments, paste a frozen export after the engineering review—not before. Early comments in a rich doc encourage wordsmithing over deciding. Keep the canonical path in git so git blame still works six months later.

A 45-minute first draft loop

1. 10 min — Problem and goals. Write from the bug report or the customer quote. No architecture yet.
2. 15 min — Proposal as bullets. Interfaces, data shape, failure modes. Link to files that will change (app/auth/session.ts).
3. 10 min — Alternatives. List two you rejected and why. This prevents the "did you consider X?" drive-by.
4. 10 min — Open questions. Anything you still do not know. Assign owners if you can.

Ship that as a draft PR description or a Draft status RFC. Perfect prose is optional; clear tradeoffs are not. If you cannot finish in 45 minutes, the problem statement is probably too big—split the RFC.

Language helpers that stay out of your way

Spec writing is still writing: tightening goals, turning notes into sentences, fixing tone so it does not sound like a chat log. Cloud assistants are fine when the spec has no secrets. When it names customers, infra, or unreleased strategy, keep text local.

DraftKey provides on-device AI autocomplete and rewrite inside Mac apps ($4.99 lifetime, up to 3 Macs, macOS 14+, Apple Silicon, about 1.12 GB model, no trial). Disclosure: I built DraftKey. Use it—or any local helper—while the draft still contains things you would not paste into a random chatbot.

From editor draft to team artifact

Link the merged path in Linear or GitHub Issues so the tracker points at the source of truth, not a stale paste. When the implementation ships, add a one-line "Shipped in vX.Y" note at the top so readers know the doc is not aspirational.

Habits that keep specs alive

• Update the Last updated date when behavior changes—not only when you rewrite the whole doc.
• If implementation diverges, add a short Amendment section instead of silent drift.
• Delete or mark Superseded when a newer RFC wins. Zombie specs confuse new hires.
• Link related ADRs or RFCs; do not paste them inline.

Draft beside the code, review as engineering text, export only when needed. Your future self, reading docs/ six months later, is the primary audience.

What "good enough" looks like in review

Ask reviewers for decisions, not copy edits:

• Does the problem statement match the issue they feel?
• Are non-goals actually non-goals, or polite fiction?
• Is the rollout reversible?
• Which open question blocks implementation?

If feedback is mostly tone and commas, the spec was already clear enough—merge and move the prose polish to a follow-up. Conversely, if reviewers argue about the problem, stop coding; fix the Problem section first.

Pairing specs with tickets

Every Accepted RFC should have:

• One parent issue or epic in Linear/GitHub.
• Child issues for rollout steps that are not "obvious."
• A link back from the issue to docs/rfcs/... on main.

Without that loop, the beautiful Markdown file becomes archaeology. The editor-first workflow only works if the tracker still points at git as source of truth.

Most AI writing tools want a monthly payment. That makes sense for apps that run every request on a cloud GPU, but a growing number of Mac apps run a small language model on your own Apple Silicon chip. When the compute is yours, a one-time price becomes realistic.

I went through the Mac writing apps that AI assistants usually recommend for "one-time purchase AI writing app for Mac" and checked each one's pricing page in October 2026. One of them is mine, and I say so where it comes up. Prices change, so check the linked pages before you buy.

Quick comparison

• DraftKey: price: $4.99 once; what it mainly does: Inline autocomplete (Tab) + rewrite panel; runs on-device?: Yes, built-in model; macs per license: Up to 3
• WunderType: price: $8.99 once; what it mainly does: Rewrite/fix selected text with a shortcut; runs on-device?: Optional (built-in MLX models or Ollama); macs per license: Not stated on homepage
• Charm: price: $19.99 once; what it mainly does: Spelling, grammar and next-word prediction; runs on-device?: Yes, built-in model; macs per license: Up to 3
• RewriteBar: price: Free tier; $29 or $59 once; what it mainly does: Command palette of AI actions on selected text; runs on-device?: Optional (Ollama, LM Studio, Apple Intelligence and others); macs per license: 1 (Standard), 3 (Pro)
• Cotypist: price: Free tier; $72/yr or $108/yr; what it mainly does: Inline autocomplete; runs on-device?: Yes; macs per license: 1 (Plus), 3 (Pro)

Cotypist is a subscription, so it's not strictly in scope, but it has a usable free tier and it's the app most people compare the others against, so it belongs in the table.

1. DraftKey: autocomplete and rewrites for $4.99

$4.99 once: getdraftkey.com

DraftKey does two things in compatible Mac text fields. While you type, it suggests the next words in gray and you press Tab to accept them. When you want to change something you already wrote, you tap Command + Option to open a rewrite panel on the current paragraph or your selection, then pick Fix writing, Shorter, Clearer, a tone like Friendly or Professional, or type your own instruction. You review the result before it's inserted.

The model runs on your Mac and works offline after setup. The internet is used only for the model download, license activation and update checks. The license also includes a 10-item clipboard history and mechanical keyboard sounds.

The honest trade-offs:

• It needs an Apple Silicon Mac on macOS 14 or later, with at least 8 GB of memory.
• The model is a separate download of about 1.12 GB.
• There's no free trial and no automatic money-back guarantee, so you're buying on the strength of the site and reviews.
• Some custom editors and secure fields aren't supported.

I built it, so weigh my description accordingly.

2. WunderType: the cheapest one-key rewrite tool

$8.99 once: wundertype.com

WunderType is a small (~20 MB) menu bar app. Select text in any app, press ⌘⇧G, and it fixes or rewrites the selection in place. It ships with five modes and lets you add unlimited custom prompts, each with its own keyboard shortcut.

Version 1.5 added on-device models that run through Apple's MLX framework (Gemma 3, Granite and Phi-4 Mini options), so you don't need Ollama or an API key. You can also point it at Ollama, your own OpenAI key or OpenRouter. It has no account, no server and no telemetry.

Good fit if: you want quick fixes on demand and don't want suggestions appearing while you type. WunderType doesn't do inline autocomplete.

3. Charm: a one-time Grammarly replacement

$19.99 once, 14-day money-back guarantee: theodorehq.com/charm

Charm corrects spelling and grammar as you type and predicts your next word, which you accept with Tab. Everything runs on a local model: you choose between a Fast model (about 1.5 GB) and a Best Quality model (about 2.3 GB). A license covers up to three Macs.

It's focused on correctness rather than rewriting tone, and it currently supports UK and US English. It doesn't correct as you type in Google Docs, though its Fix Selection shortcut covers apps that can't be edited live.

Good fit if: your main goal is replacing Grammarly's spelling and grammar checks without a subscription. The 14-day refund window also makes it the lowest-risk purchase on this list.

4. RewriteBar: the power-user command palette

Free tier; $29 Standard or $59 Pro, one-time: rewritebar.com

RewriteBar opens a palette of AI actions on your selected text: fix grammar, change tone, translate (500+ languages, depending on the model), summarize, format JSON or SQL, and dozens more. You can build custom actions and chain several together, and it integrates with PopClip.

On privacy, it depends on your setup. The default RewriteBar provider sends your text through RewriteBar's server (which says it doesn't store it). Third-party providers get your text directly from your Mac. For fully local use, it supports Ollama, LM Studio, oMLX, Apple Intelligence and Osaurus. Standard covers one device; Pro covers three and adds a year of its cloud Gateway.

Good fit if: you want the biggest menu of actions and providers and don't mind some setup.

5. Cotypist: the autocomplete benchmark (subscription)

Free tier; Plus $72/yr, Pro $108/yr: cotypist.app

Cotypist is the best-known inline autocomplete app for Mac. It predicts your next words in nearly every app, entirely on-device, and you press Tab to take the next word or the whole line. It learns your vocabulary and phrasing over time and can use what's on screen as context.

The free tier gives full suggestions for your first 100 accepted words a day, and every install starts with a 30-day Pro trial with no card. Cotypist recommends an M1 Pro or M2 with 16 GB of memory for the smoothest experience.

Good fit if: autocomplete quality is your top priority and a yearly subscription doesn't bother you. If it does, it's worth comparing against the one-time options above.

What "lifetime" actually means

Before buying any one-time license, read the terms:

• Updates: some licenses cover all future updates, and others cover only the current major version. Charm's terms, for example, include free updates to the current major version. DraftKey's FAQ says updates come through the app but the license doesn't guarantee every future major version.
• Devices: check how many Macs a license covers. It ranges from one to three here.
• Hidden running costs: with tools that use cloud models through your own API key (RewriteBar, WunderType), you pay the provider per use. Local models cost nothing extra.
• Refunds: Charm offers 14 days. DraftKey has no automatic guarantee. Check the others before you pay.

How to choose

• You want suggestions while you type: DraftKey, Charm (word prediction) or Cotypist.
• You want to fix or rewrite text on demand: WunderType, RewriteBar or DraftKey's rewrite panel.
• You want grammar correction first: Charm.
• You want the most actions and AI providers: RewriteBar.
• You want the lowest price: DraftKey at $4.99, then WunderType at $8.99.

Which one-time Mac apps did I miss? Tell me in the comments.

Disclosure: I built DraftKey.

1. Stop using -m for anything that matters

git commit -m "fix stuff" is fast because it skips the editor, and that's the problem: a one-liner is the only thing it encourages. Keep -m for truly trivial commits (a typo, a version bump) and let Git open an editor for everything else. That's where the next few steps pay off.

2. Pick an editor that opens fast and blocks properly

Git opens whatever core.editor is set to and waits until that editor closes the file. If you've never set it, you're probably getting Vim, which is fine if you know Vim and miserable if you don't.

For VS Code (after running Shell Command: Install 'code' command in PATH from the Command Palette):

git config --global core.editor "code --wait"

The --wait flag matters. Without it, code returns right away and Git sees an empty message and aborts the commit.

If you'd rather stay in the terminal, nano ships with macOS and needs no setup:

git config --global core.editor "nano"

Write the message, press Control-O to save, Control-X to exit, and the commit goes through.

3. Add a commit template that asks the right questions

A template is a plain text file Git pre-fills into the editor every time you commit without -m. Lines starting with # are comments and get stripped automatically, so you can leave yourself prompts that never end up in history.

Create ~/.gitmessage:

# Subject: imperative, ~50 chars, no period
#   e.g. "Fix race in session refresh"
#
# Body (wrap at 72): WHY this change, not what the diff shows.
#   - What was wrong or missing?
#   - Why this approach over the obvious alternative?
#   - Anything a reviewer or future you should watch for?
#
# Trailers (optional):
#   Refs: #123
#   Co-authored-by: Name <email>

Then point Git at it:

git config --global commit.template ~/.gitmessage

The empty first line is deliberate: your cursor lands where the subject goes. The prompts do the real work. When you're tired, "why this approach over the obvious alternative?" is the question you'd skip, and it's usually the one a reviewer most wants answered.

If a repo has its own conventions (say, Conventional Commits like feat: and fix:), set a repo-level template that overrides the global one:

git config commit.template .gitmessage

4. Write with the diff on screen

Half the effort of a commit message is remembering what you actually changed. Let Git show you:

git config --global commit.verbose true

Now every commit editor includes the full staged diff below the message, under a "scissors" line. Everything from that line down is removed before the commit is saved, so it's there for reference only. You can scroll down, see exactly what's staged, and describe it accurately instead of from memory.

Two more commands worth running before you write:

git diff --staged --stat   # which files, how much
git log --oneline -10      # how this repo usually phrases subjects

The second one is the fastest way to match a team's style without reading a contributing guide.

5. Commit in smaller pieces so each message is easy

A message is hard to write when the commit does four things. git add -p walks through your changes hunk by hunk and asks whether to stage each one (y, n, s to split a hunk, q to quit). Stage one logical change, commit it, and repeat. Each message then has a single subject that's obvious.

For follow-up fixes to an earlier commit on your branch, skip the message entirely:

git commit --fixup=<sha>
git rebase -i --autosquash main

--fixup creates a commit titled fixup! <original subject>, and --autosquash folds it into the original during the rebase. Your branch ends up with clean commits and no "address review comments" noise.

And if you notice a bad message right after committing, git commit --amend reopens the last message in your editor (only do this before you've pushed, or be ready to force-push your own branch).

6. Add trailers without typing them

Recent versions of Git have a --trailer flag that appends a properly formatted trailer to the message:

git commit --trailer "Co-authored-by: Sam Lee <sam@example.com>"

If you pair with the same people often, turn it into a Git alias in ~/.gitconfig:

[alias]
    cosam = commit --trailer "Co-authored-by: Sam Lee <sam@example.com>"

Now git cosam opens your normal template with the trailer already added.

7. Give the repo a pull request template

GitHub pre-fills new pull requests with the contents of .github/pull_request_template.md if it exists on the default branch. A short one works better than a long one, because people actually fill it in:

## What
<!-- One or two sentences. -->

## Why
<!-- The problem, link to the issue. -->

## How to test
1.

## Notes for reviewers
<!-- Risky parts, follow-ups, anything you're unsure about. -->

HTML comments are hidden when the description is rendered, so the prompts don't clutter the final PR.

8. Draft the PR from the terminal with gh

If you've written good commits, most of the PR description already exists. The GitHub CLI (brew install gh, then gh auth login) can reuse it:

gh pr create --fill

--fill uses your commit info for the title and body. For a single-commit branch, that's often the whole PR. For bigger branches, build a body from your commit subjects and copy it to the clipboard with macOS's built-in pbcopy:

git log --reverse --format='- %s' main..HEAD | pbcopy

Paste that into the "What" section as a starting changelog, then spend your effort on "Why" and "Notes for reviewers," which no tool can write for you.

Other flags worth knowing:

• gh pr create --draft opens it as a draft so CI can run before reviewers get pinged.
• gh pr create --body-file pr.md uses a file you wrote in your editor.
• gh pr create --web opens the browser form with your branch selected, if you prefer to finish there.

9. Keep short review phrases one keystroke away

For the bits you type over and over in PR descriptions and review comments ("How to test," "nit:", "LGTM once CI passes"), macOS Text Replacements work in Safari and most native text fields. Add them under System Settings > Keyboard > Text Replacements, and they sync across your Apple devices. Browser-based editors and Electron apps don't always honor them, so test in the places you actually write.

A five-minute setup checklist

1. Set core.editor to something with a proper --wait.
2. Create ~/.gitmessage and set commit.template.
3. Turn on commit.verbose.
4. Get in the habit of git add -p and git commit --fixup.
5. Add .github/pull_request_template.md to your repos.
6. Install gh and try gh pr create --fill on your next branch.

None of this writes your messages for you. It removes the friction around writing, so the thirty seconds you spend explaining why goes into the message instead of fighting your tools.

One more tool, if you want it

Disclosure: I built DraftKey, a Mac app that adds private, on-device AI autocomplete and rewriting to every Mac app, which helps when you're drafting PR descriptions and review comments. Nothing you type leaves your Mac. It's $4.99 lifetime (up to 3 Macs) and needs macOS 14 or later on Apple Silicon: getdraftkey.com. The setup above works perfectly well without it.

1. Write the title as "what happened, where"

The title is what a maintainer sees in a list of 200 open issues. Make it specific enough to triage without clicking.

• Bad: App crashes
• Bad: URGENT!!! export broken
• Good: Crash when exporting a PDF with an empty title field (v2.3.1, macOS 15)

A useful pattern: action + symptom + condition. "Saving a file over SMB hangs for 30s when the share is offline" tells the reader what you were doing, what went wrong, and the condition that seems to matter.

2. Steps to reproduce: numbered, minimal, from a clean start

This is the section that decides whether your bug gets fixed. Write steps someone else can follow without guessing:

1. Start from a fresh state (new project, logged out, default settings, whatever "clean" means for this app).
2. Number every step, one action per line.
3. Include the exact input you used. If you typed something, paste it. If you opened a file, attach it or describe how to make one.
4. Then cut it down. Remove each step and check whether the bug still happens. The shortest list that still reproduces the bug is worth far more than the full story of your afternoon.

If you can't reproduce it reliably, say so and say how often: "about 1 in 5 tries" is useful information, not an admission of failure.

3. Expected vs actual, as two separate lines

Don't make the reader infer what you thought should happen.

Expected: The PDF exports with "Untitled" as the document title.
Actual: The app quits immediately. No error dialog.

Two lines. It forces you to notice when the "bug" is really a disagreement about intended behavior, which is a different (and often faster) conversation.

4. Grab your environment details in one command

Version numbers are the most commonly missing piece of a bug report. On a Mac you can get the OS details in one go:

sw_vers

That prints the product name, version, and build. For the chip and memory, add:

sysctl -n machdep.cpu.brand_string
system_profiler SPHardwareDataType | grep -E "Chip|Memory"

Pipe any of it straight to your clipboard so you never retype version numbers by hand:

{ sw_vers; sysctl -n machdep.cpu.brand_string; } | pbcopy

Then add the app's own version (usually in its About window) and, for CLI tools, the output of tool --version. For web apps, include the browser and its version.

5. Show it: screenshots and screen recordings without extra apps

macOS has everything built in:

• Cmd + Shift + 4 captures a selected area. Press Space after it to capture a single window.
• Cmd + Shift + 5 opens the capture toolbar, including Record Selected Portion, which is perfect for a 10-second clip of the bug happening.
• Add Control to either screenshot shortcut (for example Cmd + Control + Shift + 4) to copy to the clipboard instead of saving a file, so you can paste straight into a GitHub issue.

GitHub accepts .mov and .mp4 uploads directly in issues, so a short recording often replaces a paragraph of description. Crop it to the part that matters.

6. Attach the logs that matter (not all of them)

Logs help when they're relevant and trimmed. A few Mac-specific places to look:

• Crash reports: open Console.app, choose Crash Reports in the sidebar, and find the entry for the app. These also live in ~/Library/Logs/DiagnosticReports/.
• Live logs: in Console.app, start streaming, filter by the process name, reproduce the bug, then stop and copy the relevant lines.
• Terminal output: rerun the failing command and capture everything, including errors:

your-command --verbose 2>&1 | tee bug-output.txt

Paste the relevant lines in a fenced code block, and attach the full file if it's long. Before you post, search the output for tokens, API keys, email addresses, and file paths that reveal more than you want. Redact them.

Need a file path for the report? In Finder, right-click the file, hold Option, and choose Copy "filename" as Pathname.

7. Say what you already tried

One short list saves a round trip:

Already tried:
- Restarted the app and the Mac
- Reinstalled v2.3.1
- Same crash with a brand-new user account
- Does NOT happen in v2.2.0

That last line is gold. "It worked in the previous version" narrows the search to one diff.

8. Make the template do the remembering

If you maintain a project, don't rely on reporters reading a guide like this. Add a GitHub issue form at .github/ISSUE_TEMPLATE/bug_report.yml:

name: Bug report
description: Something isn't working
labels: ["bug"]
body:
  - type: textarea
    id: steps
    attributes:
      label: Steps to reproduce
      placeholder: "1. ...\n2. ...\n3. ..."
    validations:
      required: true
  - type: textarea
    id: expected-actual
    attributes:
      label: Expected vs actual behavior
    validations:
      required: true
  - type: input
    id: version
    attributes:
      label: App version and macOS version
      placeholder: "v2.3.1 on macOS 15.1 (paste output of sw_vers)"
    validations:
      required: true
  - type: textarea
    id: logs
    attributes:
      label: Logs or screenshots
      render: shell

Required fields mean you stop getting issues with no version number. If you start from the terminal, this opens the new-issue page, where the form appears:

gh issue create --web --repo owner/repo

9. Reread it as the person who has to fix it

Before you hit submit, read your report as someone who has never seen your screen. Could they reproduce it in five minutes without asking you anything? If not, the missing piece is usually a version number, an input file, or a step you did without thinking.

Keep the tone neutral. "Export crashes with an empty title" gets fixed faster than "your app is garbage," and maintainers are people who chose to give their time away.

A quick checklist

• Specific title: action, symptom, condition
• Numbered, minimal steps from a clean start
• Expected vs actual on separate lines
• sw_vers output plus the app's version
• Screenshot or short recording
• Trimmed, redacted logs
• What you already tried, and the last version that worked

One more tool, if you want it

Disclosure: I built DraftKey, a Mac app that adds private, on-device AI autocomplete and rewriting to every Mac app, which helps when you're writing up issues, review comments, or support replies. Nothing you type leaves your Mac. It's $4.99 lifetime (up to 3 Macs) and needs macOS 14 or later on Apple Silicon: getdraftkey.com. Everything above works fine without it.

None of this takes talent to avoid. It takes a few habits. Here's the routine I use when I review pull requests, plus the small tools that make it faster.

1. Say how much the comment matters

The most useful thing you can add to a review comment is a label. Without one, the author has to guess whether "maybe rename this?" is a request or a passing thought, and careful authors treat every comment as blocking.

The Conventional Comments format (conventionalcomments.org) gives you a small vocabulary for this. A few labels cover most reviews:

• issue: something that needs to change before merging.
• suggestion: a concrete improvement you'd like but could live without.
• question: you don't understand something yet. No change implied.
• nitpick: trivial and optional, like naming or formatting.
• praise: something done well. Use it when it's true.

You can add a decoration like (non-blocking) or (blocking) to remove any doubt:

suggestion (non-blocking): This loop could use Array.some instead of tracking a flag. Fine to leave as is.

Even if your team never adopts the format officially, writing "Non-blocking:" or "Nit:" at the start of a comment does most of the work.

2. Make the comment self-contained

Write each comment so it makes sense to someone reading it in an email notification, without the surrounding thread. A good comment has three parts:

• What you noticed. Point at the specific line or behavior.
• Why it matters. A bug, a performance cost, a readability problem, a convention.
• What you'd do instead. Or, if you don't know, say that.

Instead of:

This is wrong.

Write:

issue: If user is null here (logged-out visitors hit this path), this throws before the redirect. Could we return early when there's no user?

The second version takes fifteen more seconds to write and saves a round trip.

3. Ask real questions, not rhetorical ones

"Why didn't you just use the existing helper?" sounds like a question but reads as an accusation. If you're genuinely asking, make it clear you might be missing context:

question: Is there a reason not to use formatDate from utils here? I may be missing a case it doesn't handle.

If you aren't asking, don't phrase it as a question. Make the suggestion directly.

4. Comment on the code, not the person

Small wording changes shift the tone a lot:

• "You forgot to handle errors" becomes "This call doesn't handle a failed request."
• "Your naming is confusing" becomes "I misread data2 as a copy of data. Something like filteredRows would help."
• "Why would you do it this way?" becomes "What led to this approach? I'd have expected X."

Using "we" and "this code" instead of "you" isn't about being soft. It keeps the discussion on what to change.

5. Use suggested changes for small fixes

If the fix is a line or two, don't describe it. On GitHub, the "Add a suggestion" button in a review comment inserts a suggestion block, and the author can apply it with one click. GitLab has the same idea with its "Insert suggestion" button. It's faster for both of you and leaves no room for misreading.

Save prose for things that need a decision: design, naming of public APIs, trade-offs.

6. Batch your comments into one review

Leaving comments one at a time sends a notification for each one, and the author may start fixing things before you've finished reading. On GitHub, use "Start a review" on your first comment instead of "Add single comment," then submit everything at once with a summary.

The summary is worth a few sentences:

Looks good overall. One blocking issue with the null user path in session.ts; the rest are suggestions and nits, so feel free to skip those. Happy to approve once the null case is handled.

That tells the author where to start and how far they are from done.

7. Keep reusable phrasing ready

You probably write some of the same comments every week: "Could you add a test for this case?", "Can we split this into a separate PR?", "Nit: unused import." A few ways to stop retyping them:

• GitHub saved replies. In your GitHub settings, under Saved replies, you can store canned responses and insert them from the comment box.
• macOS Text Replacements. In System Settings > Keyboard > Text Replacements, set short triggers like ;nb for "Non-blocking:" or ;test for "Could you add a test that covers this case?" They work in most Mac apps and text fields.
• A notes file with your team's review conventions, so new reviewers write comments the same way.

Templates handle fixed phrases well. Where they fall short is the part that's different every time: explaining a specific bug, or softening a comment you wrote while annoyed.

8. Reread before you submit

Before submitting, skim your own comments once with three questions:

1. Is it clear which comments block the merge?
2. Could the author act on each comment without asking me what I meant?
3. Would I be fine receiving this comment on my own code?

If a comment fails the third question, rewrite it. If it fails the second, add the "why" or a suggested change.

Where an AI writing tool can help

For the reread step and the writing in between, an AI writing tool can speed things up. The main thing to watch is where your text goes. Review comments often quote proprietary code, and many companies don't allow pasting that into a cloud chatbot.

I built DraftKey for this kind of writing. It's a Mac app that runs its model on your Mac, so your text isn't sent to a cloud AI service. As you type, it suggests the next words in gray and you press Tab to accept them. When you want to change something you already wrote, you tap Command+Option to open a rewrite panel with Fix writing, Shorter, Clearer, tone options like Friendly or Professional, or your own instruction. "Make this less blunt but keep the request" is a good one for review comments.

The honest details: it's $4.99 once for up to 3 Macs, it needs macOS 14 or later on Apple Silicon, and there's no free trial. It works in compatible Mac text fields, and some custom editors aren't supported, so how well it works in a given browser or editor depends on how that app exposes its text. It's at getdraftkey.com.

You don't need it to do anything in this article. The habits are what matter.

A quick checklist

• Label each comment: issue, suggestion, question, nitpick, or praise
• Say what, why, and what you'd do instead
• Ask real questions or make direct suggestions
• Talk about the code, not the person
• Use suggested changes for one- or two-line fixes
• Batch comments into one review with a short summary
• Keep saved replies or text replacements for repeated phrases
• Reread once before submitting

Try labeling your comments for a week. In my experience, it's the change that cuts the most back-and-forth.

Disclosure: I built DraftKey.

Grammarly, autocomplete tools, text expanders, window managers and screen readers all have the same problem on macOS. They need to work inside apps they didn't write. Nearly all of them solve it with the Accessibility API, the same interface VoiceOver uses. If you've ever wondered why one of these tools works in Mail but not in some editor, or why it asks for a scary-sounding permission, this is how the pieces fit together.

Step 0: become a trusted client

Your app can't read other apps' UI until the user adds it under System Settings → Privacy & Security → Accessibility. You check for that and ask for it with one call:

import ApplicationServices

let opts = [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as String: true] as CFDictionary
let trusted = AXIsProcessTrustedWithOptions(opts)   // shows the system prompt if needed

AXIsProcessTrustedWithOptions returns whether your process is a trusted accessibility client. With the prompt option set, macOS shows its own dialog that points the user to System Settings. You can't grant this permission in code, and that's on purpose.

The permission is broad. A trusted client can read the contents and structure of almost any app's windows. That's why it's worth knowing who made any tool you grant it to.

Step 1: find the focused text field

Everything in the Accessibility API is an AXUIElement, an opaque reference to a UI object in another process, with named attributes you can read. Start at the system-wide element and ask what has focus:

func focusedElement() -> AXUIElement? {
    let system = AXUIElementCreateSystemWide()
    var value: CFTypeRef?
    guard AXUIElementCopyAttributeValue(system, kAXFocusedUIElementAttribute as CFString,
                                        &value) == .success else { return nil }
    return (value as! AXUIElement)
}

From there, these are the attributes a writing tool cares about:

• kAXRoleAttribute / kAXSubroleAttribute: is this a text field, a text area, or something else?
• kAXValueAttribute: the full text of the field.
• kAXSelectedTextRangeAttribute: the selection as a character range (not bytes). An empty range gives you the caret position. Apple's docs say this attribute is required for all editable text elements, which is why it's the most reliable one to build on.
• kAXSelectedTextAttribute: just the selected text.

With the value and the caret position, you have the context a model needs: the text before the cursor, and maybe a little after it.

Step 2: find where the caret is on screen

To draw ghost text or a popup next to the cursor, you need screen coordinates. That's what parameterized attributes are for. kAXBoundsForRangeParameterizedAttribute takes a range and returns the bounding rectangle of that text as it appears on screen:

func caretRect(_ el: AXUIElement, location: Int) -> CGRect? {
    var range = CFRange(location: location, length: 0)
    guard let axRange = AXValueCreate(.cfRange, &range) else { return nil }
    var out: CFTypeRef?
    guard AXUIElementCopyParameterizedAttributeValue(
            el, kAXBoundsForRangeParameterizedAttribute as CFString, axRange, &out) == .success
    else { return nil }
    var rect = CGRect.zero
    AXValueGetValue(out as! AXValue, .cgRect, &rect)
    return rect
}

Two practical notes:

• Some apps return an empty rectangle for a zero-length range. A common fallback is to ask for the bounds of the character just before the caret and use its right edge.
• The rectangle uses top-left-origin screen coordinates, while AppKit windows use bottom-left. Flip the y value against the main screen's height before you position your overlay.

Step 3: react to typing without polling

You don't want to read the whole field 60 times a second. AXObserver lets you subscribe to notifications from another process:

var observer: AXObserver?
AXObserverCreate(pid, { _, element, notification, _ in
    // debounce, then re-read value + selection and request a suggestion
}, &observer)

let app = AXUIElementCreateApplication(pid)
AXObserverAddNotification(observer!, app, kAXFocusedUIElementChangedNotification as CFString, nil)
AXObserverAddNotification(observer!, app, kAXValueChangedNotification as CFString, nil)
AXObserverAddNotification(observer!, app, kAXSelectedTextChangedNotification as CFString, nil)

CFRunLoopAddSource(CFRunLoopGetCurrent(),
                   AXObserverGetRunLoopSource(observer!), .defaultMode)

You need one observer per app process, so watch NSWorkspace for app activation and move your observer as the user switches apps. Value-changed tells you the user typed. Selected-text-changed tells you the caret moved, which is often your cue to throw away a stale suggestion.

Step 4: put the text back

Once the user accepts a suggestion, there are two common ways to insert it:

1. Set the selected text. Writing to kAXSelectedTextAttribute with AXUIElementSetAttributeValue replaces the current selection, or inserts at the caret if nothing is selected. It's clean when it works, and it leaves the clipboard alone. Not every app supports writing it, so check the result code.
2. Paste it. Put the text on the pasteboard and post a synthesized ⌘V with CGEvent. It works in more places, but you have to save and restore the user's clipboard, and some apps handle pasted text differently from typed text.

Many tools try the first and fall back to the second.

Why it doesn't work everywhere

This is the part users actually notice.

Apps expose different amounts. Native AppKit text views implement everything above. Custom-drawn editors (some code editors, canvas-based web apps, games) may expose little or nothing. Your tool can only see what the app reports.

Electron and Chromium build their tree on demand. Per Electron's accessibility docs, Electron apps turn on accessibility support automatically when assistive technology like VoiceOver is running. A third-party tool can request it by setting the AXManualAccessibility attribute to true on the app's element. Until then, the text you're looking for may not be in the tree at all.

Secure fields are off-limits, and should be. Password fields have the subrole kAXSecureTextFieldSubrole, which Apple describes as a field for sensitive data that shows input as bullets. Skip them. Separately, when an app turns on Secure Event Input, which NSSecureTextField does automatically and Terminal and iTerm let you keep on, Apple's TN2150 explains that keyboard event taps stop receiving keystrokes. You can check this with IsSecureEventInputEnabled() and show the user why suggestions paused.

The Mac App Store is mostly out. Apple's App Sandbox documentation lists "use of accessibility APIs in assistive apps" among the things the sandbox forbids, and Mac App Store apps must be sandboxed. That's why most system-wide writing tools are downloads signed with Developer ID, not App Store apps. (Event taps that need only Input Monitoring are a narrower exception.)

Debugging tips

• Accessibility Inspector (Xcode → Open Developer Tool) shows exactly which attributes an app exposes. Check it before you blame your code.
• During development, macOS ties the permission to your code signature, so a rebuilt binary with a different signature can quietly lose trust. tccutil reset Accessibility <bundle-id> gives you a clean slate.
• Every AX call is a cross-process message to the target app. Keep them off the main thread, and set a timeout with AXUIElementSetMessagingTimeout so a frozen app can't freeze yours.

Where the model fits

All of the above is plumbing. The model only sees a string of context and returns a string. That separation is what makes on-device suggestions practical. The Accessibility layer collects the text locally, and if inference also runs locally, the text never has to leave the Mac.

That's the design I went with for DraftKey. It uses Accessibility to work in compatible text fields, skips secure fields, has per-app controls, and runs its writing model on the Mac. It's $4.99 lifetime for up to 3 Macs (macOS 14+, Apple Silicon). It hits the same limits described above, so it can't work in editors that don't expose their text.

If you're building something in this space, start with Accessibility Inspector and a single AXObserver. You'll learn most of what you need from watching which notifications actually fire.

Originally published on DEV.

You can answer those questions with a little setup. This guide covers where the usage data lives on your Mac, how to group it by project, and a few habits that make the numbers useful instead of just interesting.

Why per-project numbers matter

A single monthly total hides the decisions you can actually change:

• Which repos need a smaller context. A project with a bloated CLAUDE.md or AGENTS.md, huge generated files, or no ignore rules can cost several times more per task than a tidy one.
• What to bill clients. If you freelance, AI time on a client project is a real cost. Per-repo numbers let you price it in honestly.
• Which side projects are worth it. It's easy to keep a hobby project going in the background without noticing it's taking a third of your plan.
• Where a spike came from. When you hit a limit early, you want to know which session did it, not guess.

Where the data lives

Both tools keep local session logs, which is what makes per-project tracking possible without any API dashboard.

Claude Code writes a JSONL transcript for every session under ~/.claude/projects/. Each project gets its own folder, named after the path of the directory you started the session in. Assistant messages in those files include a usage block with input tokens, output tokens, and cache read and cache creation tokens.

Codex CLI stores session logs under ~/.codex/sessions/, organized by date. Each session records the working directory it ran in, along with token counts as the session progresses.

Two things follow from this. First, the folder you launch the tool from is the project, as far as the logs are concerned, so launch from the repo root consistently. Second, the data is already on your disk. You just need to add it up.

Option 1: use an existing CLI

The quickest route for Claude Code is ccusage, an open-source CLI that reads the local JSONL files and reports usage by day, month, or session, with estimated cost. Run it with npx ccusage@latest and look at the session report. Sessions are tied to project folders, so you can see which repos dominate.

Check the project's README for current flags, since it changes often. If you only use Claude Code, this may be all you need.

Option 2: a small script of your own

If you want Claude Code and Codex in one table, or you want to group by client rather than by folder, a short script works fine. The idea:

1. Walk ~/.claude/projects/ and, for each project folder, sum input_tokens, output_tokens, cache_read_input_tokens, and cache_creation_input_tokens from assistant messages in every .jsonl file.
2. Walk ~/.codex/sessions/, read the working directory and final token totals for each session, and group by directory.
3. Map directories to the names you care about, for example everything under ~/code/acme-* becomes "Acme (client)".
4. Multiply by the current per-token prices for the models you use if you want dollars, or keep raw tokens if you're on a subscription and care about limits.

Here's a minimal Python sketch for the Claude Code half:

import json, pathlib, collections

root = pathlib.Path.home() / ".claude" / "projects"
totals = collections.defaultdict(lambda: collections.Counter())

for project in root.iterdir():
    for f in project.glob("*.jsonl"):
        for line in f.open():
            try:
                msg = json.loads(line).get("message", {})
            except json.JSONDecodeError:
                continue
            usage = msg.get("usage") if isinstance(msg, dict) else None
            if usage:
                for k, v in usage.items():
                    if isinstance(v, int):
                        totals[project.name][k] += v

for name, c in sorted(totals.items(), key=lambda kv: -sum(kv[1].values())):
    print(f"{name}: in={c['input_tokens']:,} out={c['output_tokens']:,} "
          f"cache_read={c['cache_read_input_tokens']:,}")

Field names can change between versions, so print one raw line first and adjust if needed. Treat the result as an estimate, not an invoice: the provider's billing page is the source of truth.

Making the numbers useful

Collecting data is the easy part. These habits turn it into decisions.

Always launch from the repo root. Starting a session from ~/ or a random subfolder splits one project across several buckets, or lumps unrelated work together.

Look at cache reads separately. In long sessions, cache reads are usually the biggest token count. They're much cheaper than fresh input, but on a subscription they still count against your limits. A project with huge cache-read numbers is a project where sessions run too long. Clearing more often and restating the task in a few lines usually helps.

Compare cost per task, not just totals. A busy project should cost more. What you want to spot is a project where ordinary tasks cost far more than elsewhere, which usually points to oversized context: a long memory file, giant fixtures, or generated code the agent keeps reading.

Check weekly. Monthly reviews are too late to change anything. A five-minute weekly look tells you if a project is drifting.

Write down what you change. If you trim a project's memory file or add ignore rules, note the date. Next week's numbers tell you whether it worked.

Seeing it while you work

Scripts and reports are good for looking back. During the day, it helps to have current usage visible without running anything, so you notice a runaway session while it's happening rather than at the end of the week.

That's the reason I built TokenBar, a Mac menu bar app that shows your Claude, Codex, and other AI usage and cost at a glance, including how close you are to your limits. It's built on the MIT-licensed open-source CodexBar project and costs $15 once, with no subscription. It doesn't replace a per-project breakdown, but it pairs well with one: the menu bar tells you something is spiking, and the logs tell you which repo did it.

Quick checklist

• Launch Claude Code and Codex from each repo's root, every time
• Use ccusage or a short script to sum tokens per project folder
• Group folders into clients or products if that's how you think about cost
• Watch cache reads in long sessions, and clear more often where they balloon
• Compare cost per task across projects to find oversized context
• Review weekly and note what you changed

Disclosure: I built TokenBar.

All facts below come from each app's own website as of October 2026. If something has changed, the linked pages are the source of truth.

The short version

These four apps fall into two camps:

• Autocomplete while you type: Cotypist and DraftKey show suggested next words inline, and you press Tab to accept.
• Rewrite on demand: WunderType and RewriteBar act on text you select, triggered by a shortcut.

DraftKey sits in both camps, because it also has a rewrite panel. Cotypist doesn't rewrite selected paragraphs, and WunderType and RewriteBar don't autocomplete as you type.

Comparison table

Cotypist

cotypist.app

What it does well. Cotypist is the reference point for Mac autocomplete. Suggestions appear inline in almost any app, Tab takes the next word (or the whole line), and it learns your vocabulary and phrasing. It can also use what's on your screen as context, so suggestions match the email thread you're replying to. Processing is entirely on-device and works offline. It has strong reviews, including from John Gruber at Daring Fireball, who called its suggestions "eerily good."

Trade-offs. It's a subscription for unlimited use ($72/year for one Mac, $108/year for three). The free tier covers 100 accepted words a day. It recommends an M1 Pro or M2 with 16 GB of memory for the smoothest experience. It's built for autocomplete, so for rewriting a paragraph you'd pair it with something else.

Pick it if autocomplete quality and personalization matter most and you'd like a free tier and a long trial before committing.

DraftKey

getdraftkey.com

What it does. This is mine. DraftKey suggests the next words as you type in compatible Mac text fields, and you press Tab to accept. Tapping Command + Option opens a rewrite panel on the current paragraph (no need to select first) with Fix writing, Shorter, Clearer, Friendly, Professional, or a custom instruction. You review the result before it's inserted. The model runs on your Mac and works offline after setup. The license also includes clipboard history and keyboard sounds.

Trade-offs. No free trial and no automatic money-back guarantee, which makes it the hardest of the four to evaluate before paying. It needs Apple Silicon, macOS 14+, 8 GB of memory and a ~1.12 GB model download. It has no cloud-model option, so you can't swap in a frontier model for harder edits. It's also a much younger app than Cotypist, with nowhere near its track record or reviews.

Pick it if you want autocomplete and rewrites in one local app for a one-time $4.99.

WunderType

wundertype.com

What it does well. WunderType is deliberately minimal: a ~20 MB sandboxed menu bar app with no Dock icon, no account, no server and no telemetry. Select text, press ⌘⇧G, and it's corrected in place, with your clipboard restored. Since version 1.5 it runs models on your Mac's GPU through Apple MLX (Gemma 3 1B or 4B, Granite 2B, Phi-4 Mini), and you can also use Ollama, your own OpenAI key or OpenRouter, even per prompt. Custom prompts can each have their own shortcut.

Trade-offs. No inline autocomplete. It acts only when you invoke it.

Pick it if you want a cheap, private, one-key fixer with the flexibility to use a bigger cloud model when you need one.

RewriteBar

rewritebar.com

What it does well. RewriteBar is the maximalist option: a Spotlight-style palette of AI actions on your selection, with grammar fixes, tone changes, translation to 500+ languages (model-dependent), summaries, JSON and SQL formatting, side-by-side diffs, chained multi-step workflows and PopClip integration. It supports 500+ models across 38+ providers, including fully local ones.

Trade-offs. Privacy depends on configuration. The default RewriteBar provider routes text through its server (it says nothing is stored), so you'll need to set up a local provider for offline use. All those options also mean more setup than the others.

Pick it if you want the most actions and model choices and you're happy to configure them.

Which one should you pick?

You can also pair an autocomplete app with a rewrite app. Cotypist for autocomplete plus WunderType for rewrites, for example, covers both gestures. Just don't run two autocomplete apps that both use Tab at the same time.

Worth mentioning

Two related apps come up in the same searches:

• Charm ($19.99 once) focuses on on-device spelling and grammar correction, with next-word prediction.
• Elephas has moved toward private AI over your own documents and now offers a 7-day free trial, then paid plans.

Neither fits neatly into a head-to-head with these four, but both are worth a look depending on what you need.

If you've used any of these, I'd like to hear what you'd change in this table.

Disclosure: I built DraftKey.

Both tools have a middle ground. You can tell them which commands are always fine, which ones always need a check, and which files they should never touch. This guide walks through how to set that up in each tool, plus a starter config you can copy.

Flags and setting names do change between releases, so run claude --help and codex --help to confirm what your version supports.

The idea: allow the boring stuff, block the scary stuff

Most agent commands fall into three groups:

• Safe and frequent: reading files, running tests, linting, git status, git diff. Approving these by hand is pure friction.
• Worth a look: installing packages, git push, anything that hits the network or changes files outside the project.
• Never: reading .env or credential files, rm -rf outside the repo, deploying to production.

The goal is to auto-approve the first group, keep prompts for the second, and hard-block the third.

Claude Code: permission rules

Claude Code reads permission rules from settings files:

• ~/.claude/settings.json for your personal defaults across every project
• .claude/settings.json in the repo, which you can commit for your team
• .claude/settings.local.json for personal overrides in one repo (keep it out of git)

Rules go in allow, ask, and deny lists. Deny wins over everything else. A starter project file might look like this:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm install:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl:*)"
    ]
  }
}

A few things that help:

• Use prefix matches for commands. Bash(npm run test:*) covers npm run test with any arguments after it. Be careful with very broad prefixes like Bash(npm:*), since that also covers npm publish.
• Add rules from the prompt. When Claude asks to run something, choosing the "don't ask again" option writes an allow rule for you. After a week of normal work, open the file and prune anything too broad.
• Check what's active with /permissions. It lists every rule and which settings file it came from, which is the fastest way to debug "why did it ask me again?"

Permission modes

On top of rules, Claude Code has modes you can cycle with Shift+Tab during a session:

• Default: asks the first time it wants to use each tool.
• Accept edits: file edits go through without a prompt, but shell commands still follow your rules.
• Plan mode: read-only. Claude explores and writes a plan but doesn't change anything. This is a great first step for any big task.

There's also --dangerously-skip-permissions, which skips every prompt. Only use it inside a throwaway container or VM with no credentials in it, because the name is accurate.

Codex CLI: sandbox plus approval policy

Codex splits the problem into two separate settings.

Sandbox mode controls what commands can physically do:

• read-only: can read files, can't write or use the network.
• workspace-write: can write inside the project folder, and network access is off by default.
• danger-full-access: no sandbox at all.

On macOS, Codex enforces this with the system's built-in sandbox (Seatbelt), so it isn't just an honor system. A command that tries to write outside the workspace actually fails.

Approval policy controls when Codex stops to ask you:

• untrusted: asks before anything that isn't on its short list of known-safe read commands.
• on-request: runs inside the sandbox and asks only when it needs to go beyond it.
• never: never asks. Failures just come back to the model.

You can set both per session:

codex --sandbox workspace-write --ask-for-approval on-request

--full-auto is a shortcut for roughly that same pair. Or set defaults in ~/.codex/config.toml:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

Inside a session, the /approvals command lets you switch levels without restarting, which is handy when you move from exploring to letting it run a long refactor.

A setup that works for most projects

Here's what I'd start with in both tools:

1. Start big tasks read-only. Plan mode in Claude Code, read-only sandbox in Codex. Let the agent read the code and propose a plan before it touches anything.
2. Then allow edits inside the repo only. Accept-edits mode in Claude Code, workspace-write with on-request in Codex.
3. Auto-approve your test, lint, and read-only git commands. These are the bulk of what agents run.
4. Hard-deny secrets. Block .env files and credential folders explicitly, even if you think the agent wouldn't look.
5. Keep network and publish commands behind a prompt. git push, npm publish, curl, and deploy scripts should always need your OK.
6. Do anything fully unattended in a container. If you want zero prompts, give the agent a disposable environment rather than your real laptop.

Commit the shared project rules so everyone on the team gets the same guardrails, and keep personal preferences in your home directory or local settings file.

One side effect worth knowing

Once you stop approving every command, sessions run a lot longer on their own. That's the point, but it also means an agent can burn through a big chunk of your plan limits or API budget while you're getting coffee. It's worth keeping an eye on usage when you first loosen the rules, so you notice if a loop of failing tests is eating tokens.

Disclosure: I built TokenBar, a $15 lifetime Mac menu bar app that shows your Claude, Codex and other AI usage and cost at a glance. It's built on the MIT-licensed open source CodexBar. https://tokenbar.site

What allow and deny rules have you settled on? I'd love to see other people's configs in the comments.

Once a coding agent can work for twenty minutes without you, the obvious next step is to run two. One session fixes a bug while another builds a feature, and a third writes tests. It works right up until they share a directory.

Two agents in one checkout are like two people typing into the same document. Session A rewrites auth.ts while session B is halfway through reading it. One runs the formatter across the repo and the other's diff fills with noise. One switches branches, and the other's files change underneath it. Test runs pick up half-finished edits from the other session, so a failure tells you nothing. At best you get a confusing diff; at worst one agent quietly undoes the other's work.

The fix is to give each session its own working directory. Git has had a built-in way to do that since 2015: worktrees.

What a git worktree is

A worktree is an extra working directory attached to the same repository. Every worktree has its own files, its own checked-out branch, its own index and its own HEAD. They all share one .git object store, so commits, branches, stashes and remotes are common to all of them.

That's different from cloning the repo again. A second clone duplicates the history and has to fetch and push separately. A worktree only adds the checked-out files, and a commit made in one is visible from every other immediately.

For agents, this is exactly the right shape. Each session gets a private directory to edit, build and test in, and you can still review and merge everything from one place.

The four commands you need

Run these from your main checkout.

Create a worktree

# New branch "fix-login" in a sibling directory
git worktree add -b fix-login ../myapp-fix-login

# Existing branch
git worktree add ../myapp-review feature/search

# Throwaway checkout with a detached HEAD (no branch)
git worktree add -d ../myapp-scratch

With -b, the new branch starts from your current HEAD. To start from somewhere else, add the start point at the end:

git worktree add -b fix-login ../myapp-fix-login origin/main

List them

git worktree list

/Users/me/code/myapp            bec18a8 [main]
/Users/me/code/myapp-fix-login  bec18a8 [fix-login]

Remove one

git worktree remove ../myapp-fix-login

Git refuses if the worktree has modified or untracked files, which is a useful safety net. --force overrides it, so only use that once you're sure nothing in there matters. Removing a worktree doesn't delete its branch. If the branch is merged or abandoned, delete it separately:

git branch -d fix-login    # -D if it was never merged

Prune stale entries

If you delete a worktree folder with rm -rf or Finder instead of git worktree remove, git still has a record of it, and git worktree list marks it as prunable. Clear those records with:

git worktree prune

Naming and placement

Two conventions keep this manageable.

Where to put them. Either use sibling directories (../myapp-fix-login) or a dedicated folder such as ../myapp-worktrees/fix-login. If you'd rather keep them inside the repo, use a folder like .worktrees/ and add it to .gitignore, or every file in it shows up as untracked in your main checkout. Siblings are the least surprising for editors and build tools, since nothing ends up nested inside another project.

What to call them. Name the directory after the branch, and name the branch after the task: fix-login, feat-csv-export, agent/refactor-billing. When you have four terminals open, git worktree list should tell you at a glance which session is doing what.

Set up each worktree before starting an agent

A new worktree contains only tracked files. Anything gitignored is missing, and that's usually the stuff your project needs to run.

Dependencies. node_modules, .venv, target/ and friends aren't there. Install them in each worktree:

cd ../myapp-fix-login
npm ci            # or: pnpm install, uv sync, bundle install, cargo build

This costs disk space and time per worktree. Package managers with a shared cache (pnpm's global store, uv's cache) make repeat installs much cheaper.

Environment files. .env and .env.local are gitignored, so copy them over:

cp ../myapp/.env .env

Ports. Two dev servers can't both listen on port 3000. If a session will run the app, give each worktree its own port, usually through the same env file:

echo "PORT=3001" >> .env

Databases and services. If both sessions point at the same local database, one agent's migration or test fixtures can break the other's run. Give each worktree its own database name, or its own SQLite file. If you use Docker Compose, a different COMPOSE_PROJECT_NAME per worktree gives each one separate containers, networks and volumes.

If you repeat these steps often, put them in a small script that creates the worktree, copies env files and installs dependencies.

Running claude or codex in each worktree

The manual approach works with any agent. Open one terminal per worktree and start a session in each:

# Terminal 1
cd ~/code/myapp-fix-login && claude

# Terminal 2
cd ~/code/myapp-csv-export && codex

Each session treats its worktree as the project. Because your CLAUDE.md or AGENTS.md is a tracked file, it's present in every worktree automatically. Give each session one focused task with a clear finish line ("done when the login tests pass and lint is clean"), then let it run.

A terminal multiplexer such as tmux keeps several sessions in one window, and lets you detach and come back later. Codex and Claude Code both resume per directory: claude --continue resumes the most recent conversation in the current directory, and codex resume --last does the same for Codex. Running either from inside a worktree picks up that worktree's session.

Claude Code's built-in worktree support

Current Claude Code versions can create the worktree for you. Pass --worktree (or -w) with a name:

claude --worktree fix-login

According to Anthropic's docs, this creates a worktree at .claude/worktrees/fix-login/ inside your repo, on a new branch named worktree-fix-login, and starts the session there. Run the same command with another name in a second terminal for a second isolated session. Leave out the name and Claude generates one. A few details worth knowing:

• Add .claude/worktrees/ to .gitignore, as the docs recommend, so those directories don't show up as untracked files in your main checkout.
• The base is your default branch, not your current branch. By default, new worktrees branch from the repository's default branch on the remote (usually main). To branch from your local HEAD instead, set "worktree": { "baseRef": "head" } in settings. For a specific existing branch, create the worktree with git yourself.
• .worktreeinclude copies gitignored files. Put a file named .worktreeinclude at the project root, using .gitignore syntax, and Claude copies matching gitignored files such as .env into every worktree it creates.
• Cleanup happens on exit. When you leave the session, Claude checks the worktree. If it's clean and the session was unnamed, it removes the worktree and its branch. If there are changes or commits, it asks whether to keep or remove it. Non-interactive runs with -p don't clean up, so remove those with git worktree remove.
• The repo needs at least one commit, or worktree creation fails.

You can also ask Claude mid-session to "work in a worktree," and custom subagents can run in their own worktree by adding isolation: worktree to their frontmatter.

Codex CLI's worktree support

Recent Codex CLI releases have managed worktrees too, though OpenAI describes this as newer functionality, so check codex --help on your version. In an interactive session, type /worktree to start a new chat, or move the current one, into a managed git worktree. There's also a "Browse worktrees" option for finding existing ones. For scripted runs, --worktree works with new and forked runs:

codex exec --worktree "implement the next step"
codex fork <SESSION_ID> --worktree

The docs say --worktree requires local execution and can't be combined with resume, review or --ephemeral. If you'd rather keep full control over branch names and locations, plain git worktree add plus codex works on every version.

Reviewing and merging the results

Every worktree is a branch, so review works like reviewing a colleague's branch. From your main checkout:

git log --oneline main..fix-login     # what it committed
git diff main...fix-login             # the full change

Uncommitted work only exists inside its worktree, so ask the agent to commit when it's done, or check with git -C ../myapp-fix-login status.

Then merge whichever way your team does: push the branch and open a pull request, or merge locally:

git switch main
git merge fix-login

Merge one branch at a time and run the tests after each. Two agents that both worked "correctly" in isolation can still conflict, especially when both touched a shared module. When a later branch conflicts, it's often easiest to rebase that branch on the updated main inside its own worktree, and let its session fix the conflicts. It has the context on why it made its changes.

Cleaning up

When a branch is merged or abandoned:

git worktree remove ../myapp-fix-login
git branch -d fix-login
git worktree prune

Check git worktree list every so often. Forgotten worktrees pile up, each with its own node_modules, and keep their branches checked out.

Common pitfalls

The same branch can't be checked out twice. Git won't let two worktrees hold the same branch. If main is checked out in your main directory, git worktree add ../x main fails with 'main' is already used by worktree at .... Create a new branch with -b, use -d for a detached checkout, or remove the worktree that's holding the branch.

Shared lockfiles conflict. If two sessions both add dependencies, both branches change package-lock.json, pnpm-lock.yaml, uv.lock or Cargo.lock, and the merge conflicts. Don't hand-merge lockfiles. Take one side, re-run the install so the package manager regenerates the file, and commit the result. Better yet, keep dependency changes to one session at a time.

Generated files and migrations collide. Two branches that each add a database migration with the next sequence number, or that each regenerate an API client, will clash at merge time even if the code is fine. Assign those tasks to one session.

Submodules need extra care. A new worktree doesn't initialize submodules, so run git submodule update --init --recursive inside it. Git's own docs say submodule support in multiple worktrees is incomplete, and git worktree remove needs --force for a worktree with submodules. If your repo leans heavily on submodules, test the workflow before you rely on it.

Your IDE gets confused. Opening a worktree nested inside the main project can make an editor index everything twice, run duplicate language servers, or show the same file in search results twice. Open each worktree as its own window (code ../myapp-fix-login), and exclude your worktree folder from the main project's indexing if you keep worktrees inside the repo.

Agents wander. An agent running in a worktree can still cd back into your main checkout if nothing stops it. Claude Code blocks edits and git commands that target the main checkout while a session is isolated with --worktree. With manual worktrees, tell the agent which directory it owns, and keep sandbox or permission settings scoped to it.

Parallel sessions burn limits faster

One last thing that's easy to miss: parallel sessions don't come with parallel quotas. Every Claude Code session on your account draws from the same usage limit, and every Codex session draws from the same ChatGPT plan limit. Four agents running for an hour can use up roughly what one agent would use in four hours, and you hit the limit in the middle of the afternoon, with all four sessions stopping at once.

So run as many sessions as you can actually review, not as many as your machine can handle. Give the cheap, mechanical tasks (renames, test scaffolding, lint fixes) to parallel sessions, and save your heavy reasoning work for one focused session. If you're on API billing instead of a subscription, the same logic applies to your bill.

A short checklist

• The repo has at least one commit and a clean main checkout.
• Each task gets its own branch and worktree, named after the task.
• Worktrees live in sibling directories or a gitignored folder.
• Dependencies are installed and .env files copied in each worktree (or listed in .worktreeinclude for Claude Code).
• Each worktree has its own port, database and Compose project name if it runs services.
• Each session has one focused task with a clear "done when."
• Dependency, lockfile and migration changes are limited to one session.
• Agents commit their work before you review it.
• Branches are merged one at a time, with tests after each.
• Finished worktrees are removed, their branches deleted, and stale entries pruned.
• You're watching how fast parallel sessions draw down your shared limit.

Worktrees don't make agents smarter. They just stop agents from tripping over each other, which is most of what running several at once requires.

TokenBar is a $15 Mac menu bar app that shows your Claude and Codex usage and cost, which helps when several sessions are draining the same limit. It's at https://tokenbar.site if that's useful.

Disclosure: I built TokenBar.

I write a lot of email. It's mostly short stuff: asking for something, answering a question, following up on a thread that went quiet. For a long time I treated Apple Mail as a plain inbox and did everything by hand. Then I spent an afternoon going through its menus and settings, and it turns out Mail already has most of what I was missing.

This is the setup I use now. It's built into Mail, so you don't need any plugins. A few notes before we start:

• Menu names change a little between macOS versions. On recent versions the settings window is Mail > Settings. On older ones it's Mail > Preferences.
• Send Later, Undo Send, Remind Me, and Follow Up arrived in macOS 13 Ventura. If you're on something older, skip those sections.
• Apple Intelligence features only show up on supported Macs, in supported languages and regions, with Apple Intelligence turned on.

1. Keep reusable emails in a Templates mailbox

Mail doesn't have a proper "templates" feature, so a lot of people either retype the same messages or try Stationery. I do something simpler: I keep good emails in their own mailbox and reuse them.

Here's how to set it up:

1. Choose Mailbox > New Mailbox, pick On My Mac (or your main account if you want it on all your devices), and call it Templates.
2. Write the email you keep sending: an intro request, an invoice reminder, a "thanks for the call, here are the next steps" note. Leave blanks in brackets like [NAME] and [DATE] so you can spot them easily.
3. Send it to yourself, then drag the message from your inbox or Sent folder into Templates.

When you need it, select the template and choose Message > Send Again. Mail opens a new compose window with the same subject, body, and attachments. Fill in the brackets, change the recipient, and send. In my experience Send Again works on messages you sent, which is why I send templates to myself first.

The same trick works on a one-off basis. If you sent a great status update last month, find it in Sent, choose Send Again, and edit it.

Two habits keep this mailbox useful:

• Name templates by their subject line. Start the subject with a tag like TEMPLATE - Invoice reminder, then delete the tag before you send.
• Prune them. If you haven't used a template in six months, delete it. Ten good templates beat forty stale ones.

For small things like a greeting, a meeting link, or a sign-off, use Text Replacements in System Settings > Keyboard. I covered those in an earlier article, so I won't repeat it here.

2. Set up multiple signatures and pick the right one per account

If you send from a work address and a personal address, you probably want different signatures. You may also want different signatures for different situations: a full one for first contact, a short one for replies.

1. Open Mail > Settings > Signatures.
2. Select an account in the left column, click +, and give the signature a name, like "Full" or "Short".
3. Type the signature in the right-hand pane. To use your own fonts and links, uncheck Always match my default message font.
4. Use the Choose Signature menu under the account list to set that account's default. You can also choose None, or have Mail rotate through them at random or in order.

While you're writing, the Signature pop-up in the compose window lets you switch signatures on the fly. I set "Short" as the default and switch to "Full" only for first contact.

Turn on Place signature above quoted text, too. Otherwise your signature ends up below the whole quoted thread, where nobody sees it.

3. Use Send Later so email arrives at the right time

I do a lot of writing at night, but I don't want to send a client email at 11:40 PM. Send Later fixes that.

In the compose window, click the small arrow next to the Send button. Mail offers a couple of preset times plus Send Later..., where you pick an exact date and time. Scheduled messages wait in a Send Later mailbox in the sidebar. To change or cancel one, open it there and click Edit.

Some things I use it for:

• Writing replies on Sunday and scheduling them for Monday at 9 AM.
• Emailing people in other time zones at the start of their workday.
• Sending a reminder the morning before a deadline instead of today.

One caution: I wouldn't assume a scheduled email goes out while your Mac is asleep or Mail is closed. For anything important, leave the Mac awake and check the Send Later mailbox afterward.

4. Give yourself an Undo Send window

Most of my worst email mistakes happen in the second after I hit Send: the missing attachment, the wrong "Hi Sarah," the reply-all that should have been a reply.

Go to Mail > Settings > Composing and find Undo send delay. You can choose a short delay (10, 20, or 30 seconds) or turn it off. I use 30 seconds. It's long enough to catch a mistake and short enough that I don't notice it.

After you send, click Undo Send at the bottom of the sidebar, or press Command-Z right away. The message comes back as an open draft. Mail just holds the email for those few seconds before sending, so this works with any email account, not only iCloud.

5. Let Mail remind you, and suggest follow-ups

Some emails you can't deal with right now. Instead of marking them unread and hoping, use Remind Me.

Control-click a message in the list (or use the Message menu) and choose Remind Me. Pick one of the preset times, or choose Remind Me Later... to set your own date. When the time comes, the message jumps back to the top of your inbox.

The flip side is Follow Up. If you sent an email and didn't hear back after a few days, Mail can move your sent message to the top of your inbox with a Follow Up button. Click it to start a reply to your own message and give the other person a polite nudge. If you find it noisy, you can turn these suggestions off in Mail's settings.

6. Learn the composing and replying shortcuts

You don't need to learn every shortcut. These are the ones I use dozens of times a day:

• Command-N: new message
• Command-R: reply
• Command-Shift-R: reply all
• Command-Shift-F: forward
• Command-Shift-D: send
• Command-Shift-A: attach files
• Command-Option-B: show the Bcc field
• Command-Option-F: jump to the search field
• Command-' (apostrophe): increase quote level; Command-Option-' to decrease it

My favorite trick isn't a shortcut, though. Select a sentence in the original email before you press Command-R, and Mail quotes just that part. When someone sends five paragraphs and asks one question, quoting only the question makes your reply much easier to follow. If it isn't working, check Mail > Settings > Composing for the option that includes only selected text when quoting.

Get in the habit of pausing before Command-Shift-R, too. Reply all is right far less often than people think.

7. Use a structure that makes replies easy

Settings and shortcuts make you faster, but structure decides whether people actually reply. I use the same structure for almost every email.

The subject line states the ask. Write "Can you approve the Q3 budget by Friday?" instead of "Budget." Someone scanning their inbox should know what you need before they open the email.

The first line is the ask. Don't open with two sentences of background and leave the request at the end. Start with "Could you review the attached contract and send any changes by Thursday?" Put the context after it.

Short paragraphs, one idea each. Two or three sentences is plenty. If you have several questions, number them so the reply can say "1. Yes, 2. No, 3. Next week."

Make the next step obvious. End with a clear action and, if there's one, a date. "If I don't hear back by Wednesday, I'll go with option B" saves a whole round of emails.

Cut the warm-up. "I hope this email finds you well" and "Just checking in" add length without adding anything. A friendly first name and a direct request are polite enough.

Here's a short example:

Subject: Can we move Thursday's call to 2 PM?

Hi Priya, could we move Thursday's call from 11 AM to 2 PM? Something came up in the morning. If 2 PM doesn't work, Friday any time after 10 is open for me. Thanks, Sam

It takes about 30 seconds to read, the ask is in the subject, and Priya can answer in one line.

8. Let Apple Intelligence help (if your Mac supports it)

On Macs that support Apple Intelligence, Mail gets a few writing features worth trying.

Writing Tools. Select some text in a draft, then Control-click and choose Writing Tools, or use the Writing Tools button in the compose window. You can proofread, rewrite, change the tone (friendly, professional, or concise), or turn notes into a list. Concise is the one I use most, because my first drafts are always too long.

Smart Reply. When you reply to some messages, Mail can suggest quick replies based on what the sender asked. It's handy for simple yes/no or scheduling emails. Still read the draft before sending, because it doesn't know the context the way you do.

Summaries. Mail can summarize long messages and threads, which helps when you're catching up on a thread you were added to halfway through.

If you don't see these, your Mac, macOS version, language, or region may not support them yet. Everything else in this article works without them.

A quick checklist

• Create a Templates mailbox and save your three most common emails in it
• Reuse them with Message > Send Again
• Set up a short and a full signature for each account
• Turn on Place signature above quoted text
• Set Undo send delay to 30 seconds
• Schedule late-night replies with Send Later
• Use Remind Me instead of marking messages unread
• Learn Command-R, Command-Shift-R, Command-Shift-F, and Command-Shift-D
• Select the relevant text before replying so you quote only that part
• Put the ask in the subject and in the first line

Do the first five once and you'll feel the difference by the end of the week.

DraftKey is a $5 Mac app that does private, on-device AI autocomplete and rewriting in any app, including Mail (macOS 14+ on Apple Silicon). It's at https://getdraftkey.com if that's useful.

Disclosure: I built DraftKey.

Most Slack messages fail in the same way. They're written in the order the writer thought of things, so the reader has to scroll through the backstory to find out what's being asked. Then they reply with a question, you answer it, and a two-minute decision takes an afternoon.

You don't need to become a better writer in general to fix this. A handful of habits covers almost all of it. Here's the routine I use, plus the Mac and Slack features that make it quick.

1. Put the ask in the first line

Start with what you need from the reader, not with how you got here.

Instead of:

Hey! So I was looking at the onboarding flow yesterday and noticed the signup numbers dipped after Tuesday's release. I dug in a bit and I think it's the new email step. Anyway, could you take a look?

Write:

Can you check whether Tuesday's new email step is hurting signups? They dropped about 15% since the release. Details below.

The reader knows in one line what you want and whether it's urgent. The backstory can follow for anyone who needs it.

2. Skip the lone "hi"

A message that just says "hi" or "got a sec?" makes the other person wait for the real message, and it often lands while they're focused on something else. Send the greeting and the question together:

Hi Sam, quick one: is the pricing page copy final, or can I still edit it today?

Now they can answer whenever they look, in one reply.

3. Make it easy to answer from a phone

A lot of Slack replies happen on a phone between meetings. Help that person out:

• Ask yes/no or either/or questions when you can. "Ship Friday or wait for Monday?" gets an answer; "Thoughts on timing?" gets a meeting.
• Number your questions if there's more than one, so people can reply "1 yes, 2 Monday."
• Say what happens if they don't answer. "If I don't hear back by 3, I'll go with option A" keeps things moving without being pushy.

4. Use formatting, but only a little

Slack supports bold, bullet lists, and code blocks. A short list beats a dense paragraph when you're giving steps or options. But a message with three headings and five bold phrases looks like a document, and people skim documents.

A good rule: if a message needs more than about eight lines, it probably belongs in a doc or a thread, with a one-line summary in the channel.

5. Use threads on purpose

Reply in a thread when you're responding to a specific message, so the channel stays readable. Check Also send to #channel only when the outcome matters to everyone, like a final decision. Don't start a new top-level message to continue an old conversation; people lose the context.

6. Edit before you send

Most of the value is in a ten-second reread. Before pressing Return, check three things:

1. Is the ask in the first line?
2. Can I delete a sentence? Usually the first one ("Hope your week's going well") or the last one ("Let me know if you have any questions").
3. Would this make sense to someone who wasn't in my head? Replace "it" and "that thing" with the actual name.

Slack also lets you edit after sending, but people often read the first version from a notification, so it's better to fix it before.

7. Mac and Slack shortcuts that save time

These are worth learning if you send dozens of messages a day:

• Shift-Return adds a new line without sending. Essential for writing lists.
• Up Arrow in an empty message box edits your last message.
• Command-K jumps to any channel or DM.
• Command-Shift-A opens all unreads; Command-Shift-T opens threads.
• Command-Shift-7 and Command-Shift-8 start numbered and bulleted lists.
• /remind sets a reminder, such as /remind me to follow up with Sam tomorrow at 10am.
• Schedule send: click the arrow next to the send button to send a message tomorrow morning instead of at 11 PM.

On the Mac side, System Settings > Keyboard > Text Replacements works inside Slack too. Set up short triggers for things you type constantly, like your calendar link, standard handoff note, or "Thanks, that's all I needed."

8. Keep a few templates for repeated messages

If you write the same kind of message every week, like a status update, a bug report, or a handoff, save a template in a Slack saved item, a note, or a text replacement. A simple status update template:

Done: … Next: … Blocked on: … (or "nothing")

It takes the thinking out of the format so you can focus on the content.

9. Match the channel's tone

A short, direct message reads as friendly in a busy engineering channel and can read as curt in a DM to someone you've never worked with. Before writing in a new place, scroll up a bit and match how people there write. Adding one line of warmth ("Thanks for jumping on this") costs nothing and changes how the rest lands.

A quick checklist

• Ask in the first line
• No standalone "hi"
• Yes/no or numbered questions
• Say what happens if nobody answers
• Light formatting, eight lines max
• Threads for replies
• Reread once and cut a sentence
• Learn Shift-Return, Up Arrow, Command-K, and schedule send
• Text Replacements and templates for repeated messages

Try just the first three for a week. You'll notice fewer follow-up questions almost right away.

DraftKey is a $5 Mac app that does private, on-device AI autocomplete and rewriting in any app, including Slack (macOS 14+ on Apple Silicon). It's at https://getdraftkey.com if that's useful.

Disclosure: I built DraftKey.

Coding agents are fast enough now that the slow part of the job has moved. Writing the code takes Claude Code or Codex CLI a few minutes. Making sure the code is right is still on you, and it's tempting to skip. The agent says "All tests pass, the feature is implemented," the terminal looks tidy, and you type git commit -am "add feature".

Then, three days later, you find out the tests pass because the agent deleted the one that failed.

This is the review routine I use before committing anything an agent wrote. It doesn't need special tools: it's git, your test runner, and a few habits. It takes five to fifteen minutes for a typical change, and that's a lot less time than debugging a bad commit later.

1. Start from a clean baseline

Reviewing is much easier when the only uncommitted changes in your tree belong to the agent. Before you start a session, commit or stash your own work:

git status
git stash push -m "my work before agent session"

Now whatever shows up in git status afterward came from the agent. If you mix your half-finished edits with the agent's, you can't tell which lines you're supposed to be reviewing.

2. Ask the agent for a summary, then don't trust it

When the agent finishes, ask it to explain what it did. Something like:

List every file you changed, created, or deleted. For each one, say in one
sentence what changed and why. Then list anything you were unsure about,
any tests you modified or skipped, and any new dependencies you added.

This summary is useful as a map, not as evidence. Agents sometimes describe what they intended rather than what they did, and they tend to leave out the edits they made along the way, like "I also tidied up this other function." Treat the summary as a list of claims you're about to check against the diff.

3. Read the shape of the change first

Before reading any code, look at how big the change is and where it landed:

git status
git diff --stat
git diff --name-status

--stat shows lines added and removed per file. --name-status shows whether each file was modified (M), added (A), deleted (D), or renamed (R). This is where you catch the big surprises cheaply:

• A file you never mentioned has 200 changed lines.
• A test file shows up as D.
• package.json, requirements.txt, Cargo.toml, or a lockfile changed when you didn't ask for a dependency.
• A config file, CI workflow, or .env.example changed.

One trap: git diff doesn't show new files that haven't been staged. Agents create files all the time, so list them explicitly:

git ls-files --others --exclude-standard

If you want new files to show up in the diff alongside everything else, mark them with intent-to-add. It records that the file exists without staging its contents:

git add -N path/to/new_file.py
git diff

4. Read the diff file by file

Don't scroll through one giant diff. Go a file at a time, starting with the files that matter most (core logic, then tests, then everything else):

git diff -- src/payments/refund.ts

If the agent reformatted things and the noise is drowning out the real change, ignore whitespace while you read:

git diff -w -- src/payments/refund.ts

And run git diff --check once to flag trailing whitespace and leftover conflict markers.

For each file, ask three questions: Does this change belong to the task? Do I understand every line of it? What happens when this code gets bad input?

5. Look for the usual agent mistakes

Agents make a fairly predictable set of mistakes. They're worth checking for by name, because they don't jump out at you when you're just skimming.

Deleted or weakened tests. This one matters most. If a test was failing, the fastest way to "fix" it is to delete it, mark it skipped, loosen the assertion, or change the expected value to whatever the code now returns. Look for removed test cases, new skip or xfail markers, .only left in JavaScript tests, and assertions that got vaguer (toEqual(42) becoming toBeDefined()).

Swallowed errors. An empty catch block, except Exception: pass, a try that logs and carries on, or a ?? [] that quietly turns a failure into an empty result. These make the error go away without fixing anything.

Invented APIs. A method that sounds right but doesn't exist in your version of the library, or a config option it guessed at. Type checkers and tests catch some of these. For the rest, check the call against the library's docs or source.

Unrelated edits. Renamed variables, reordered imports, "improved" functions nobody asked about, or comments deleted. Each one might be harmless, but together they bloat the diff and hide the real change. Revert them unless you actually want them.

Hardcoded values. Magic numbers, a hardcoded user ID or URL from the example you gave it, a fixed date, a file path that only exists on your machine, or (worst) a real API key pasted in for testing.

New dependencies. A whole package added to do something your standard library already does. Check that it's real, maintained, and actually needed before you accept it, and look at how much the lockfile changed.

Leftover debris. console.log and print statements, TODOs, commented-out blocks, scratch scripts, and backup files in the repo root.

A quick search helps with a few of these:

git diff | grep -nE "^\+.*(console\.log|print\(|TODO|FIXME|\.only\(|skip)"

It's crude and will produce false positives, but it only takes a second.

6. Run the checks yourself

The agent saying "tests pass" isn't the same as the tests passing. Maybe it ran a subset, maybe it ran them before its last edit, or maybe the run failed and it misread the output. Run them yourself in your own terminal:

npm test          # or pytest, cargo test, go test ./...
npm run lint      # or ruff check ., cargo clippy, etc.
npm run typecheck # if your project has one

Use whatever commands your project actually has. If there's a test that covers the feature, make sure it would fail without the change. A quick way to check is to stash the source change, keep the test, and run it again. A test that passes either way isn't testing anything.

If the change is something you can see, like a UI, a CLI, or an endpoint, try it by hand too. Spend two minutes on the happy path and one obvious edge case.

7. Stage hunk by hunk with git add -p

This is the habit that makes the biggest difference. Instead of git add ., stage interactively:

git add -p

Git shows you each hunk and asks what to do with it. The keys you'll use most are y (stage this hunk), n (skip it), s (split it into smaller hunks), q (quit), and ? (help). Keep the hunks you've reviewed and agree with, and skip the rest.

It forces you to look at every change one more time, and it lets you commit the good 80% of a session while leaving the questionable 20% unstaged. Before you commit, check exactly what's going in:

git diff --staged

If you staged something by mistake, unstage it without losing the edit:

git restore --staged path/to/file

8. Run a second-pass review with a fresh context

The agent that wrote the code is a poor judge of it, because it's still anchored to its own reasoning. A new session, or a different tool, does better. Start a fresh Claude Code or Codex session, or paste the diff into one, and give it a narrow, adversarial brief:

Review the staged diff (git diff --staged) as a strict senior reviewer.
Do not rewrite anything. Report only:
1. Bugs or edge cases that would break in production
2. Tests that were removed, skipped, or weakened
3. Errors that are caught and ignored
4. Calls to functions or options that may not exist
5. Changes unrelated to the stated goal: <describe the goal>
For each issue, give the file, the line, and why it matters.

Telling it not to rewrite anything keeps it from opening a new round of edits. Treat what it reports as leads to check, not verdicts. A second model can invent problems as easily as the first one invented APIs.

9. Keep diffs small enough to review

Most review pain comes from how the agent was asked, not from the review itself. A prompt like "build the settings page" produces a 900-line diff that nobody reads properly. Smaller asks give you diffs you can actually review:

• Give the agent one task per session, and say what's out of scope ("don't touch the API layer").
• Ask it to stop after each step so you can review and commit before it continues.
• Commit working checkpoints often. Small commits are cheap, and each one becomes a safe point to go back to.
• If a diff is too big to review honestly, split it with git add -p across a few commits, or throw it out and ask again in smaller pieces.

10. Know when to throw it away

Sometimes the right review outcome is "no." If the approach is wrong, re-prompting on top of a messy diff usually makes things worse. Reset and try again with a better prompt.

To discard the changes in one file:

git restore path/to/file

To discard all uncommitted changes to tracked files:

git restore .

That deletes the work for good, so if you might want any of it back, stash it instead:

git stash push -u -m "agent attempt 1: wrong approach"
git stash list

The -u flag includes untracked files, which matters because agents create so many of them. Later you can look at it with git stash show -p stash@{0} or bring it back with git stash pop.

For any untracked files left over, preview before you delete:

git clean -n   # shows what would be removed
git clean -f   # actually removes them

The checklist

Before you commit agent-written code:

• Started from a clean tree, so every change is the agent's
• Asked for a summary and checked it against the diff
• Read git diff --stat, --name-status, and the list of untracked files
• Read every file's diff, most important first
• Checked for deleted tests, swallowed errors, invented APIs, unrelated edits, hardcoded values, new dependencies, and debris
• Ran tests, linters, and type checks yourself
• Staged with git add -p and reread git diff --staged
• Got a second-pass review from a fresh session on anything non-trivial
• Reverted or stashed whatever you didn't trust

None of this is new. It's how you'd review a pull request from a fast, confident colleague who sometimes makes things up. The agent writes code much faster than any colleague, which is exactly why the review step can't be skipped.

Disclosure: I built TokenBar, a $15 Mac menu bar app that shows your Claude and Codex usage and cost, which is handy when second-pass reviews start eating into your limits. It's at https://tokenbar.site.

Disclosure: I built TokenBar.

Proofreading your own writing is hard for a simple reason: you know what you meant to say. Your brain fills in the missing word, skips the doubled "the," and reads "form" as "from" because it already knows the sentence. Spell checkers catch some of this, but they don't catch a real word in the wrong place, and they never tell you a sentence is clumsy.

The fix is to break the familiarity. Make the text sound different, look different, or arrive in a different order, and the mistakes start to stand out. Your Mac already has tools for all three. Here's how I use them.

A note on names: on macOS Tahoe 26 and later, the speech settings live under Read & Speak. On macOS Sequoia 15 and earlier, the same settings are called Spoken Content. The steps are otherwise the same.

1. Have your Mac read your draft out loud

This is the most useful proofreading trick I know. A synthetic voice can't skim. It reads exactly what's on the page, not what you meant, so missing words, repeated words, and sentences that run out of breath become obvious.

Turn on Speak Selection

1. Choose Apple menu > System Settings, then click Accessibility in the sidebar.
2. Click Read & Speak (or Spoken Content on older versions).
3. Turn on Speak selection.

Now select some text in any app and press Option-Esc. Your Mac reads it aloud. Press Option-Esc again to stop. If nothing is selected, it reads the available text in the current window.

Set it up for proofreading

Click the info button next to Speak selection to see its options. A few are worth changing:

• Highlight content: choose words, sentences, or both. With word highlighting on, you can follow along and see exactly where the voice stumbles. This is where you catch "it's" versus "its" and other errors that sound fine but look wrong.
• Sentence style: pick an underline or a background color for the current sentence. I find a background color easier to track.
• Show controller: the controller is a small onscreen panel that lets you pause, change the speaking rate, and skip forward or back one sentence. For anything longer than a paragraph, set this to show automatically so you can jump back and replay a sentence you want to rework.
• Keyboard shortcut: if Option-Esc clashes with something you use, set your own here.

Choose a voice and a speed

Back on the main settings page, use the System voice pop-up menu to pick a voice. Click the info button next to it to adjust how fast and how loud it speaks, and to download more voices.

For proofreading, slower is better than you'd think. At a fast rate, your ears start skimming the same way your eyes do. Try something a bit below a normal speaking pace for a final pass, and faster for a quick first listen.

Start speaking from the Edit menu

In many apps, including TextEdit, Pages, Mail, and Notes, you can also choose Edit > Speech > Start Speaking, and Edit > Speech > Stop Speaking when you're done. It's handy if you'd rather not memorize a shortcut.

Try Accessibility Reader on newer macOS

On macOS Tahoe 26 and later, Read & Speak also has Accessibility Reader. Turn it on in the same settings pane, then press Command-Esc in any app. It shows the text in a full-screen view with your choice of font, layout, and background color, and it can read the text aloud with play, pause, skip, and speed controls. You can also open it from Edit > Speech > Open in Accessibility Reader.

2. Use the say command for long drafts

If you write in Markdown or plain text, Terminal has a built-in text-to-speech command called say.

The basics:

say "Testing one two three"
say -f draft.txt

-f reads a file. To pick a voice, use -v; to list every voice installed on your Mac, use -v '?':

say -v '?'
say -v Samantha -f draft.txt

To set the speed in words per minute, use -r:

say -r 160 -f draft.txt

My favorite option is -o, which saves the speech to an audio file instead of playing it:

say -r 170 -f draft.txt -o draft.aiff

Now you can listen to your draft on a walk, away from the screen, with a notes app open on your phone.

Two more tricks:

• pbpaste | say reads whatever is on your clipboard, so you can copy a paragraph from any app and hear it.
• If your draft is in a Word or rich text file, textutil -convert txt draft.docx creates a plain text copy (draft.txt) that say -f can read.

3. Run the spelling and grammar checker on purpose

Most people only notice underlines as they type. The checker is more useful as a deliberate, separate pass at the end.

In most native apps, open Edit > Spelling and Grammar:

• Choose Check Grammar With Spelling so grammar issues are flagged along with spelling. A checkmark shows it's on. Hold the pointer over a flagged word to see a description of the problem.
• Choose Check Document Now to highlight the first error, then press Command-Semicolon to move to the next one.
• For a long document, choose Show Spelling and Grammar to open a window that steps through each issue with suggestions.

A few habits make the checker more trustworthy:

• Choose between Ignore and Learn carefully. When you Control-click a flagged word, Ignore Spelling skips it in the current document only. Learn Spelling adds it to your dictionary, so it's never flagged again anywhere. Learn product names and your own name. Don't learn a typo just to make the underline go away. If you already did, Control-click it and choose Unlearn Spelling.
• Check a selection when you only changed one part. In apps like Pages, select a passage first and the Spelling and Grammar window checks just that text.
• Don't treat a clean check as a finished proofread. The checker won't flag "their" for "there," "trial" for "trail," or a sentence that says the opposite of what you meant. That's what the read-aloud pass is for.

Grammar checking isn't available in every language or region, so if you don't see grammar flags at all, that may be why.

4. Change how the text looks

Your eyes get used to a page's shape. Change it and you'll notice things you skimmed past ten times.

• Change the font or size. In TextEdit and many other apps, Command-T opens the Fonts window. Switch your draft to a different typeface and size for the final pass, then switch it back.
• Zoom in. In many apps, Command-Plus makes text bigger. Fewer words per line means fewer places for an error to hide.
• Change the line width. Resize the window so the lines break in different places. Repeated words like "the the" are easiest to miss when one ends a line and the other starts the next.
• Use Reader in Safari. If you've published something, or you're reviewing a draft on the web, open it in Safari and press Shift-Command-R (or choose Show Reader from the Smart Search field). Reader strips the page down to the article, and while you're in it you can click the button at the left end of the Smart Search field to change the background, font, and zoom. Press Esc to leave Reader.

5. Look up the words you aren't sure about

Some mistakes aren't typos. They're real words used slightly wrong: "comprise" versus "compose," "discreet" versus "discrete," "flout" versus "flaunt."

When a word gives you even a moment of doubt, select it (or put the pointer over it) and press Control-Command-D to show its definition. You can also Control-click the word and choose Look Up, or tap with three fingers or force click if you've set that gesture in Trackpad settings. Click Open in Dictionary in the popover if you want example sentences and the full entry.

6. A short human proofreading checklist

Tools get you most of the way. These habits cover the rest:

1. Take a break first. Even twenty minutes helps; a night is better.
2. Do one pass per problem. Don't try to fix flow, spelling, and facts at once. Do a listening pass for awkward sentences, a checker pass for spelling and grammar, and a separate pass for the items below.
3. Check names and numbers on their own. Names, dates, prices, version numbers, and links are where errors cost the most and spell checkers help the least. Compare each one against its source.
4. Read backwards for typos. Start at the last sentence and work toward the first. Without the flow of the argument, you see each sentence as a string of words, which is what a typo hunt needs.
5. Look at the edges. Headings, captions, the first line, the sign-off, and the subject line of an email get skipped because they're short. Read them one more time.
6. Recheck what you just changed. A lot of errors are introduced while fixing other errors: half-deleted words, a verb that no longer matches its new subject. After every edit, reread the whole sentence, not just the word you touched.

If you have Apple Intelligence, Writing Tools has a Proofread option too, and it's worth running as one more pass. I'd still do the listening pass myself, because it's the one that tells you how the writing actually sounds.

A routine that fits in ten minutes

For an email or a short post, this is enough:

1. Run Check Document Now with Check Grammar With Spelling turned on.
2. Select everything and press Option-Esc. Listen with word highlighting on, and pause to fix anything that sounds off.
3. Check every name, number, and link against its source.
4. Read the first and last lines one more time.

For anything longer, add a break, a font change, and a backwards read.

Disclosure: I built DraftKey, a $5 Mac app that does private, on-device AI autocomplete and rewriting in any app (macOS 14+ on Apple Silicon). It's at https://getdraftkey.com if that's useful.

Disclosure: I built DraftKey.