Smart Local↔Cloud Routing for Sensitive Text

The local-vs-cloud privacy debate usually gets framed as a choice: either keep everything on your machine (private but limited) or send everything to the cloud (powerful but exposed). Smart routing dissolves that trade-off by making the decision per-edit instead of once-for-everything. Here’s how it works and why it’s the most practical privacy model for people who edit all day.

The problem routing solves

Most of what you do to text all day is trivial: fix a typo, tighten a sentence, adjust tone, change “I think we should” to “we should.” A small local model handles all of that perfectly well — and keeps it entirely on your machine.

A minority of edits are genuinely hard: restructure three paragraphs, translate with real nuance, reason over a long passage. Those benefit from a frontier cloud model.

Sending everything to the cloud over-exposes the 90% of edits that didn’t need to leave your machine. Keeping everything local under-powers the 10% that needed the big model. Routing fixes both: the right model for each edit, chosen automatically.

How the routing decision is made

A smart router weighs a few signals to decide where an edit goes:

• Sensitivity. Is the text flagged, classified, or from a sensitive app/context? Sensitive → local (or block the cloud entirely).
• Difficulty. Is this a quick fix or a complex rewrite? Quick → local; complex → consider cloud.
• Length. Short selections suit local models; very long ones may need cloud capacity.
• Your rules. The best version lets you set the policy — e.g. “never send anything from my code editor to the cloud,” or “always ask before any cloud call.”

The privacy-preserving default is local-first: try the local model, and only escalate to the cloud when the task clearly needs it — with your permission, never silently.

Why “with permission” is the whole point

Routing is only a privacy feature if you stay in control of the boundary. Silent escalation — a tool quietly shipping your “sensitive” text to the cloud because it decided the edit was hard — is worse than no routing at all, because you think you’re protected. A trustworthy router:

• Defaults to local for anything sensitive.
• Asks (or respects a pre-set rule) before any cloud call on flagged text.
• Tells you where each edit ran, so there’s no ambiguity about what left your machine.

Control of the boundary is what separates real routing from a black box.

The practical payoff

With routing done right, you get:

• Privacy where it matters — the bulk of your edits never leave your machine.
• Power where you need it — the hard rewrites still get the best model.
• Lower cost — you only pay for cloud tokens on the edits that actually used the cloud (see the BYOK math).
• Offline resilience — quick edits keep working with no network at all.

It’s the architecture that lets a single tool serve both a privacy-bound lawyer and a marketer who wants the best possible rewrite — without compromising either.

Routing and EditSnappy

Smart local↔cloud routing is on EditSnappy’s privacy roadmap as the natural home for its core users — people who can’t send everything to a server but still want the best model when it’s safe to use one. It is listed as a reach goal, not a confirmed shipping feature:

[[MISSING: confirm whether EditSnappy ships local↔cloud routing (and the local model it requires). master-sales-copy §5 lists “smart local↔cloud routing” explicitly as a reach goal — do not assert it ships until Ken confirms.]] [[MISSING: pricing model — routing depends on a local/BYOK path existing, which is tied to the pricing decision (master-sales-copy §8 option B).]]

What EditSnappy commits to today gives you control regardless of where an edit runs: no logging or retention of your text, a diff shown before any change commits, and one-key undo. You always see the result before it touches your document — the most direct form of “stay in control of the boundary.”

Explore the full trust stack on the Privacy, Security & BYOK hub, or try EditSnappy free — no credit card.