DEV Community: Henry Godnick

Claude Pro vs Max vs API for Claude Code: which plan fits your actual usage

Henry Godnick — Tue, 20 Oct 2026 16:02:55 +0000

Disclosure: I build TokenBar, a Mac menu bar app that tracks AI usage and cost. It gets one mention near the end. The rest uses only Claude Code's own files and Anthropic's published prices.

"Should I upgrade to Max?" is usually answered by gut feel: you hit a limit twice in one week and start shopping. A better answer is already on your disk. Claude Code keeps a transcript of every session, and every model response in it records its token counts. Price those tokens at API rates and you get a real number to set beside each plan.

What you're choosing between

From Anthropic's pricing page and the Max plan help article, as of October 2026:

Option	Price	Usage
Pro	$20/mo, or $17/mo billed yearly ($200 up front)	At least 5x Free per 5-hour session
Max 5x	$100/mo, monthly only	5x Pro per session, plus $100/mo in API credits
Max 20x	$200/mo, monthly only	20x Pro per session, plus $200/mo in API credits
API (Console)	Pay per token	No plan limits, only rate limits

Some details matter more than the price:

Limits aren't in dollars. Every plan has a rolling 5-hour session window, and paid plans add a weekly limit. Anthropic says there's no fixed message count, because usage depends on context length, model and features.
It's one shared pool. Claude Code, claude.ai, desktop and mobile all draw from the same allowance.
When you hit a limit, you can wait, upgrade, or turn on usage credits and keep going at standard API rates.

The API prices you'll use

Per million tokens, from the API pricing docs:

Model	Input	5-min cache write	1-hour cache write	Cache read	Output
Opus 5.5	$4	$5	$8	$0.20	$20
Sonnet 5.5	$2	$2.50	$4	$0.10	$10
Haiku 5.5 (prompts up to 100k)	$0.10	$0.125	$0.20	$0.01	$0.50
Haiku 5.5 (prompts over 100k)	$0.50	$0.625	$1	$0.05	$2.50

Cache reads are where most Claude Code tokens land. A long session re-sends its whole history on every request, and caching is the reason that's affordable. One detail affects the comparison: per the Claude Code cost docs, the cache lifetime is an hour on a subscription but five minutes by default on an API key. So the same work can cost a bit more on the API, because you rebuild the cache more often after short breaks.

Where the numbers live

Claude Code writes transcripts as JSONL to ~/.claude/projects/<project-dir>/<session-id>.jsonl, and keeps them for 30 days by default (cleanupPeriodDays). Assistant lines carry a message.usage object:

"usage": {
  "input_tokens": 5,
  "cache_creation_input_tokens": 20780,
  "cache_read_input_tokens": 15718,
  "output_tokens": 1101
}

Two caveats before you trust a script:

Anthropic calls the format internal, so it can change in any release. For anything long-lived, the sessions docs point you to claude -p --output-format json, which returns usage and cost for a run, or to /export.
One response can span several lines. Claude Code may write one line per content block, each repeating the same message.id and usage. If you sum every line you'll overcount, so dedupe by message.id.

A small script to price your last 30 days

#!/usr/bin/env python3
# claude_cost.py: API-equivalent cost of local Claude Code sessions
import json, pathlib, collections

# $ per million tokens: input, 5m write, 1h write, cache read, output
PRICES = {
    "opus":   (4.00, 5.00, 8.00, 0.20, 20.00),
    "sonnet": (2.00, 2.50, 4.00, 0.10, 10.00),
    "haiku":  (0.10, 0.125, 0.20, 0.01, 0.50),   # prompts <= 100k
}
HAIKU_LONG = (0.50, 0.625, 1.00, 0.05, 2.50)     # prompts > 100k

msgs = {}
for f in pathlib.Path.home().glob(".claude/projects/**/*.jsonl"):
    for line in f.open(errors="ignore"):
        try:
            e = json.loads(line)
        except ValueError:
            continue
        m = e.get("message") or {}
        if e.get("type") != "assistant" or "usage" not in m:
            continue
        key = m.get("id") or e.get("uuid")
        prev = msgs.get(key)
        if not prev or m["usage"].get("output_tokens", 0) >= prev[2].get("output_tokens", 0):
            msgs[key] = (e.get("timestamp", "")[:10], m.get("model", ""), m["usage"])

days = collections.defaultdict(float)
for day, model, u in msgs.values():
    fam = next((k for k in PRICES if k in model), None)
    if not fam:
        continue  # unknown or synthetic model entries
    inp, cr = u.get("input_tokens", 0), u.get("cache_read_input_tokens", 0)
    cw = u.get("cache_creation_input_tokens", 0)
    split = u.get("cache_creation") or {}
    w1h = split.get("ephemeral_1h_input_tokens", 0)
    w5m = cw - w1h
    p = PRICES[fam]
    if fam == "haiku" and inp + cr + cw > 100_000:
        p = HAIKU_LONG
    days[day] += (inp*p[0] + w5m*p[1] + w1h*p[2] + cr*p[3]
                  + u.get("output_tokens", 0)*p[4]) / 1e6

for d in sorted(days):
    print(f"{d}  ${days[d]:8.2f}")
active = [v for v in days.values() if v > 0]
print(f"\nActive days: {len(active)}  Total: ${sum(active):.2f}  "
      f"Avg per active day: ${sum(active)/max(len(active),1):.2f}")

Run it with python3 claude_cost.py. It maps models by family name, so check the table against the pricing page whenever Anthropic changes prices. Older model versions are priced differently. Opus 4.8, for example, is $5 in and $25 out.

The ** glob also picks up subagent transcripts if your version writes them to subfolders. You want those included, because subagent requests count toward your usage too.

