It wasn't. The number that decides the tier turned out to have nothing to do with the monthly price.

Every hosted tier has a retention cap

Chatwoot Cloud keeps your conversation history for a bounded window, and the window is set by the tier:

• Free tier: 30 days

• Entry paid tier: 6 months

• Mid tier: 1 year

• Top tier: 2 years

That is not a soft limit or an archive. Older conversations are removed.

My oldest message is from 25 November 2025. As I write this that is 282 days of history. On the entry paid tier, roughly three months of client conversations would already be gone.

Why this is an architecture decision, not a billing detail

A support inbox is not a chat app. It is a record.

The questions that make it valuable are all backwards-looking. What did we quote them in March? Did we ever tell this customer the migration was included? Which agent handled the escalation, and what did they promise? Every one of those needs history that outlives the incident.

Once you frame it that way, the retention cap stops being a line in a pricing table and becomes a constraint on what the system is for. A tool that forgets six months back cannot answer "what did we agree in the spring."

Self-hosted has no retention cap at all. Your history lasts as long as your disk does — and disk is cheap. My whole Postgres database, 350,000 messages in, is under a gigabyte.

What it costs to keep it

The natural follow-up is what self-hosting actually consumes, since "free licence" and "free" are not the same thing. Measured on my production install, steady state: chatwoot-rails-1 827 MiB, chatwoot-postgres-1 595 MiB, chatwoot-sidekiq-1 368 MiB, chatwoot-redis-1 7 MiB — 1.80 GiB in total.

Under two gigabytes of RAM for 20 inboxes. A modest VPS runs it comfortably, and — the part that matters for the comparison — that footprint tracks message volume, not seat count. Adding an agent costs nothing. On any hosted plan, each seat is a recurring line item.

I put the full tier-by-tier comparison, including where the crossover sits at different team sizes, in a longer write-up: what Chatwoot actually costs to run.

The honest counterweight

Self-hosting is not free, it is differently expensive. Over nine months I have worked through Postgres connection-pool exhaustion under load, a Redis eviction policy that silently dropped background jobs, a log rotation config that corrupted an access log badly enough to break my own monitoring, and an upgrade that reverted files I had mounted into the container.

None of those were Chatwoot's fault. All of them were the price of the zero-cost licence, paid in evenings.

If nobody on your team is comfortable on a server at 11pm, hosted is genuinely cheaper for you, because the alternative is not "a server" — it is "a server plus a person."

But do read the retention row before you pick the tier. It is the constraint that will actually bite, and it is the one nobody quotes.

Figures measured on a production install, September 2026. I build WhatsApp bots and business automation at Achiya Automation, and I run self-hosted Chatwoot for clients.

I asked an AI agent to cross-post a 7,000-character article from dev.to to Hashnode.

The Submit click succeeded. Hashnode returned a draft URL. I clicked through.

The draft had **446 characters**: the first paragraph, then 41 empty paragraphs, then the last paragraph.

This is a postmortem of how I got there, why my first three diagnoses were wrong, and what fixed it. If you're shipping any kind of browser automation that touches modern rich-text editors, this one is worth the read.

## The setup

