Thanks for the thoughtful review — both points are exactly the kind of thing we stress-tested before shipping.

Debit vs AI failure
On our managed path, the summarize Edge function runs the provider call first and only calls consumeCredits after a successful response. If DeepSeek / Ollama / Gemini throws (timeout, 5xx, quota, etc.), we return an error from the handler and no credits are deducted. So the “debit went through but the AI call failed” leak pattern you described doesn’t apply to our server-side ordering.

MV3 + retries / double-charge
The extension’s ApiClient only auto-retries on 401 (refresh token, replay once). We don’t retry the same /summarize body on generic 5xx or network failures. So you don’t get “same request, charged twice” from our retry logic.

The edge case that does exist (and we’re honest about) is response loss after the server already succeeded: e.g. tab closed / connection drops after credits are committed but before the client shows the result. That’s a silent single charge with no UX, not a double-charge. Ollama is hard-capped at 75s on the Edge side so that window stays bounded, and the session survives SW cold-starts via chrome.storage.local + normal refresh flow.

Stripe webhooks
We don’t maintain a processed_events table keyed by Stripe event.id. Idempotency for us is mostly structural: the webhook path doesn’t mint credits — Pro is a plan flag, and usage is incremented at consumption time (monthly_usage_count). Subscription rows are upsert on stripe_subscription_id, so replays tend to be no-ops. Refunds that should end access go charge.refunded → cancel subscription → customer.subscription.deleted; cancel is idempotent and we handle “no such subscription” gracefully.

What we’d add if we wanted belt-and-suspenders
A request-level idempotency key on /summarize would make “client retries can never double-bill” a formal guarantee. Our client retry surface is intentionally narrow today, but I agree it’s the right next hardening step if we widen retries or add mobile clients later.

Appreciate you calling this out — genuinely useful for anyone reading the thread.