Spell Correction for AI Prompts

How Terse's 4-stage pipeline catches typos before they reach the model — preventing costly retry loops in Claude Code, ChatGPT, and Cursor sessions.

Why Typos in AI Prompts Are Expensive

When you send a prompt to an LLM, every token counts. A misspelled word does not simply get auto-corrected by the model. It gets tokenized, processed through attention layers, and billed at full price. Worse, it can cause the model to misunderstand your intent entirely.

Consider a common scenario: you type authetication instead of authentication in a prompt asking Claude Code to fix a login bug. The model might interpret this as a novel technical term, spend tokens asking for clarification, or generate code referencing a misspelled variable name that then causes a cascade of errors in subsequent agent turns.

In agentic coding sessions, this problem compounds dramatically. Each turn in a Claude Code or Cursor session builds on the previous context. A typo in turn 1 can trigger a retry loop that wastes 10 to 50 times more tokens than the original prompt. The agent reads the misspelled term, generates code with the same misspelling, encounters an error, retries with a different interpretation, and the cycle continues until the context window is saturated with wasted reasoning.

At current API pricing, a single typo-induced retry loop can cost between $0.05 and $0.50 depending on the model and context length. Across hundreds of daily prompts, this adds up to real money. More importantly, it wastes time. Every retry loop is 10 to 30 seconds of waiting for a response that should not have been necessary.

Browser spellcheck does not help here. Most AI interfaces use custom text fields or web-based editors where browser spellcheck either does not activate or flags technical terms as errors. VS Code's built-in spellcheck is oriented toward code comments, not prompt composition. There is a gap between where you write prompts and where spelling gets checked.

How Terse's Spell Correction Pipeline Works

Terse runs a 4-stage spell correction pipeline that executes entirely on-device before any optimization or compression takes place. Every prompt passes through all four stages in sequence, and the entire pipeline completes in under 5 milliseconds for typical prompt lengths. No data leaves your machine. No API calls are made. The corrections happen inline as you type.

Stage 1: Hardcoded Typo Dictionary

The first stage is the fastest and most reliable. Terse maintains a curated dictionary of over 400 common typos that appear frequently in coding and AI prompt contexts. These are direct string replacements with zero ambiguity.

Examples from the dictionary:

"authetication" → "authentication"
"wirte"         → "write"
"funciton"      → "function"
"reponse"       → "response"
"impelment"     → "implement"
"retrun"        → "return"
"lenght"        → "length"
"widht"         → "width"
"heigth"        → "height"
"exmaple"       → "example"

This dictionary was built by analyzing thousands of real prompts sent to coding assistants. The entries are specifically weighted toward developer vocabulary: variable names, API terms, framework keywords, and common instruction verbs. Because these are exact-match replacements, the false positive rate is effectively zero. The word authetication has no legitimate meaning. It is always a typo.

Stage 1 runs in constant time per word. It is a hash table lookup, so even prompts with thousands of words complete in microseconds.

Stage 2: Norvig Edit-Distance Correction with QWERTY Weighting

For typos not covered by the hardcoded dictionary, Terse uses a modified version of Peter Norvig's statistical spelling corrector. The classic Norvig algorithm generates all words within edit distance 1 or 2 of the misspelled word and selects the most probable candidate based on word frequency data.

Terse enhances this with QWERTY keyboard proximity weighting. When scoring candidate corrections, edits involving adjacent keys on a QWERTY layout receive higher probability than edits involving distant keys. The intuition is simple: if you typed wirte, the most likely intended word is write because i and r are adjacent keys that were hit in the wrong order. A substitution of a for q is more probable than a for m because those keys are physically next to each other.

This proximity weighting significantly improves accuracy for fast typists who frequently transpose or substitute adjacent keys. For a deeper look at the algorithmic foundations, see our Norvig Spelling Corrector reference page.

The word frequency corpus is tuned for technical and instructional English, not general prose. Words like function, implement, parameter, and configuration have higher base frequencies than they would in a standard English corpus, which means the corrector is more likely to suggest them as replacements.

Stage 3: Context-Aware Real-Word Error Detection

Stages 1 and 2 handle non-word errors, where the misspelled word is not a real English word. Stage 3 tackles a harder problem: real-word errors, where the typo produces a valid word that is wrong in context.

The classic example: "what souls I do" contains three valid English words, but souls should be should. A traditional spellchecker would not flag this because souls is a real word.

Terse detects these errors using bigram probability analysis. It examines each pair of adjacent words and checks whether the pair is statistically improbable given a language model trained on instructional and technical text. The bigram "what souls" has extremely low probability compared to "what should", so Terse flags it and suggests the correction.

