Maho vs Safari: defaults are sticky, agentic is not optional

Sep 11, 2026

Maho Team

Safari is good. Safari is fast. Safari is, on a fresh Mac, already the browser. Those three sentences are most of the reason this comparison even has to exist. The default browser on macOS does not have to be the best browser. It has to be present. Presence is the moat.

Maho is built for the same machine, but for a different decade of browsing. The web in 2026 is not the web Safari was designed against in 2003 or even 2018. Tabs are heavier. Context windows have replaced bookmarks for a lot of people. Browser-driven agents do real work. The shape of “what a browser is for” has shifted, and the default has not shifted with it.

This post is the comparison. We are honest about where Safari wins, because it does. We are clear about where we are placing different bets.

Maho and Safari on the same Mac

The default-tax argument

There is a tax most users pay without noticing it. It is the cost of using whatever the operating system put in the dock. On macOS, that thing is Safari. The tax is small, per session: a few seconds of friction, a slightly worse fit for some workflow, an AI feature that was not built for your tabs. Per session it is invisible. Over years, it adds up to a browsing experience shaped entirely by Apple’s release cadence and product priorities.

The default tax is not unique to browsers. Email clients, photo managers, calendar apps, all carry it. The reason it matters more for the browser is that the browser is where you spend most of your screen time. A small fit problem in your photo app costs you minutes a year. A small fit problem in your browser costs you minutes a day.

We are not making the case that you should swap on principle. We are making the case that you should test whether the default is still the best fit for what you actually do online.

Where Safari is still better

Safari has real advantages and pretending otherwise would be a marketing exercise. The honest list:

Battery life. Apple controls the kernel, the GPU drivers, the JavaScript engine, and the energy accounting. On a MacBook running on battery, Safari still pulls less power than any third-party browser, and the gap is not small. If your number-one priority is hours of unplugged use, Safari wins.
Continuity integration. Handoff to iPhone, Universal Clipboard, AirDrop of links to other Apple devices, Apple Pay at checkout. These are tied to Safari at the system level. Other browsers can approximate, but they cannot match.
iCloud Keychain. If you are already deep in Apple’s password ecosystem, Safari is the most natural client for it.
First-party WebKit. Some sites are tested only in Safari, and a subset of those sites only ever feel right in Safari. The set is shrinking, but it is non-zero.
System-wide reading list and tab groups. They are not the most powerful version of those features that has ever shipped, but they are the version that follows you across every device you own.

If those five points describe your situation, Safari is the right answer. There is no AI feature that beats four extra hours of battery on a long flight if a long flight is the use case.

Where Maho is built for the next era

The bets we are making are not about replacing Safari at what Safari is good at. They are about being good at things Safari was not designed for.

Agentic by default. The browser can read the page you are on, the tab next door, the conversation in the side panel, and turn that into actions. Not “open a chat window and paste your question”. The chat is part of the browser, and so are the tools the chat can use.
BYOK at the wiring level. You bring the API key. You pick the model. You pay the provider. We are not the middleman. Safari’s AI features route through a vendor stack and the route is not configurable.
Local model support. If you have an M-series Mac, you have an inference engine in your laptop. We can target it. A bundled architecture cannot.
Sync without an account. Pairing-based, end-to-end encrypted, no email required. The relay sees ciphertext. We talk about this in detail in the sync architecture overview (sidebar) and the dedicated post on the relay model.
Spaces. A workspace primitive that sits above tab groups: per-space history, per-space cookies, per-space AI context. Closer to how a working session actually feels than a flat tab strip.

These choices are not improvements on Safari’s roadmap. They are different roadmaps.

Where the default tax shows up

Sync model comparison

| Aspect | Safari (iCloud) | Maho | |---|---|---| | Account required | Yes, an Apple ID | No, pairing-based | | Encryption | Advanced Data Protection optional, off by default | End-to-end, on by default | | Server can read content | Yes, unless ADP is enabled | No, ever | | Recovery on total device loss | Apple ID recovery | Recovery key only | | Cross-platform | Apple devices only | Any device that can run Maho | | Web-based access | iCloud.com | Not available |

Two different shapes of the same feature. Apple’s model trades transparency to the vendor for a recovery story that does not require you to keep a key. Our model trades the recovery convenience for a relay that genuinely cannot read your data. Neither is wrong. They are answering different questions.

AI integration comparison

| Aspect | Safari + Apple Intelligence | Maho | |---|---|---| | Model choice | Vendor-bundled | BYOK, any provider | | Local model support | Limited, on-device summaries only | Full, any local server | | Page context to model | Selection or short summary | Whole page, multi-tab, Space-scoped | | Tool use in the browser | None | Native, including MCP servers | | Cost model | Bundled into hardware | You pay the provider directly | | Provider transparency | Opaque routing | You pick the endpoint |

The Apple Intelligence story is improving. It is also constrained by the choice to ship a single bundled model with a single bundled router. That choice has product-level consequences. The agentic flows that depend on heterogeneous tools and configurable models are not flows you can build inside that constraint.

For the architecture behind our side of this table, see the browser AI overview. For a broader landscape view, see the comparison hub.

Sync and AI comparison summary

Pick guide

This is the short, honest version. Use it as a starting point.

Pick Safari if:

You spend most of your time on battery, far from a charger.
You live in the Apple ecosystem and use Continuity features daily.
You do not care about agentic browsing today, and you do not expect to next year.
“Just works with my iPhone” is a higher value than “configurable model stack”.
iCloud Keychain is your password manager and you are not changing that.

Pick Maho if:

The browser is your primary work environment and small fit problems compound.
You want to use your own API keys, or run models on your own hardware.
You want sync without handing your browsing history to a vendor.
Your work involves multi-tab research, agentic tool use, or both.
You are willing to trade a bit of battery life for a much bigger AI surface.

There is also a third position: keep both. Safari for the on-the-go, low-power, ecosystem-tight cases. Maho for the focused work session at a desk. We are not going to argue against that. A lot of our internal team uses both for exactly this reason.

Join the waitlist

We are not yet open to everyone. The browser is in private testing while we tune the parts that interact with the rest of the system, particularly the AI panel and the sync relay. If the picture above is closer to your needs than the default, the waitlist is the way in.

Join the waitlist and we will reach out as slots open. There is no account to create. There is no card to attach. The only thing we ask for is the email we should send the access link to, and we will send exactly one email per access event. The default tax is real, and the way you get out from under it is to try a different default, even briefly. The waitlist is the door.