How I built an AI spell-checker Chrome extension (and the API bill mistake that nearly killed it)

작성자

카테고리:

← 피드로
DEV Community · Typo Guard · 2026-08-06 개발(SW)
Cover image for How I built an AI spell-checker Chrome extension (and the API bill mistake that nearly killed it)

Typo Guard

I kept sending messages with typos.

Not in documents — those have spell-checkers. I mean the places where you actually write all day now: the ChatGPT prompt box, a Gmail reply, a Messenger chat, a reply to a guest on Airbnb. Browsers underline the odd word, but they don’t understand context, and they don’t work consistently across every web app. So I built a Chrome extension to fix it, and called it TypoGuard.

It’s an AI-powered spell and grammar checker that corrects your text in real time, inside the web tools you already use. Here’s how it’s built, and the one mistake that almost sank the whole thing.

The idea: Google’s “Did you mean?” everywhere

Google Search has trained us all: you mistype, and it quietly suggests the right thing. I wanted that same experience in every text field on the web — Gmail, ChatGPT, Claude, Gemini, Messenger, Google Messages, and platforms like Airbnb and Booking where a clean message matters.

The architecture

Content scripts (Manifest V3). The extension injects content scripts that watch editable fields (textarea, contenteditable, inputs) on the supported sites. When you pause typing, it grabs the text and sends it off for a correction pass, then surfaces suggestions inline.

A proxy in front of the AI — never ship your API key. The corrections are powered mainly by Gemini. The obvious-but-wrong approach is to call the model directly from the extension. That means your API key is sitting in client-side code for anyone to extract. Instead, every request goes through a Cloudflare Worker that holds the key server-side, applies rate limits, and returns only the correction. The extension never sees the key.

Usage metering with Workers KV. TypoGuard is freemium, so I needed per-user quota without forcing an account. Each install gets a device UUID; the Worker tracks monthly corrections per device in Workers KV. Hit the free limit and corrections pause until the next cycle. Upgrades go through Lemon Squeezy, with webhooks flipping the device to unlimited.

The mistake that nearly killed it

For a while my costs made no sense. The dashboard showed one thing; the actual bill was roughly 100× higher. I assumed a runaway loop somewhere in the extension.

It wasn’t the extension. It was one default.

The Gemini model I was calling runs with “thinking” tokens enabled by default. For a task like “fix the spelling in this sentence,” those reasoning tokens are pure waste — and you pay for them. The fix was a single line in the request config:

generationConfig: {
  thinkingConfig: { thinkingBudget: 0 }
}

Enter fullscreen mode Exit fullscreen mode

Costs dropped back to sane levels immediately. If you’re building anything on top of a modern LLM API and doing short, mechanical tasks, check whether you’re silently paying for reasoning you don’t need. It’s the cheapest optimization I’ve ever shipped.

Things I’d tell my past self

  • Proxy your model calls from day one. Retrofitting a key out of client code is worse than starting with a Worker.
  • Meter usage before you monetize. Device UUID + KV gave me a real free tier without an auth wall.
  • Read the API defaults, not just the docs you need. The thinking-tokens default cost me more than any bug.

TypoGuard is a desktop Chrome extension (not mobile), with a free plan and a premium tier for unlimited corrections and more languages. If you want to see it in action, it’s at typoguard.vip.

Happy to answer anything about the Worker proxy or the freemium setup in the comments.

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다