Reading the result

Treat the number as "what this would have cost on the API," not "how much of my plan I used." Anthropic doesn't publish a dollar equivalent for plan allowances, so no exact break-even point exists. These are the comparisons that do hold up:

Monthly API-equivalent below $20. Pay-as-you-go in the Console may cost you less than Pro. You lose claude.ai chat, and the cache expires sooner, but if you mostly use Claude Code a few days a month, it's worth a look.
Well above $20, but you rarely see a limit message. Pro is doing its job. Upgrading buys headroom you don't use.
You hit the 5-hour or weekly limit every week. Open /usage. On paid plans it shows your plan bars and a breakdown by skills, subagents, plugins and MCP servers, and it flags any behavior (long context, cache misses) that makes up 10% or more of your usage. Press d or w to switch between the last day and week. Fix what it flags first. If you still hit the wall, Max 5x is the next step.
You're comparing Max with the API. Max includes $100 or $200 a month in API credits on top of your plan usage, so count those if you'd use them.

For a reference point, Anthropic's cost docs say enterprise Claude Code deployments average about $13 per developer per active day and $150â€“250 per developer per month, with 90% of users under $30 per active day. Those are API-rate figures for heavy, full-time use. If your average per active day is close to that, you're a normal heavy user, not an outlier.

Use the right `/usage` number

The Session block at the top of /usage shows a dollar cost calculated locally at list price. Anthropic says it's meant for API users. On Pro or Max it doesn't affect your bill, and it resets on /clear. It's still useful as a per-task price tag. Run /clear, do one task, then check /usage, and you'll know what that kind of task costs.

Check again after a month

One month of data beats any blog post's rule of thumb, mine included. Run the script at the end of each month (transcripts expire after 30 days unless you change cleanupPeriodDays), and compare it with how often you hit a limit.

I wanted that number visible without running a script, so I built TokenBar, which shows Claude, Codex and other providers' usage and cost in the Mac menu bar. The script above gives you the same core number for free.

What does your average active day come out to? I'm curious how far apart people's numbers are.

How Mac apps add text suggestions to every app: the Accessibility API explained

Henry Godnick — Tue, 20 Oct 2026 15:10:32 +0000

Disclosure: I build DraftKey, an on-device writing assistant for Mac that's built on the APIs below. It comes up once at the end. This post is about the platform, not the product.

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:

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.
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 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.

How to make Claude Code's usage limits last longer: 9 practical habits

Henry Godnick — Mon, 19 Oct 2026 22:50:40 +0000

Disclosure: I build TokenBar, a Mac menu bar app that tracks AI usage. It comes up once near the end. Everything else here works without it, and most of it comes straight from Anthropic's own cost docs.

If you're on a Pro or Max plan, the limit you hit isn't a dollar amount. It's a session window that resets every five hours and a weekly limit, and they're shared with everything else you do in Claude, including chats on claude.ai. When you run out halfway through a refactor, it's usually not because you asked for too much. It's because each request carried far more context than it needed.

Here's the key fact: Claude Code sends your whole conversation with every request, and every tool call sends another request carrying those results. Prompt caching makes re-reading that history cheaper, but it isn't free. A one-line question in a session that's been open all day still draws usage for the entire conversation.

Almost every habit below comes back to that.

1. `/clear` between unrelated tasks

This is the biggest win and the one people skip. If you've finished fixing a bug and now want to write docs, the old bug context is dead weight on every later message.

/rename auth-bugfix   # so you can find it later
/clear                # start fresh, costs nothing
/resume               # come back to the old one if you need it

The docs say it plainly: stale context wastes tokens on every message that follows, and /clear costs nothing.

2. Compact on purpose, and tell it what to keep

/compact summarizes the conversation so far to free up space, but compacting is itself a large request, because it has to read everything it's summarizing. So don't compact out of habit. Do it when you want to keep going on the same task, and give it instructions:

/compact Keep the failing test names, the final schema, and the files we changed

You can also set default instructions in CLAUDE.md:

# Compact instructions

When you are using compact, please focus on test output and code changes

If you don't need continuity, /clear is cheaper than /compact.

3. Mind the cache after a break