[Safari MCP](https://github.com/achiya-automation/safari-mcp) is the macOS-native browser automation tool I maintain. One of the things it has to do is fill rich-text editors — Quill, ProseMirror, Lexical, the React-controlled stuff Featured.com uses, and a dozen variations.

For the cross-posting flow specifically, the agent does this:

- Opens the Hashnode "new draft" page in my real Safari (already signed in).
- Drops a 7,000-character markdown body into the editor.
- Clicks Publish.

That's it. It worked for years on dev.to, Medium, X, LinkedIn (after their 2026 Quill migration), Featured.com. Hashnode was supposed to be the easy one — they sell themselves as "developer-friendly".

## The symptom

After Submit, the draft saved with the first paragraph intact, then 41 empty paragraphs, then the last paragraph intact.

Total saved: 446 chars. Total sent: 6,808 chars. **The middle 94% was silently dropped.**

The agent had no error. The fill call returned successfully. The Submit click returned successfully. Hashnode's own draft view showed the broken structure as if it were intentional.

## First diagnosis (wrong): paste race condition

My first guess was a paste-event timing issue. I'd recently fixed a similar bug on X.com where the synthetic `ClipboardEvent('paste')` was racing with their React `useEffect` cycle. The fix had been an explicit `execCommand('delete')` before the paste.

I tried the same thing here. No change.

I added a `safari_verify_state` call between fill and submit. The verifier confirmed the editor's `.textContent` matched what I sent — at the moment I checked. But by the time Submit fired ~100ms later, the editor state had reverted.

So whatever was eating the middle paragraphs, it was doing it after the fill returned. The agent's "success" signal was lying.

## Second diagnosis (wrong): markdown auto-conversion

Hashnode's editor does auto-format certain characters at the start of a line: `>` becomes blockquote, `**` becomes bold, `[` opens a link helper, `#` becomes heading.

I noticed the body had several paragraphs starting with these characters. So I theorized: the editor was rejecting paragraphs whose first characters tripped auto-format prompts, leaving them empty until the user manually accepted.

Fix: I escaped the leading characters with a zero-width space. Re-ran. Result: **still 446 chars saved.**

So that wasn't it either.

## Third diagnosis (wrong): React reconciliation order

Hashnode's editor wraps ProseMirror in a React component. I suspected that the multiple `beforeinput` events I was dispatching were getting batched and only the first + last applied.

I switched from `beforeinput` to `composing` text events with intermediate `setTimeout(0)` calls to give React's render cycle a chance to flush.

Still 446 chars.

At this point I was four hours in and getting irrationally angry at a contenteditable div.

## The real bug

I read the Safari MCP fill pipeline. For ProseMirror editors, it walks the DOM looking for `.pmViewDesc`, if found dispatches via view.dispatch. If not found, walks React Fiber for memoizedProps.view. If still not found, **falls through to char-by-char `beforeinput` + `execCommand('insertText')` per line.**

Path 4 is the fallback for editors that don't expose ProseMirror's internals. It's worked everywhere I'd tested it. Including Hashnode in earlier dev.

But it has one assumption baked in: **that the editor will accept the text it's told to insert.** If the editor rejects an insert silently — for any reason — the fill pipeline never finds out. The function returns success. The DOM has empty paragraphs.

Hashnode's ProseMirror configuration has an "input rules" plugin that runs on every paragraph start. The plugin's job is to handle markdown shortcuts. But its implementation aborts the insert if the matched text doesn't form a valid command — and just doesn't insert anything.

So a blockquote-prefixed line doesn't become a blockquote. It also doesn't become a regular paragraph. It becomes nothing.

The fill pipeline is char-by-char per line. It walks down, fires beforeinput, fires execCommand. The input rule fires on each markdown-shortcut character, kills the line silently. Pipeline moves to next line. Same thing.

Only paragraphs whose first character doesn't trip a rule survive. In my article, that was paragraph 1 and the final paragraph.

## The fix

The fix is straightforward once you see it: after the char-by-char fill, verify the editor's textContent length. If less than 60% of what you sent landed, clear the editor via DOM removal and re-fill via `execCommand('insertHTML', false, paragraphWrappedHtml)`. `insertHTML` bypasses the input-rules plugin because the rules only fire on character-level input events. A bulk HTML insert is treated as a paste and goes through a different code path — one that doesn't run the markdown-shortcut interceptor.

Verify-after-fill is the part that took me too long to add. Trust the framework to tell you what happened, not the call that just returned.

This shipped in [v2.10.4](https://github.com/achiya-automation/safari-mcp/releases/tag/v2.10.4) of Safari MCP.

## The lesson

The deeper issue isn't ProseMirror. It's the assumption that **a successful tool call means the action succeeded.**

Browser automation has a recurring failure mode: the framework keeps its own state separately from the DOM, and the framework's state is what gets submitted on form post. Your synthetic events change one or the other, sometimes both, sometimes neither. The DOM looks right. The submit ships the wrong thing.

I added a tool called `safari_verify_state` in v2.10.0 specifically for this. It checks framework state (ProseMirror view, Lexical editor state, React `_valueTracker` desync, Closure component values) and returns whether the framework agrees with the DOM. The Hashnode ProseMirror case is now a built-in check.

If you're building any agent that touches a serious editor — Quill, ProseMirror, Lexical, Slate, Tiptap — assume the fill happened, then **verify what landed before you click Submit.** The 5 ms it takes is the cheapest insurance you'll buy this year.

## Postscript

I cross-posted this article using the fixed code path. It saved as 41 intact paragraphs.

The agent didn't notice anything was different. That's the point.

---

[Safari MCP](https://github.com/achiya-automation/safari-mcp) is open source (MIT) and runs on macOS. It's used by Claude Code, Cursor, and other MCP clients to drive a real, logged-in Safari instead of spinning up a headless Chromium.

I was eating dinner when my AI agent ate my tabs.

I had Safari open with a Chatwoot Meta dashboard in one tab and an n8n executions view in another — both with unsaved state, both in the middle of real work. In a third tab, my own tab, my agent was supposed to be testing a new feature in the MCP server I maintain (Safari MCP).

I came back to the laptop and both real-work tabs had been navigated to URLs the agent picked.The Chatwoot tab was now showing some test page. The n8n tab was on a Reddit comment thread the agent had been debugging an unrelated module against.

The agent hadn't gone rogue. The MCP server had a state-tracking bug — and instead of failing loudly, it had silently fallen back to "use whatever tab the user is on."

This is a postmortem. The fix took three releases — v2.10.0, v2.10.1, and v2.10.3 — and the iteration is the interesting part.

The shape of the bug

Safari MCP exposes a safari_new_tab(url) tool. Internally, it tracks "the tab MCP owns" via a tab index (_activeTabIndex) — Safari's positional handle — and a DOM marker (window.__mcpTabMarker) — injected JS that lets future calls verify "yes, this is still our tab."

Every subsequent safari_navigate, safari_click, safari_fill etc. resolves "where to act" by: (1) check marker in current tab, (2) else check _activeTabIndex still valid, (3) else fall back to "front document of front window".

That last branch is the catastrophe. "Front document of front window" is, by definition, whatever the user is looking at right now.

So why did the fallback fire? Three different reasons, across three releases.

v2.10.0 — the original failure mode

The original safari_new_tab(url) did exactly what its name said: open a new tab and navigate it to url in one call. If navigate(idx, url) fails to load — file:// blocked by Safari, network error, an app:// scheme that Safari doesn't understand — the new tab stays at about:blank. The marker injection runs, but then the next user-driven navigation in any tab can wipe it. By the time the next safari_navigate arrives, our marker check fails. The "front document" fallback fires. We navigate the user's current tab.

I shipped this. I tested it on a clean Safari with one window. I never hit the bug because in clean state, the user's tab is my tab.

v2.10.1 — the grace window (almost-fix)

The first fix was a NEW_TAB_GRACE_MS = 30000 window. For 30 seconds after safari_new_tab, ANY mutating operation that would fall back to the user's tab now throws a clear error. Plus a fix for the marker wipe — safari_navigate now re-injects window.__mcpTabMarker after every successful navigation.

This passed all my tests. It also worked correctly for ~95% of real sessions.

The 5% it missed: sessions longer than 30 seconds where the tab-ghost recovery path nullified _activeTabIndex mid-session.

v2.10.3 — the permanent guard

runJS (the workhorse for every JS-driven tool) has a tab-ghost recovery path. If a JavaScript evaluate fails because the tab Safari thinks is at index N has been closed/replaced, runJS nullifies _activeTabIndex so the next call resolves cleanly. The intent: avoid using a stale index after Safari shuffles tabs.

The unintended consequence: 30+ minutes into a session, after a routine ghost-recovery, _activeTabIndex is null. The grace window from v2.10.1 has long expired. The marker check fails. Fallback fires. User's current tab gets clobbered.

The bug pattern: a "safe" recovery path created the exact failure mode the grace window was designed to prevent.

The permanent fix is a sticky session-scoped flag (_hasOwnedTab) that's set the first time safari_new_tab succeeds, and never resets for the lifetime of the MCP process. Four entry points — _assertNotFallingBackToUserTab (used by navigate and navigateAndRead), runJS's tab-ghost fallback path, and runJSLarge — all call this assertion before falling back to the user's current tab. If the assertion throws, the agent gets a clear error pointing back at safari_new_tab. The user's tab is untouched.

What I'd take away if I were writing my own MCP server

1. The fallback you don't notice is the fallback that bites. "Use the user's current tab" looks like a reasonable degraded mode in isolation. In context — an autonomous agent acting on the user's real, logged-in browser — it's the worst possible default. The fix wasn't "make the fallback work better." It was "the fallback should not exist in this branch of the state machine."

2. State-tracking bugs aren't subtle. They're catastrophic. A misidentified tab is a misidentified action. The class of bug here — I think I'm acting on X but I'm actually acting on Y — is the same class as a deployment script targeting prod instead of staging, or a Git rebase rewriting the wrong branch. There's no "minor version" of this bug.

3. "Sticky" flags beat "windowed" flags for invariants you actually need. The v2.10.1 grace window was time-bounded. But sessions are unbounded. Anything that can happen during the session can happen after the grace window expires. If the property "MCP has owned a tab in this session" is the actual thing protecting the user, that property must hold for the whole session — not 30 seconds.4. Tests on clean state miss the bugs that matter. I tested v2.10.0 on a fresh Safari with no other tabs. The user-tab-clobber bug is invisible in that environment because the user's tab and MCP's tab are the same tab. Real users have eight tabs open and were just clicking around in tab six. If your tool drives a user's real browser, your test environment must have unrelated, in-progress tabs.

5. Errors are a feature. The replacement for "silent fallback to user tab" is a thrown error with a remediation message: "Call safari_new_tab to re-establish." That error is better than the original happy path — because the original happy path was sometimes a disaster. A loud, fixable error is always better than a quiet, irreversible mistake.

The diff that mattered

The load-bearing change is one line of state plus a guarded fallback function: a sticky boolean _hasOwnedTab that flips true on the first successful safari_new_tab and gates the fallback to the user's current tab. That's the load-bearing part. Everything else in v2.10.3 is plumbing.If you're building an MCP server (or any tool that drives a user's real browser/editor/database), the question I'd ask in code review is: "What's the worst thing this fallback can do, and does the fallback's existence buy enough to be worth that worst case?" For tab fallback in Safari MCP, the answer was: no, it doesn't.

Source: github.com/achiya-automation/safari-mcp
Install: npx safari-mcp
Releases discussed: v2.10.0, v2.10.1, v2.10.3

Have you shipped a state-tracking bug that ate user data? What was the failure mode, and what flag/invariant ended up being the real fix?

So I built Safari MCP — a native macOS browser automation server that uses AppleScript instead of Chrome DevTools Protocol. Zero overhead, keeps logins, runs silently in the background.

The Problem: Chrome Is Heavy

Every Chrome-based automation tool (Puppeteer, Playwright, Chrome DevTools MCP) spawns a separate browser process. On Apple Silicon:

• Chrome: 400-800MB RAM, constant CPU spikes
• Safari: Already running, 0 additional overhead

The Architecture: AppleScript + JavaScript Bridge

Safari MCP uses a dual-engine approach:

Engine 1: Safari Extension (~5-20ms per command) — HTTP polling bridge with full DOM access.

Engine 2: AppleScript + Swift daemon (~5ms per command) — compiled Swift helper for screenshots, file dialogs, clipboard.

80 Tools, Zero Configuration

Navigation, interaction, reading, forms, storage, network monitoring — 80 tools that work transparently with both engines.

The Hardest Bug: React Controlled Inputs

React uses _valueTracker on inputs. The fix: set the tracker value, then set new value and dispatch input events. Works for React, Vue, Angular, and vanilla JS.

Results

• CPU dropped 40-60% on Apple Silicon
• Fan noise eliminated
• 80 tools vs Chrome DevTools MCP 30
• Running automation for 50+ business clients

npx safari-mcp

GitHub | npm

I am Achiya Cohen, an automation engineer based in Israel. I build WhatsApp bots, workflow automation, and AI tools for businesses. Let us talk.

What is the heaviest tool in your AI development stack? For me it was Chrome — what is yours?

I searched the MCP server registry. There are at least 13 browser automation servers listed. Every single one requires Chromium — Chrome DevTools Protocol, Puppeteer, Playwright with Chromium, or some wrapper around them.

On my MacBook, that meant a second browser process burning CPU while Safari sat right there with all my sessions already loaded.

## The Problem With Chrome-Based MCP Servers

Chrome with a debug port open idles at 8–15% CPU on an M2 MacBook Pro. During active automation it spikes to 25–40%. Chrome alone was consuming 200–400MB of RAM before a single page loaded.

Meanwhile, Safari was already open with all my logins — Gmail, GitHub, AWS console, client dashboards. I was running two browsers so my AI agent could interact with web pages.

## Safari MCP: The Native Alternative

I built [Safari MCP](https://github.com/achiya-automation/safari-mcp) — 80 tools for native Safari browser automation via AppleScript + a Swift daemon.

**Key differences:**

| | Safari MCP | Chrome DevTools MCP | Playwright MCP |

|---|---|---|---|

| Your existing logins | Yes | Yes | No |

| CPU overhead | Minimal (native WebKit) | High (Chrome process) | Medium |

| Dependencies | None | Chrome + debug port | Playwright runtime |

| Tool count | 80 | ~30 | ~25 |

## What Changed When I Switched

The fans stopped. Safari MCP uses about 30MB of memory. Idle CPU at 0.1%. During active automation it bumps to 2–5%.

I stopped re-authenticating. The agent uses my real Safari with all existing sessions.

Safari stopped stealing my focus. Every command targets a specific tab by index.

## Getting Started

```bash

npm install safari-mcp

```

Add to your MCP config:

```json

{

"mcpServers": {

"safari": {

"command": "npx",

"args": ["safari-mcp"]

}

}

}

```

Works with Claude Code, Cursor, Windsurf, Claude Desktop, VS Code + Continue. MIT licensed.

**GitHub:** [github.com/achiya-automation/safari-mcp](https://github.com/achiya-automation/safari-mcp)

---

*What's your CPU temperature when Chrome DevTools MCP runs alongside your IDE? I'm curious whether others have noticed the same overhead, or if it's a non-issue for most workflows.*