This stage is more conservative than the others. It only triggers when the probability ratio between the original bigram and the corrected bigram exceeds a high confidence threshold. This prevents false positives on unusual but intentional word combinations. In practice, it catches errors like:

• "can you right a function" → "can you write a function"
• "I want too add a feature" → "I want to add a feature"
• "what souls I do next" → "what should I do next"
• "please sent the response" → "please send the response"
• "the filed is required" → "the field is required"

Stage 4: macOS NSSpellChecker Integration

The final stage leverages macOS's built-in NSSpellChecker API through Terse's compiled Swift accessibility helper. This catches anything the first three stages missed, and it supports every language installed on your system.

NSSpellChecker has access to Apple's system dictionaries, user-added words, and learned corrections. If you have added technical terms to your macOS dictionary through other apps, Terse will respect those. If you write prompts in German, French, Spanish, or any other language macOS supports, the system spellchecker handles it.

This stage runs as a subprocess call to the terse-ax Swift binary, which means it executes natively outside the Electron process. The latency is typically 1 to 3 milliseconds for a full prompt check. Because it runs after the first three stages, it only needs to evaluate words that were not already corrected, keeping the workload minimal.

Protecting Code and Technical Terms

A spell corrector that flags your code as errors is worse than useless. Terse applies several filters before any correction stage runs:

• ALL-CAPS words are skipped. Acronyms like API, HTTP, JSON, and SQL are never modified.
• Capitalized words (proper nouns, class names) are skipped. React, PostgreSQL, Kubernetes pass through untouched.
• Inline code blocks (text between backticks) are preserved exactly as written.
• URLs and file paths are detected and excluded from correction.
• CamelCase and snake_case identifiers are recognized as code and left alone.
• Words with numbers (like v2, h1, utf8) are treated as technical terms and skipped.

These filters mean you can freely mix natural language instructions with code snippets, variable names, and technical jargon in your prompts. Terse corrects the English while leaving everything else untouched.

Impact on Agent Sessions

In a typical Claude Code or Cursor session, you send 20 to 50 prompts over 30 to 60 minutes. Each prompt averages 40 to 100 tokens. If even 5% of those prompts contain a typo that causes a single retry or clarification, you are looking at 1 to 3 wasted turns per session, each costing the full context window re-read.

For a session with 80,000 tokens of accumulated context, one retry turn costs roughly $0.08 at Claude Sonnet pricing and $0.24 at Opus pricing. Three retries per session, across 5 sessions per day, adds up to $1.20 to $3.60 daily in pure waste. Over a month, that is $25 to $75 in tokens spent on nothing.

Terse's spell correction eliminates this category of waste entirely. The pipeline runs before the prompt is sent, so the model always receives clean, correctly-spelled input. No retries. No clarification requests. No misspelled variable names propagating through generated code.

This becomes even more critical with agent monitoring enabled. When Terse detects an agent session (Claude Code, Cursor, Windsurf), it monitors each turn's token usage and flags anomalies. Spell correction at the input layer is the first line of defense against the kind of compounding waste that makes agent sessions expensive.

How Terse Compares to Other Approaches

Browser Spellcheck

Built-in browser spellcheck works in standard text inputs and content-editable elements. It does not work in most AI chat interfaces, which use custom components. It also has no understanding of technical vocabulary, frequently flagging words like async, middleware, and webhook as errors. It cannot detect real-word errors and offers no QWERTY proximity weighting.

Grammarly and LanguageTool

These tools are designed for long-form prose writing. They focus on grammar, style, and tone. They work well for emails and documents but are too aggressive for AI prompts, where brevity and directness are virtues. They also require cloud connectivity, which means your prompts are sent to a third-party server. For proprietary code discussions or sensitive project details, this is a non-starter.

Terse runs entirely on-device. Your prompts never leave your machine.

LLM-Based Correction

You could ask the LLM itself to correct your typos, but that means sending the typo-laden prompt first, paying for those tokens, and then paying again for the corrected version. It defeats the purpose. The whole point is to fix errors before they reach the model.

Spell Correction in the Optimization Pipeline

Spell correction is Stage 1 of the Terse optimization pipeline. It runs before pattern optimization, NLP analysis, and telegraph compression. This ordering is intentional: correcting spelling first ensures that downstream stages operate on clean text, which improves their accuracy.

For example, the pattern optimizer has a rule that converts "in order to" to "to". If a typo produced "in ordor to", the pattern would not match, and the compression opportunity would be lost. By fixing the spelling first, every downstream optimization has the best possible input to work with.

In Soft mode, spell correction is one of the primary operations (along with whitespace compression). It preserves 100% of your intended meaning while fixing mechanical errors. In Normal and Aggressive modes, spell correction still runs first, but the prompt then passes through additional compression stages that reduce token count further.