Prompt caching is why long sessions are affordable at all. On a subscription, the cache lasts an hour (it drops to five minutes once you're drawing on usage credits). Your first message after a longer break misses the cache and reprocesses your full context.

In practice, if you're coming back to a huge session after lunch, it's often cheaper to /clear and restate the task in a few lines than to type "ok, continue" into a cold 200k-token conversation. /usage now shows a prompt cache line with your hit rate and whether the cache is warm, so you can check before you decide.

4. Match the model to the job

Anthropic's own advice: Sonnet handles most coding tasks well and costs less than Opus, so save Opus for complex architecture decisions and multi-step reasoning. Switch mid-session with /model, or set a default in /config.

Two details worth knowing:

Switching to Opus also applies to subagents that inherit your session's model. For simple subagent work, set model: haiku in the subagent config.
If you hit a model-specific limit ("You've hit your Opus limit"), switching to another model family keeps you working. If you hit your session or weekly limit, switching models won't help, because those are shared across models.

5. Turn thinking down for easy tasks

Extended thinking is on by default because it helps with planning and hard reasoning, but thinking tokens are billed as output tokens, and the default budget can be tens of thousands of tokens per request. Renaming a variable doesn't need that.

Lower it with /effort (or from /model) for routine work. Some models always use extended thinking, so effort level is the control that works everywhere.

6. Shrink what loads every session

Some context gets loaded before you've typed anything:

CLAUDE.md is loaded at session start. The docs suggest keeping it under about 200 lines. Move detailed workflow instructions (PR reviews, migrations, release steps) into skills, which only load when they're used.
MCP servers add overhead. Tool definitions are deferred by default, but server names and instructions still go in. Run /mcp and disable the servers you're not using. When there's a CLI for something (gh, aws, gcloud, sentry-cli), it's more context-efficient than an MCP server.

Run /context to see what's actually filling your window. It's often a surprise.

7. Be specific, and plan before you build

"Improve this codebase" makes Claude scan broadly. "Add input validation to the login function in auth.ts" lets it read a couple of files and get to work.

For bigger changes:

Press Shift+Tab to switch to plan mode first. Claude explores and proposes an approach, so you don't pay for an implementation going the wrong way.
Press Escape as soon as it heads off course, and use /rewind (or double-tap Escape) to go back to a checkpoint.
Give it a way to check itself: a test to pass, an expected output, a screenshot. Fewer "that's still broken" round trips means fewer tokens.

8. Keep noisy output out of the main conversation

A 10,000-line test log in your context gets re-sent with every later message. Two ways to avoid that:

Hooks. A PreToolUse hook can rewrite test commands to return only the failures, cutting tens of thousands of tokens down to hundreds. The cost docs include a ready-made filter-test-output.sh example for npm test, pytest and go test.
Subagents. Hand verbose work (running tests, reading docs, digging through logs) to a subagent so only a summary comes back. Subagent requests still count toward your usage, so pair this with a smaller model.

9. Watch what runs when you're not typing

Some usage happens in the background:

Scheduled tasks and /loop fire on their interval even when the session is idle, sending your full context each time.
Agent teams use about 7x more tokens than a normal session when teammates run in plan mode, because each one has its own context. Keep teams small and shut teammates down when they're done.
Long-idle sessions can wake up for cross-session messages or goal check-ins, and each of those is a full-context turn.

Then, once a week, open /usage and look at the breakdown. On paid plans it shows how your recent usage splits across skills, subagents, plugins and MCP servers, lists your heaviest loops, and flags any behavior (like long context or cache misses) that's 10% or more of your usage, with a tip to fix it. Press d or w to switch between the last day and the last week. It only counts this machine, so claude.ai chats and other computers won't show up there.

The common thread: notice before you hit the wall

Every habit above is easier when you can see your usage climbing while you work, not after you get cut off. /usage is free and official. I got tired of checking it, so I built TokenBar, which keeps Claude, Codex and other providers' usage and cost in the Mac menu bar. A free tracker or a status line works too. What matters is having the number in view.

If I had to pick just three habits: /clear between tasks, Sonnet by default, and a short CLAUDE.md. Those three cover most of the waste I've seen.

What's the habit that saved you the most? I'm collecting tips for a follow-up.

Private AI writing assistants for Mac in 2026: what actually runs on-device

Henry Godnick — Mon, 19 Oct 2026 20:39:32 +0000

Disclosure: I build DraftKey, one of the tools below. I've tried to describe every option, mine included, as plainly as I can.

Lots of Mac writing tools now call themselves "private," and the word covers very different things. Some send every keystroke to a server under a privacy policy. Some run a model on your Mac but still call out for harder requests. Some never send your text anywhere.

If you write client emails, legal drafts, health notes or code comments you don't want stored on someone else's server, that difference matters. Here's how the main options compare in October 2026.

What "on-device" should mean

When I evaluate a tool, I ask four questions:

Where does inference run? On your Mac's GPU or Neural Engine, or on a server?
Is there a cloud fallback? Some tools quietly hand harder requests to a remote model.
What still needs the internet? Model downloads, license checks and updates are normal. Sending your text is a different thing.
Can you turn it off per app? You probably don't want any assistant reading your password manager or your terminal.

Almost every system-wide Mac writing tool works through macOS Accessibility, which lets it read the text field you're typing in. That's how they work across apps, and it's also why you should trust whoever made the one you install.

The cloud option: Grammarly

Grammarly is still the default for many people. The Mac app works across desktop apps and browsers, and its grammar and tone suggestions are mature.

It is cloud-based: text is sent to Grammarly's servers for analysis, and it needs an internet connection. You can turn it off per app, and it tries to skip sensitive fields such as passwords. There's a free plan, and Grammarly Pro is listed at $12/month billed annually or $30 month-to-month.

Good for: polished grammar and tone suggestions when cloud processing is acceptable.
Not for: anything you're not allowed to send to a third party.

The built-in option: Apple Intelligence Writing Tools

On Apple silicon Macs with Apple Intelligence turned on, Writing Tools can proofread, rewrite, change tone and summarize text in most apps, for free.

Apple's privacy page says basic requests run on-device, but more complex requests can go to Private Cloud Compute. That's Apple's server setup, which Apple says only processes the data needed for the request, doesn't store it, and can't be accessed by Apple. You can review those requests in System Settings â†’ Privacy & Security â†’ Apple Intelligence Report. macOS also has its own inline predictive text for short completions.

Good for: free, good-enough rewrites with a strong privacy design.
Caveat: "mostly on-device" isn't the same as "always on-device." It's a request-based tool, so you select text and pick an action. It's not continuous AI autocomplete.

Third-party apps that run on-device

All of these need an Apple Silicon Mac, and most need macOS 14 or later.

Cotypist is AI autocomplete that predicts your next words in any Mac app, running on your Mac. It offers the most personalization of any app here: learning your voice, per-app instructions, and screen- and clipboard-aware suggestions on higher tiers. There's a free tier (100 accepted completions a day) and a 30-day Pro trial. After that, Plus is $72/year for one Mac and Pro is $108/year for up to three.

Shadowtype is free and open source. It runs GGUF models through llama.cpp and Metal, showing next-word suggestions in light gray text (ghost text) plus rewrites of selected text with âŒ¥âŒ˜K: improve, shorten, make formal or casual, fix grammar, summarize. You can bring your own model, and it runs a local OpenAI-compatible endpoint and an MCP bridge, which developers will like. The trade-off is that you manage more yourself.

Refine is an offline grammar checker built on a local Gemma model. It checks as you type, explains each fix, and supports many languages, with a floating editor for rewrites and translation. Its site lists it as free with no account. Note that it optionally lets you plug in your own API key for cloud models. That's off by default, but if you enable it, those requests leave your Mac.

TypeTab is focused on autocomplete. Predictions run on the Apple Neural Engine, and it says no account and no telemetry. It's free to try, then $49 one-time.

DraftKey is my app. It does on-device autocomplete plus instruction-based rewriting: tap âŒ˜ and âŒ¥ together in a text field, choose an action or type a request like "make it shorter," review the result, then insert it. It works on the current paragraph or your selection. It also has optional mechanical keyboard sounds and a local clipboard history, each with its own toggle. The writing model is a separate ~1.12 GB download, and AI features need 8 GB of memory. After setup the model works offline. The internet is only used for the model download, license activation and update checks. There are per-app controls, and secure fields are excluded. It's a $5 lifetime license for up to three Macs.

Weak spots: it's a young app, the model is small so it won't match a large cloud model on complex rewrites, and some custom editors don't expose their text to Accessibility, so it can't work there.

Comparison

Tool	Where text is processed	Autocomplete	Rewriting	Price	Requirements
Grammarly	Cloud	Suggestions	Yes	Free plan; Pro $12/mo annual or $30/mo	Internet required
Apple Writing Tools	On-device, complex requests may use Private Cloud Compute	No (macOS has basic predictive text)	Yes	Free	Apple silicon, Apple Intelligence
Cotypist	On-device	Yes	Word alternatives	Free tier; $72â€“$108/yr	macOS 14+, Apple Silicon
Shadowtype	On-device	Yes	Yes	Free, open source	macOS 14+, Apple Silicon
Refine	On-device (optional bring-your-own-key cloud)	No (grammar checks)	Yes	Free	macOS 14+
TypeTab	On-device	Yes	No	$49 one-time	macOS 14+, Apple Silicon
DraftKey	On-device	Yes	Yes	$5 lifetime (up to 3 Macs)	macOS 14+, Apple Silicon, 8 GB RAM

How I'd choose

Your text may never leave the machine (client work, NDAs, regulated data): rule out Grammarly, and remember that Apple's Writing Tools can use Private Cloud Compute. Pick one of the on-device apps and check its network activity yourself with Little Snitch or LuLu.
You mainly want grammar fixes: Refine, or Apple's Writing Tools if PCC is fine for you.
You mainly want autocomplete: Cotypist if you want deep personalization and don't mind a subscription, TypeTab for a one-time purchase, Shadowtype for free and open source.
You want autocomplete and rewriting in one small paid app: DraftKey or Shadowtype. Shadowtype is free and more hackable. DraftKey is more of a ready-to-use app.

A note on testing claims

Don't take "100% private" on trust, mine included. Install the tool, turn on a network monitor, type a paragraph, and watch what connects. An on-device assistant should be quiet while you write, apart from the license and update checks it tells you about. Ten minutes of testing tells you more than any marketing page.

Which one are you using, and did it pass the network-monitor test?

How to track Claude Code and Codex usage limits on a Mac (5 ways compared)

Henry Godnick — Mon, 19 Oct 2026 20:39:25 +0000

Disclosure: I build TokenBar, one of the tools below. I've tried to keep this useful whichever one you pick, and most of the options here are free.

If you use Claude Code or Codex on a subscription, you've probably hit a limit halfway through a task. Neither tool shows your remaining usage by default, so it's easy to burn through a session window without noticing.

This guide covers five ways to keep an eye on it on a Mac, starting with the free, built-in ones.

First, how the limits actually work

Claude (Pro, Max, Team). Paid plans have two kinds of limits: a session limit that resets every five hours and weekly limits that reset once a week. Max plans also have a separate weekly limit for some models. Usage from claude.ai, Claude Desktop and Claude Code all counts toward the same pool, so a long chat in the browser eats into your coding budget too. How fast you use it depends on the model, context length, effort level and the features you use. (Claude Help Center)

Codex (ChatGPT plans). Codex comes with ChatGPT plans, and its usage depends on the model, task complexity, context, reasoning and tools. Plans have had a five-hour window plus weekly limits, but OpenAI has changed this more than once in 2026. The five-hour window was temporarily lifted for some plans, and Pro currently has no five-hour limit. Codex also shares its allowance with other agent features like ChatGPT Work. Check your own account rather than trusting a blog post, this one included. (OpenAI Help Center)

1. Built-in commands (free, zero setup)

Claude Code:

/usage shows session cost, plan usage limits (the five-hour session and weekly bars with reset times) and activity stats. /cost and /stats are aliases for it.
/context shows what's filling your context window as a colored grid.
/compact [instructions] summarizes the conversation so far to free up context. A bloated context makes every later turn cost more, so compacting early is one of the easiest ways to make your limit last.
/usage-credits opens usage-credit settings when you hit a limit.

Codex CLI:

/status in an active session shows your remaining limits and reset times.
The Codex usage dashboard (Settings â†’ Usage) is the official source of truth.

Pros: official numbers, nothing to install, nothing to trust.
Cons: you have to remember to check, it only works inside a session, and you see one tool at a time.

2. ccusage (free, open source CLI)

ccusage reads the usage data that coding agent CLIs store locally and turns it into daily, weekly, monthly and per-session reports with token counts and estimated costs. It now covers far more than Claude Code: Codex, Gemini CLI, GitHub Copilot CLI, OpenCode, Amp and many others.

npx ccusage@latest          # all detected sources, by day
npx ccusage claude daily    # just Claude Code
npx ccusage codex daily     # just Codex
npx ccusage blocks          # Claude Code 5-hour windows
npx ccusage statusline      # status line for Claude Code hooks (beta)

ccusage blocks is the most useful one for limits, because it groups your Claude Code activity into five-hour windows.

Pros: free, scriptable, --json output, works offline from local files, covers lots of tools.
Cons: it's an estimate built from your local logs. It can't see your plan's actual remaining percentage, and it doesn't count usage from claude.ai or other machines.

3. Read the logs yourself (free, maximum control)

If you want your own dashboard or alerts, the raw data is on disk:

Claude Code: ~/.claude/projects/<encoded-project-path>/<session-id>.jsonl, plus subagents/ folders in newer versions. Assistant records carry a message.usage object with input, output and cache tokens.
Codex CLI: ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl. Look for event_msg records whose payload type is token_count.

Two traps people hit when summing these:

Claude Code duplicates. Resumed sessions can repeat earlier assistant turns, so deduplicate on message.id (plus requestId) or your totals come out inflated.
Codex cumulative totals. token_count events carry both total_token_usage (a running total) and last_token_usage (just that turn). Sum last_token_usage only. Also note that OpenAI's input_tokens already includes cached_input_tokens.

Neither format is officially documented, so expect it to change between versions.

Pros: total control, no third-party code.
Cons: real work to build, breaks when formats change, and like ccusage it can't see your server-side remaining quota.

4. Free menu bar apps

A menu bar app keeps the numbers visible without you having to ask. These three are free and open source (MIT):

CodexBar (macOS 14+, brew install --cask codexbar). It shows limits and reset countdowns for a long list of providers: Codex, Claude, Cursor, Gemini, Copilot and dozens more. You get one menu bar item per provider, or a merged icon. For Claude it uses OAuth, browser cookies or the CLI, and it ships a codexbar CLI for scripts.

Claude Usage Tracker (macOS 14+, installed with Homebrew). It tracks Claude's five-hour session, weekly and per-model usage, with optional Codex tracking. Its standout feature is support for multiple Claude accounts with their own credentials, plus status line integration, usage history charts and threshold notifications.

Usage4Claude (macOS 13+, installed from a DMG, Intel or Apple silicon). It tracks Claude's five-hour, seven-day, extra-usage and per-model limits, plus Codex's five-hour, seven-day and credit balance. Its "pace" graph shows whether you're using your allowance faster than time is passing, which is handy for weekly limits.

Pros: they're free and always visible, and they show your real remaining quota rather than an estimate from logs.
Cons: most read credentials from your Keychain or browser cookies, so read what each one accesses. Some depend on unofficial endpoints that can break when a provider changes things.

5. TokenBar (paid)

TokenBar is my app, so weigh this section accordingly. It's a macOS 14+ menu bar app that brings Claude, Codex, Cursor, Gemini and Copilot into one place: allowances, credits and reset timing, plus a spending view with cost history. It also adds agent notifications for finished tasks, input requests, approvals and stalls on supported integrations, and "Pixel Agents," a small pixel-art office that shows which coding sessions are working or need attention. It also shows CPU, memory and energy so you can see what your agents are doing to your Mac.

Pricing: Pro is $15 once for a lifetime license on one Mac, or Basic is $5/month. You buy inside the app.

Pros: one view across providers, agent notifications, a polished native UI.
Cons: it costs money while the apps above are free. Coverage varies by integration, and it's a one-Mac license.

Comparison

Method	Cost	Shows real remaining quota	Claude Code	Codex	Always visible	Setup
`/usage`, `/status`	Free	Yes	Yes	Yes	No	None
ccusage	Free (OSS)	No (estimate from logs)	Yes	Yes	Via status line	`npx`
Raw JSONL logs	Free	No	Yes	Yes	If you build it	High
CodexBar	Free (MIT)	Yes	Yes	Yes	Yes	Low
Claude Usage Tracker	Free (MIT)	Yes	Yes	Optional	Yes	Low
Usage4Claude	Free (MIT)	Yes	Yes	Yes	Yes	Low
TokenBar	$15 lifetime / $5 mo	Yes	Yes	Yes	Yes	Low

Which should you use?

You check occasionally: /usage and /status are enough.
You want history and cost reports: ccusage.
You want it always visible, for free: CodexBar if you use many providers, Claude Usage Tracker if you juggle several Claude accounts, Usage4Claude if you like pace tracking.
You want spending, agent notifications and multiple providers in one paid app: TokenBar is one option.

Whatever you pick, the habits that stretch a limit the most are the same: /compact before context gets huge, use smaller models for routine work, and keep in mind that your claude.ai chats share the same pool as Claude Code.

What are you using to stay under your limits? I'd like to hear about setups I've missed.

Shipping on-device AI on the Mac: the requirements and tradeoffs I didn't want to hide

Henry Godnick — Tue, 13 Oct 2026 17:18:29 +0000

I'm building DraftKey, a native Mac app that brings together AI autocomplete, instruction-based rewriting, and mechanical keyboard sounds. The one constraint I wouldn't bend on: the writing model runs on your Mac, and your text isn't sent to a cloud AI service.

That choice shapes almost everything else. Here's what it looks like in practice, in case you're weighing local inference for a desktop app of your own.

1. The hardware is the first gate

When inference runs locally, the user's machine does the work. DraftKey needs an Apple Silicon Mac on macOS 14 or later, and the AI features need at least 8 GB of memory. That rules some people out, and I'd rather say so on the download page than have someone find out after installing.

2. The model is its own download

The writing model is a separate download of roughly 1.12 GB, and you need at least 2.2 GB of free space plus room for the app. Onboarding has to explain that clearly, because "download the app" and "download the model" are two different moments for the user.

3. "Offline" needs an honest asterisk

Once the model is downloaded, autocomplete and rewriting work offline. But setup still touches the network: the initial model download, license activation, and update checks. "Your text stays on your Mac" is true. "The app never connects to the internet" would not be, so I don't say it.

4. Working inside other apps means Accessibility

DraftKey works in the apps you already write in by using macOS Accessibility to read and write compatible text fields. Support depends on how each app exposes its text, so some custom editors don't work, and secure fields are always excluded. Per-app controls let you choose exactly where DraftKey is active.

5. Keep the features independent

Autocomplete suggests what to write next while you type. Rewriting changes text you already have, following an instruction like "make it shorter." Keyboard sounds work with no AI at all. Each has its own switch, so you can run only the parts you want.

The shortcuts

Tap Command + Option together, then release, to open Writing tools. It uses your current paragraph automatically, or your selection if you've highlighted text. You review the result before choosing Insert.
Press ⌘⌥V to open clipboard history, pick an earlier text copy, press Return, then ⌘V to paste. That part needs no model and is saved only on your Mac.

A question for you

If you've shipped on-device ML in a desktop app, how did you handle hardware requirements and big model downloads during onboarding? I'd love to hear what worked and what confused people.

Why I chose on-device inference for a writing assistant

Henry Godnick — Mon, 12 Oct 2026 16:54:22 +0000

When I built DraftKey, the biggest decision was running the model locally instead of calling a cloud API. Here are the tradeoffs.

The upside: people's text never leaves their Mac, it works offline, and there are no per-request API costs.

The downside: the app needs a model download of about 1.1 GB, at least 8 GB of RAM, and an Apple Silicon Mac, and a small model has less raw capability than the frontier ones.

For short rewrites and autocomplete, a small local model turned out to be good enough, and privacy ended up being the feature people notice most. Curious whether others building local-AI apps landed in the same place. getdraftkey.com

Shipping a local-LLM writing assistant as a native macOS app

Henry Godnick — Sun, 11 Oct 2026 01:00:24 +0000

A short write-up on building DraftKey. It uses macOS Accessibility to work in text fields across apps, runs an approximately 1.1 GB model on-device so autocomplete and rewrites work offline, and skips secure fields and password-manager copies. Happy to go deeper on the Accessibility quirks or on-device inference if people are interested. getdraftkey.com

What I learned building a system-wide AI writing tool on macOS

Henry Godnick — Thu, 08 Oct 2026 20:06:42 +0000

I assumed a Mac app that helps you write in any text field would be the easy part. It wasn't. Here's what I learned building DraftKey, an on-device writing assistant for the apps you already use.

Reading text across apps means Accessibility

There's no public API that says "give me the text the user is typing in whatever app is in front." What macOS does have is the Accessibility API, the same layer screen readers like VoiceOver use.

The basic flow looks like this:

Ask for Accessibility permission. The user has to approve your app in System Settings under Privacy & Security, and AXIsProcessTrustedWithOptions is how you check (and prompt).
Create a system-wide element with AXUIElementCreateSystemWide() and ask it for kAXFocusedUIElementAttribute to find the focused text field.
Read attributes like kAXValueAttribute, kAXSelectedTextAttribute, and kAXSelectedTextRangeAttribute to get the text and where the cursor is.
Use parameterized attributes like kAXBoundsForRangeParameterizedAttribute if you want to draw UI near the caret.

With standard Cocoa text views, this works well. The problem is everything else.

Not every editor exposes its text

Support depends entirely on how each app exposes its text, and some don't expose much at all:

Editors that draw their own text, like many code editors, terminals, and canvas-based web apps, can give you a focused element with no usable value or selection.
Chromium and Electron apps often build a fuller accessibility tree only once they know assistive tech is around, so what you see can vary.
Some apps report a value but ignore writes to it, or write it but don't register an undo step.

So I stopped promising "works everywhere." DraftKey works in compatible text fields, has per-app controls so you choose where it runs, and skips secure fields completely. Password fields show up with a secure text field subrole, and you should never touch them.

Writing text back is its own decision. Setting the selected text through Accessibility is clean when an app supports it. The common fallback is going through the pasteboard, which means you're messing with the user's clipboard. Whatever you pick, test it app by app.

The modifier-only shortcut

The rewrite panel opens when you tap Command and Option together and let go. A modifier-only shortcut sounds simple, but you're really watching modifier flag changes and deciding "was that a tap, or was the user holding Command+Option on the way to some other shortcut?" If any other key goes down in between, it isn't a tap. Get that wrong and the panel pops up mid shortcut, which is the fastest way to get uninstalled.

Running the model locally has real costs

I wanted writing help that doesn't send your drafts to a cloud AI service. That part works: after a one-time model download of about 1.12 GB, autocomplete and rewriting run offline. The internet is only needed for the download, license activation, and update checks.

But local has tradeoffs you should be upfront about:

RAM. The AI features need at least 8 GB of memory, since the model shares it with everything else that's open.
The download. A 1.12 GB download on first launch is friction. I made it a separate step with clear messaging instead of hiding it in the app bundle.
Speed. Autocomplete has a tight latency budget. If a suggestion shows up after the user already typed the next word, it's noise.
Hardware. Apple Silicon makes this practical. That's why DraftKey requires an Apple Silicon Mac on macOS 14 or later.

The upside: it works on a plane, and your draft emails stay on your Mac.

Review before insert, every time

The design decision I'm most sure about: a rewrite never replaces your text directly. You type an instruction like "make it shorter," it works on the current paragraph (or your selection if you highlighted something), you see the result, and you choose whether to insert it.

Language models get things wrong sometimes. They drop a detail or change a meaning. A review step costs one keystroke, saves you from sending something you didn't write, and keeps your voice yours.

Everything is a toggle

Autocomplete, rewrites, local clipboard history (Command+Option+V), and six mechanical keyboard sound profiles all toggle independently. Some people only want the sounds, which work with the AI turned off.

Try it

If you're curious, there's a free typing test with the keyboard sounds on getdraftkey.com. No install needed. And if you've built anything on top of the Accessibility API, I'd love to hear which apps gave you the most trouble.

Planning an offline writing session on Mac? Download the model before you go.

Henry Godnick — Thu, 08 Oct 2026 15:46:56 +0000

A train journey or a few hours away from Wi-Fi can be useful time to draft documentation, support replies, or client emails. With a local writing assistant, the preparation happens before you disconnect: the app, its model, and the document all need to be ready.

Disclosure: I’m behind DraftKey. This article was written and published by an AI assistant using DraftKey’s documentation.

The installer is only the first download

DraftKey provides autocomplete and rewriting in compatible Mac text fields. Its writing model runs on your Mac, but it is downloaded separately from the app.

The documented setup sequence is to install DraftKey in Applications, follow its permission prompts, activate a purchased license, and let the writing model finish downloading. Clicking Get started begins that model download in the background.

That last step is easy to overlook. Having the installer on your Mac does not mean the AI is ready for an offline session. Check the model’s download status while you still have a reliable connection.

The current requirements are Apple Silicon, macOS 14 or later, and at least 8 GB of memory for AI. The model is approximately 1.12 GB; allow at least 2.2 GB of free space for it, plus room for the app. A purchased license is required for activation.

Prepare the exact text field you plan to use

DraftKey uses macOS Accessibility to work with text in other apps. In its per-app controls, enable the editor where you intend to write, and enable the writing feature you want.

Compatibility can vary between fields inside the same app. Secure fields are excluded, and some custom editors do not expose the text access DraftKey needs. An app appearing in your Dock is therefore not enough to establish compatibility.

Before leaving, try a short, non-sensitive paragraph in the actual field you’ll use. Open Writing tools, request a small change, and confirm you can review and apply the result. If nothing appears, check activation, model readiness, feature settings, Accessibility permission, and the per-app setting in that order.

Bring the document as well as the model

An assistant’s local inference does not make a browser-only editor available offline. Open the document in advance and use your editor’s supported offline or local-save workflow.

The same distinction matters for privacy: where DraftKey processes a rewrite and whether your editor syncs the document are separate questions. Choose both parts of the workflow deliberately.

For a support reply, that might mean drafting in an available local document, making a wording pass, and sending it when you reconnect. Confirm the destination editor works for you before depending on it during a journey.

What still needs a connection?

After setup, DraftKey’s autocomplete and rewrites use the downloaded model locally. Initial app and model downloads, license activation, and update checks use online services. Finish those setup steps ahead of time.

If that fits your routine, the DraftKey setup guide covers installation and text-field troubleshooting. The local AI guide explains which operations stay on your Mac and which use the internet.

I stopped pasting my drafts into ChatGPT. Here's the offline Mac app I use instead.

Henry Godnick — Thu, 08 Oct 2026 00:51:12 +0000

Every time I wanted a sentence to sound better, I'd copy it, switch to a browser tab, paste it into a cloud AI, wait, copy the result, and switch back. That's five steps, and my unreleased work was going to someone else's server.

So I built DraftKey. It brings AI writing help into the Mac apps you already write in, and the model runs entirely on your Mac.

The 2-second workflow

Write anywhere: email, Notes, Slack, whatever you use.
Tap ⌘ + ⌥ and let go.
Type "make it shorter" or "sound warmer," then review the rewrite and insert it.

You don't need to select anything first, because it works on the paragraph you're in. As you type, autocomplete suggests the next words in compatible text fields.

Your words never leave your Mac

After a one-time model download, autocomplete and rewriting work offline. None of your text goes to a cloud AI service. You choose which apps it runs in, and it skips secure fields automatically.

Two extras people end up loving

Clipboard history: Copied over something important? Press ⌘⌥V to search your recent copies and bring one back. It's stored locally and skips password-manager copies.
Mechanical keyboard sounds: Every keystroke gets that satisfying click, and it works with the AI turned off.

Try it in 15 seconds, no install

The site has a typing test with the keyboard sounds built in, so put on headphones and hear it for yourself. Then grab the app if you're on an Apple Silicon Mac with macOS 14 or later.

👉 Get DraftKey

I'd love your feedback. Which app should I make sure it works perfectly in next?

Text replacement, autocomplete, or rewrite? A practical Mac writing workflow

Henry Godnick — Mon, 05 Oct 2026 18:25:00 +0000

If you write support replies, bug reports or client emails on a Mac, some sentences repeat exactly. Others need different wording every time. Choosing the right kind of writing help starts with that distinction.

Disclosure: I’m behind DraftKey, a Mac writing assistant. This article was drafted by an AI assistant using public documentation. The examples are illustrative.

1. Use text replacement when the wording should stay fixed

Think about a sentence you repeatedly type, such as:

Please include the app version and macOS version in your reply.

You already know the wording. A saved shortcut is enough.

macOS has built-in Text Replacement. Open System Settings, choose Keyboard, then Text Replacements. Add a short trigger and the text it should expand into.

For example, you could save ;appdetails as the trigger for that sentence.

Apple notes that text replacement works in many apps, with exceptions. Check it in the editor where you actually write. Apple’s setup guide explains the settings and app-level controls.

Good candidates include:

A standard request for reproduction steps
A frequently used sign-off
A product name you keep mistyping
A short sentence that has already been reviewed

Keep saved wording current. An outdated template can reproduce an outdated instruction perfectly.

2. Use autocomplete while the sentence is still taking shape

Now consider a reply that begins:

Thanks for the recording. The part I need to understand is…

The next words depend on this particular conversation. There may be no useful fixed phrase to save.

Autocomplete proposes a continuation while you write. DraftKey provides that kind of help in compatible Mac text fields, with inference running locally.

You can keep typing to ignore a suggestion. Its current autocomplete documentation also describes accepting one word at a time, which is useful when the beginning fits but the rest takes the sentence somewhere you didn’t intend. The shortcut depends on your autocomplete settings.

You still need to supply the substance. A plausible continuation doesn’t establish what caused a bug or what a customer needs.

3. Use a rewrite when the draft exists and the wording needs work

Suppose you have this rough request:

Can you record what happens? Start before clicking export and include the error message because that’s the bit we need.

Here, the task is to change an existing draft. A specific instruction might be:

Make this a polite, concise support reply. Keep the request to start recording before clicking Export and include the error message.

In DraftKey’s Writing tools, you can work with the current paragraph or select a smaller passage. Review the proposed version, edit it if necessary, then choose Insert.

Selecting only the passage that needs work also makes the review smaller. You don’t need to ask for a new version of the entire email.

4. Combine them within one reply

A support message can contain both fixed and changing parts.

Use a saved phrase for a standard request. Write the case-specific explanation yourself, with autocomplete if it helps. Then select that explanation for a rewrite if its wording needs another pass.

For example:

Saved phrase: ask for app and macOS versions
Case-specific text: explain which part of the recording is needed
Optional rewrite: make that explanation easier to follow

Keep any wording that must remain exact outside the selected passage. Review the assembled reply before sending it.

Before choosing another writing tool

Look at three ordinary messages you write regularly. For each one, ask:

Am I repeating the same words?
Am I still composing the sentence?
Have I written the message but need to improve its wording?

If most of the work is repeated text, start with Text Replacement. If the wording changes with each conversation, autocomplete or rewriting may be more relevant.

DraftKey covers those latter tasks in compatible Mac text fields. It requires Apple Silicon and macOS 14 or later. AI requires at least 8 GB of memory, an approximately 1.12 GB model download, and at least 2.2 GB of free space plus room for the app. A license is required.

Its writing inference runs on your Mac; model downloads, licensing and updates still involve network services. Compatibility depends on the editor’s Accessibility support, and some custom editors and secure fields are excluded.

You can review DraftKey’s requirements and installation guide before deciding whether it fits your writing workflow.

DEV Community: Henry Godnick

Claude Pro vs Max vs API for Claude Code: which plan fits your actual usage

What you're choosing between

The API prices you'll use

Where the numbers live

A small script to price your last 30 days

Reading the result

Use the right /usage number

Check again after a month

How Mac apps add text suggestions to every app: the Accessibility API explained

Step 0: become a trusted client

Step 1: find the focused text field

Step 2: find where the caret is on screen

Step 3: react to typing without polling

Step 4: put the text back

Why it doesn't work everywhere

Debugging tips

Where the model fits

How to make Claude Code's usage limits last longer: 9 practical habits

1. /clear between unrelated tasks

2. Compact on purpose, and tell it what to keep

3. Mind the cache after a break

4. Match the model to the job

5. Turn thinking down for easy tasks

6. Shrink what loads every session

7. Be specific, and plan before you build

8. Keep noisy output out of the main conversation

9. Watch what runs when you're not typing

The common thread: notice before you hit the wall

Private AI writing assistants for Mac in 2026: what actually runs on-device

What "on-device" should mean

The cloud option: Grammarly

The built-in option: Apple Intelligence Writing Tools

Third-party apps that run on-device

Comparison

How I'd choose

A note on testing claims

How to track Claude Code and Codex usage limits on a Mac (5 ways compared)

First, how the limits actually work

1. Built-in commands (free, zero setup)

2. ccusage (free, open source CLI)

3. Read the logs yourself (free, maximum control)

4. Free menu bar apps

5. TokenBar (paid)

Comparison

Which should you use?

Shipping on-device AI on the Mac: the requirements and tradeoffs I didn't want to hide

1. The hardware is the first gate

2. The model is its own download

3. "Offline" needs an honest asterisk

4. Working inside other apps means Accessibility

5. Keep the features independent

The shortcuts

A question for you

Why I chose on-device inference for a writing assistant

Shipping a local-LLM writing assistant as a native macOS app

What I learned building a system-wide AI writing tool on macOS

Reading text across apps means Accessibility

Not every editor exposes its text

The modifier-only shortcut

Running the model locally has real costs

Review before insert, every time

Everything is a toggle

Try it

Planning an offline writing session on Mac? Download the model before you go.

The installer is only the first download

Prepare the exact text field you plan to use

Bring the document as well as the model

What still needs a connection?

I stopped pasting my drafts into ChatGPT. Here's the offline Mac app I use instead.

The 2-second workflow

Your words never leave your Mac

Two extras people end up loving

Try it in 15 seconds, no install

Text replacement, autocomplete, or rewrite? A practical Mac writing workflow

1. Use text replacement when the wording should stay fixed

2. Use autocomplete while the sentence is still taking shape

3. Use a rewrite when the draft exists and the wording needs work

4. Combine them within one reply

Before choosing another writing tool

Use the right `/usage` number

1. `/clear` between unrelated tasks