Building an AI Chrome extension in 2026: side panel UI, the Gemini API, and surviving Manifest V3

"Can you add AI to it?" is now attached to almost every extension brief I get — lead capture tools that qualify while they scrape, support widgets that draft replies, research panels that summarize whatever's on screen. The engineering answer is yes, but there are exactly four decisions that separate an AI extension that ships from one that dies in review or bleeds API money. Here's how I build them on Manifest V3.

Architecture: the four pieces

Side panel (chrome.sidePanel) — the natural home for chat and summaries. It persists across tab switches, unlike a popup, and doesn't need content-script UI injection. In 2026 this is where your users expect the AI to live.
Content script — extracts exactly the text the user asked about: the selection, the article body, the product table. Nothing else.
Service worker — same MV3 rule as always: a router, not a brain. It receives messages, forwards requests, and stores state — because it will be killed mid-task.
A tiny API proxy — the piece most tutorials get dangerously wrong.

Never ship your API key in an extension

An extension's code is fully readable by anyone who installs it. Embedding your Gemini/OpenAI key means donating it to the first student who unpacks your CRX. The production pattern:

// service worker — calls YOUR proxy, not the model vendor
const res = await fetch('https://your-proxy.workers.dev/summarize', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Ext-Token': await getInstallToken() // per-install, revocable
  },
  body: JSON.stringify({ text: selectedText, task: 'summary' })
});

The proxy (a Cloudflare Worker is plenty) holds the real key, enforces per-user quotas, and lets you rotate credentials or switch models without shipping an extension update. For internal team tools, the proxy also answers the security team's first question: "where do the prompts go?"

The streaming UX

Users forgive a two-second wait; they don't forgive silence. Stream tokens from the model through the proxy (SSE works) and render as they arrive in the side panel. A summary that types itself feels ten times faster than the identical text appearing after a spinner.

Surviving store review with an AI extension

Minimal permissions. activeTab + the side panel passes review fast. Broad host permissions plus "reads page content and sends it to an AI" reads like spyware to a reviewer — because sometimes it is. If you must have broad access, say exactly why in the review notes.
Send only what's needed. The selection, not the page. The visible table, not the DOM. State it in the privacy policy and actually do it.
Show a "what was sent" log in the panel. It builds trust and preempts complaints that trigger re-reviews.

Cost control is a feature

Route by task size: flash-class models for summarize/classify, bigger models only when the user asks for depth. Most requests are small.
Cache aggressively: the same article re-summarized on three tabs is one API call, keyed on a content hash.
Per-user quota enforced at the proxy — one enthusiastic user shouldn't be able to torch the monthly budget.

What clients actually ask for

In order, 2026 edition: "summarize this page/thread", "extract these fields into Sheets", "draft a reply in my voice", "score this lead while I browse". Notice all four are assist patterns — the human stays in the loop. That's also what keeps you out of automation-policy trouble on the platforms you're scraping.

Have one of these in your head? I build AI extensions end-to-end — side panel to proxy to store listing. Realistic budget first: what a custom extension costs — then pressure-test the idea before spending anything.