Think about how much of your day happens inside a browser. Your email. Your project board. Your docs. Your CRM. Your bank. The tools your company runs on. The research. The shopping. The reading. For most people, the browser stopped being “the thing you use to look at websites” a long time ago. It quietly became the place work happens.
And yet the browser itself barely changed. It is still, at its core, a window you look through. A passive viewport. It renders whatever a website hands it and then gets out of the way. It does not understand what you are doing. It cannot help. It cannot reshape a page that is badly designed. It cannot remember that these eight tabs are the “Acme client” project and those six are “Q3 planning.” It cannot run a task for you while you sleep. After thirty years, the most important application on your computer is still essentially dumb.
That is the gap Moxby closes. Moxby is a real, full Chromium browser, with everything you expect and nothing you have to relearn, but it treats the web as something to be operated, organized, and rebuilt, not just displayed. It is the browser that finally works for you instead of merely working. Your browser was a window, we made it a workspace. This is Browser 2.0, and the rest of this piece is a tour of exactly what that means and, more importantly, why each piece exists.
Everything is a tab: the web, your docs, your code, your tasks
Start with the foundation, because everything else is built on it. In a normal browser, a tab can only ever be one thing: a web page. That is the whole vocabulary. If you want a document, you leave for a different app. If you want a task board, a different app. A terminal, a different app. Your AI assistant, yet another app or window. Your work is scattered across a dozen programs that know nothing about each other, and you spend an absurd amount of your day just switching between them and rebuilding context every time.
Moxby expands what a tab can be. In Moxby, a tab can be a web page, the full Chromium experience, real and fast. But a tab can also be a document you are writing. Or a task board. Or a running app on localhost. Or a code file. Or a conversation with the AI. They are all first-class tabs, living in the same strip, switchable with the same muscle memory you already have.
Why does this matter so much? Because the cost of modern knowledge work is not the work. It is the switching. Every time you alt-tab from your browser to your doc app to your task tool, you pay a tax: you lose your place, you lose your train of thought, you rebuild context. When all of those things are tabs in one surface, that tax disappears. Your client’s website, the proposal you are writing for them, the task list for their project, and the AI helping you with all of it are inches apart, not apps apart. The work becomes one continuous motion instead of a constant scramble across disconnected programs.
And this is not a flimsy web-app imitation of a browser. Underneath, it is genuine Chromium, the same engine that powers the world’s most-used browser. Your sites render exactly as they should. Your logins work. Your extensions-era habits carry over. It is engineered to load instantly and stay lean even with dozens of tabs open, so the power does not come at the cost of the snappiness you expect from a browser. You get the full, real web, plus everything else.
The omni bar and the command center: one place to start anything
If a tab can be anything, you need one obvious place to start anything. That is the omni bar: the address bar, reimagined as a command center.
In a normal browser the address bar does two things: it goes to a URL, or it searches the web. Useful, but narrow. Moxby’s omni bar is the front door to your entire workspace. Type a web address and you go there. Type a search and you search. But also: start a new chat with the AI. Jump to a document. Open a task board. Find a tab you already have open somewhere in the chaos. Launch a workflow. Run a command. The same single bar, one keystroke away, is how you reach everything, not just the web.
The new-tab page follows the same idea. Instead of a grid of bookmark thumbnails and a search box, a dead end that only knows how to send you to another website, a new tab in Moxby is a launch point for any kind of work. It is the difference between “where do I want to browse?” and “what do I want to do?”
The why here is about reducing the distance between an intention and an action. The longer the path from “I need to do X” to actually doing X, the more friction, the more lost ideas, the more “I’ll get to it later.” A command center that can start anything from one keystroke means the path is always short. You think it, you type it, it happens.
Tab groups and chat folders: organize work by client, project, or topic
Here is a problem every heavy browser user knows intimately: tab chaos. You start the day clean. By noon you have forty tabs and no idea which ones belong to which thing. The Acme proposal, the personal research, the bug you were chasing, the article you meant to read, all jumbled into one undifferentiated strip of tiny favicons. The browser gives you no way to say “these belong together.”
Moxby brings real organization to this in two connected ways.
First, tab groups. You can gather related tabs into a named, collapsible group, the full Chromium tab-group experience. “Acme client” is one group. “Q3 planning” is another. “Personal” is a third. Collapse the ones you are not using, expand the one you are. Your forty-tab mess becomes three tidy, labeled clusters of work. The mental model finally matches the screen.
Second, and this is the part that does not exist anywhere else, you can organize your chats into folders, and then open an entire folder as a tab group. Think about what that unlocks. Every conversation you have with the AI can be filed: a folder for each client, each topic, each ongoing initiative. When you sit down to work on Acme, you do not hunt through a flat list of conversations and reopen tabs one by one. You open the Acme folder, and its whole set of chats springs open as a labeled tab group, ready to go. Your work is organized the way your brain organizes it, by who and what, not by a single chronological pile.
This is the moment the browser stops being a place you visit and becomes a place you live and work. Your context, meaning the pages, the conversations, and the tools for a given piece of work, can be summoned and dismissed as a unit. Switching from one client to another is no longer a fifteen-tab reconstruction project. It is one click. Open the folder; the world for that work appears. Close it; it tucks away. You can finally hold many parallel streams of work without each one bleeding into the others.
The why is cognitive load. Disorganized tools force you to keep the structure of your work in your head. Organized tools hold that structure for you, so your attention goes to the work itself instead of the bookkeeping of finding it. Chat folders that open as tab groups are organization that matches how real work is actually shaped: in projects, clients, and topics, not in one endless scroll.
Split view: see the cause and the effect at the same time
Because everything is a tab, any two (or more) tabs can sit side by side. This sounds minor. It is not. It changes the entire rhythm of work.
Put a client’s website on the left and the proposal you are writing about it on the right. Put a reference doc next to the task you are completing. Put a conversation with the AI beside the document it is helping you draft, and watch the changes land as you talk. Put a research article next to your notes. Whatever two things you need to see together, instead of flipping back and forth and holding one in fragile short-term memory, you simply place together.
The reason this matters is that an enormous amount of knowledge work is reference work: you are looking at one thing while producing another. A normal browser makes that a tab-flipping endurance test, and every flip risks losing the detail you were about to transcribe. Split view turns “look, remember, switch, type, forget, switch back” into “look and type.” Cause and effect, source and output, in view at once. Combined with tab groups, you are not just organizing your work; you are arranging it spatially to match the task in front of you.
Action buttons: the browser that knows what site you are on, and what you might want to do
A normal browser treats every website the same: it renders the page and stops. It has no idea you are looking at a GitHub repository, or a product you might want to research, or a form you fill out every week. It cannot offer to help, because it does not understand context.
Moxby does. When you land on a site, Moxby can surface contextual action buttons: one-click actions that make sense for this page. The clearest example: you are looking at a GitHub repository, and a button offers to import it. One click, and that repo becomes a real, working project inside Moxby, cloned, opened, indexed, and ready, with an AI already standing by to help you work on it. No copying the clone URL, no terminal, no setup ritual. The browser recognized what you were looking at and offered the obvious next step.
That GitHub import is one instance of a broader idea: the browser as an active participant that understands the page you are on and offers the relevant move, instead of a passive frame that makes you do all the connecting yourself. The web is full of moments where the next step is obvious to a human and invisible to a normal browser. Moxby closes that gap.
The why is leverage. Every manual connecting step you perform, whether copying this, pasting it there, opening this other tool, or setting it up, is friction that adds up across a day into real lost time and lost momentum. A browser that recognizes context and offers the action collapses those multi-step chores into single clicks, and keeps you in flow.
Mods: stop wishing a website worked differently, and make it
Every single day you hit a website that is almost right. The dashboard that shows everything except the one number you actually care about. The tool that makes you click four times for something that should be one. The page that is missing a button you wish existed. Normally, you have exactly two options: live with it, or send a feature request into a void and wait forever. The website is a thing that happens to you.
Mods flip that completely. A Mod is a small custom mini-app you (or rather, Moxby on your behalf) build that runs on top of a real website and changes how it works. It can add new buttons and overlays directly onto the live page. It can compute and display the information the site left out. It can wire the site’s own internal capabilities to a single click. It binds to the sites you choose, whether one site or a whole pattern of sites, and appears automatically whenever you are there.
And you do not write code to get one. You describe what you want, whether “add a column to this table that shows profit margin,” “put a one-click export button here,” or “surface the data this page hides three menus deep,” and Moxby builds it, injects it onto the live page, and lets you watch it take shape. If it is not quite right, you say so, and it adjusts. The website becomes clay.
Here is the clean way to hold the distinction: a browser plugin extends the browser. A Mod extends the web itself. It changes the actual sites you use into the versions of those sites you wish existed. For the first time, the websites you depend on every day are not fixed objects handed down to you; they are things you can shape to fit your own work.
The why is agency. The entire web is built on the assumption that the people who made each site decide how it works, and everyone else simply accepts it. Mods break that assumption. The tools you spend hours in every day should bend to your workflow, not the other way around. Mods make that not just possible but easy: a sentence, not a software project.
Automations: teach Moxby a task once, then stop doing it forever
So much of working on the web is the same handful of motions, over and over. The weekly report you assemble by visiting four sites and copying numbers. The data you pull every Monday. The cross-posting, the form-filling, the checking-and-updating that eats an hour you will never get back. You are a human being doing a machine’s job, because the machine never offered to do it.
Automations are how Moxby takes those jobs off your plate. They come in three flavors, and the distinction is worth understanding because each solves a different shape of problem.
Workflows are repeatable multi-step tasks on the web. You can teach one by simply doing the task once while Moxby watches, or by describing it. Moxby then generalizes what you showed it into a workflow it can replay on its own, on demand. A workflow can span a single site or hop across several: pull from one, transform, push to another. And because Moxby learns the intent of each step rather than memorizing brittle clicks, the workflow keeps working even when a site shifts its layout around. It heals itself instead of shattering.
Missions are bigger. A mission is a goal you hand Moxby to pursue over time, measured against a target you care about. Not a single task, but an ongoing objective that Moxby works toward across many runs, learning as it goes. It is the difference between “do this thing” and “keep moving this number in the right direction.”
Schedules put automations on a clock. Run this every morning. Pull that report every Monday at nine. Do this once, tomorrow, while you are asleep. The work happens whether or not you are there to kick it off.
And all of this runs in parallel. A scheduled workflow firing at dawn, a mission grinding away at a goal, and you working in your tabs right now are independent, and one never blocks another. Moxby is not a single assistant doing one thing at a time; it is a workspace where many streams of work run at once, including streams that run without you.
The why is the most fundamental one there is: your time is finite, and repetitive web work is a slow leak in it. Every task you teach Moxby once is a task you reclaim forever. The automation does not just save you the hour; it saves you the hour every week, indefinitely, and it does it without the maintenance burden that makes most automation not worth the trouble.
The Tasks module: real project management, built into the workspace
Work that matters needs to be tracked, and the usual answer is yet another separate app: one more login, one more place to check, one more thing disconnected from where the work actually happens. Moxby brings project management into the workspace as a first-class module, opened as a tab right next to everything else.
And it is not a toy checklist. This is full-strength task management: boards and lists and views; epics to group big bodies of work; sprints to plan in time-boxed cycles; subtasks to break a large item into its real pieces; recurring tasks for the things that come back every week or month; priorities, assignments, due dates, comments. Everything you would expect from a dedicated project tool, without leaving the place you do the work.
The payoff of having it inside the browser is connection. Your tasks live next to the websites, docs, and conversations they relate to. You can pull a task into a chat to give the AI context, or spin work the AI did into a task to track. The plan and the doing are no longer in two separate universes that you manually keep in sync; they are in the same workspace, aware of each other.
The why is that the gap between planning and doing is where work goes to die. When your task list is in one app and your actual work is in another, the list goes stale, the doing drifts from the plan, and you spend energy reconciling the two. Collapse them into one surface and the plan stays honest, because updating it is right there in the flow instead of a context-switch away.
Docs and the interactive web: writing that is connected to everything
Docs in Moxby are exactly what you would hope: a clean, capable writing surface for notes, proposals, plans, and knowledge bases, opened as a tab, organized however you like, ready to sit in split view beside whatever you are referencing. But there is one capability here that genuinely only makes sense in a browser-native workspace, and it is delightful.
Links inside your docs and tasks are alive. Hover over a link and you do not get a dead tooltip showing the URL; you get a live, interactive preview of the actual page, floating right there. A real, rendered peek at the website, not a screenshot, not a guess. You can glance at where a link goes, or even interact with it, without leaving your document and losing your place.
Think about how much of your writing references the web: a proposal citing a competitor’s page, a task pointing at a ticket, a doc linking out to research. Normally each of those links is a leap of faith and a context-switch: click, wait, look, come back, find your place again. When the link previews live and interactive on hover, the web you are writing about stays connected to the writing itself. Your documents stop being islands of text with dead pointers to elsewhere, and become living things woven into the web around them.
This is only possible because Moxby is a browser first. A normal document app cannot show you a live, interactive web page on hover, because it has no browser to do it with. Moxby does, because it is one. The docs and the web are not two separate worlds bolted together; they are the same world.
Shared docs and tasks: a workspace your whole team lives in
None of this is meant to be a solo experience. Docs and tasks in Moxby can be shared with your team, so the workspace is not just yours; it is a shared surface where work gets done together. A task board the whole team sees and updates. A doc multiple people contribute to. The plans, the writing, and the knowledge live in a place everyone can reach.
The why is that work is a team sport, and the moment your shared context is split across yet another set of disconnected collaboration tools, the seams start to show: things fall through cracks, versions diverge, people work from stale information. Putting the shared docs and shared tasks in the same browser-native workspace where the actual work happens keeps the team operating from one source of truth, in the same place they are already spending their day.
The Marketplace: expand the workspace, and share what you build
A workspace this open invites a question: what if the exact capability you need already exists, built by someone else? Or what if the thing you built would help thousands of other people? The Marketplace is the answer to both.
Through the Marketplace you can discover and install three kinds of building blocks. Plugins extend Moxby itself with new capabilities and surfaces. Mods, those mini-apps that upgrade websites, can be installed for the sites you use, so you benefit from a great upgrade someone else already made instead of building it yourself. And agent skills can be added to make Moxby instantly capable at new procedures, teaching it, in one install, how to do something it did not know how to do before.
Installing is safe and transparent: you see what a thing wants access to before you bring it in, so expanding your workspace never means handing over the keys blindly. And the Marketplace runs both directions: the Mod or skill you create can be shared and published for others. The clever upgrade you made to a tool your whole industry uses does not have to stay locked on your machine.
The why is compounding. A workspace you can extend, with a community extending it alongside you, gets more capable every single day, not just when the company that makes it ships an update. Every Mod, plugin, and skill anyone builds is a capability the whole ecosystem can gain. You are not buying a fixed product; you are joining a workspace that keeps growing, in directions its own users choose.
Why this is Browser 2.0
Step back and look at the whole picture. A real Chromium browser where everything, including web pages, docs, tasks, code, and conversations, is a tab. A command center that starts any kind of work from one keystroke. Tab groups and chat folders that organize your day by client and project instead of dumping it into one endless pile. Split view that lets you see source and output at once. Action buttons that recognize what you are looking at and offer the next step. Mods that let you reshape the websites you depend on. Automations that do the repetitive web work for you, on a schedule, in parallel, even while you sleep. A full task module with sprints and epics and recurring work. Docs whose links come alive on hover. Shared docs and tasks for the whole team. And a Marketplace that lets the whole thing grow without limit.
The thread running through every one of those is the same: the browser should not be a passive window you look through. It should be an active workspace that understands what you are doing and helps you do it: one that organizes your work, operates the web on your behalf, lets you rebuild the sites you use, and grows with you and your team over time.
For thirty years we accepted the dumb window because there was no alternative. Now there is. The browser grew up. Browser 2.0 is here, and it was built for the people who do not just use the web, but build on it.
