Buddhi Privacy Policy

Effective date: August 17, 2026 · Applies to the Buddhi Chrome extension and the Buddhi backend API · Developer / company: RedGobble

This policy describes how Buddhi handles data when you use the extension. It is written to match the implementation as it exists today. If the product changes, this policy will be updated before the change ships.

1. What Buddhi collects

Buddhi collects only the information you choose to work with, plus the minimum context needed to respond:

• Selected text — the exact text you select on a page and ask Buddhi to explain, summarize, or reply to. Capped at 12,000 characters.
• Surrounding context snippet — a short, bounded snippet (up to ~1,200 characters) of the text immediately around your selection, used to make the response context-aware. Buddhi never requests page content beyond your selection and this bounded snippet; any personally identifiable information in a request is only what you explicitly chose to select.
• Page context — the current page's domain (e.g. linkedin.com) and document title.
• Conversation history for follow-ups — when you send a follow-up ("make it shorter"), the previous user and assistant turns in the current session (bounded to the 8 most recent turns) are sent so the AI can preserve context.
• Your settings — response length, reply tone, and language preferences. Stored in your browser via chrome.storage.sync so they follow you across devices. Sent with each request and used only to shape the response.
• Usage metadata for quota and rate limiting — Buddhi enforces daily, hourly, and burst limits per installation. The extension carries an anonymous installation id (a random value generated on install) plus an anonymized IP-family signal (the first three octets of the IP). The backend validates the id format and derives a hashed server-side quota key from it — the raw id is never used as a storage key, and no name, email, or account is associated with it. Aggregate usage metadata (quota key hash, action type, model, token counts, estimated cost, latency, status) is tracked server-side to enforce quotas and estimate AI spend. No message content is included in this metadata.

2. What Buddhi does NOT collect

Buddhi does not collect or transmit:

• Passwords, cookies, authentication tokens, or session data
• Form values, input fields, or typed drafts outside your explicit selection
• Browsing history or lists of visited URLs (only the single current page's domain + title are sent)
• Content from other tabs or windows
• The full HTML or DOM of any page
• Health, financial, or location data
• Your name, email address, or any account identifier (Buddhi has no accounts)

3. When is your data sent?

Data is sent only when you explicitly trigger a request:

1. You select text and click Explain / Summarize / Draft Reply / Ask, or send a request from the Buddhi popup, or
2. You send a follow-up that continues a request.

Each request sends the data described in section 1 to the Buddhi backend API, which forwards the necessary prompt to the AI provider.

4. Where the data goes and who processes it

• Buddhi backend API — hosted by RedGobble. The backend builds the prompt, enforces rate limits, and streams the response back.
• AI provider — the backend forwards your request to a third-party AI provider (OpenRouter in the production deployment, with Groq available as an alternative) to generate the response. The provider receives the prompt built from your selection, context, and settings. The provider's own terms and privacy policy apply to its processing.

5. Storage

• Selected text and page content are NOT stored. The backend does not persist the content of your selections. Prompts are streamed to the provider and are not written to a database.
• Conversation history is NOT stored server-side. Follow-up history lives only in memory for the duration of a request and in your browser's session for the current conversation.
• Settings are stored locally in your browser via chrome.storage.sync.
• Rate-limit/usage counters live in the backend's usage store (memory by default; Redis in production) keyed by the hashed server-side quota key, with automatic expiry per window.
• Usage metadata (anonymous quota key hash, action type, model, token counts, estimated cost, latency, status) is recorded server-side to enforce quotas and monitor spend. It never contains message content and is not linked to an account.
• Logs contain operational metadata only (action type, provider, model, character counts, token counts, timings, status). Logs never contain your selected text, page title, or prompt content.

6. How long data is retained

• Rate-limit and usage counters expire automatically (per-minute, per-hour, and end-of-day for daily counters; monthly for budget meters).
• Aggregate usage metadata is retained only as long as needed to operate and secure the service, then deleted.
• Operational logs are retained only as long as needed to operate and secure the service, then deleted.

7. Your choices

• Turn off the floating button — disable "Floating button" in the Buddhi popup Settings.
• Don't send a selection — simply don't select text / don't trigger a request.
• Clear settings — uninstalling the extension removes its locally stored settings.

8. Children's privacy

Buddhi is not directed at children under 13 and does not knowingly collect personal information from children.

9. Changes to this policy

If this privacy policy changes, the effective date at the top of this document will be updated and the revised policy will take effect immediately. If the extension is updated in a way that materially changes data handling, the policy will be updated before that update ships.

10. Contact

For privacy questions or support, contact RedGobble through the contact information available at https://redgobble.com/.

Made by RedGobble · https://redgobble.com/