Opera Neon turns browsing into doing with a local-first agent

The day the browser learned to do

On September 30, 2025, Opera launched Neon, a paid agentic browser that treats the web as a place to finish work, not just read answers. The proposition is direct. Neon costs 19.90 dollars per month and ships with three primitives that turn intent into action: Do, Tasks, and Cards. Do is the on-page operator. Tasks are repeatable jobs. Cards are portable memory and handoffs. This is not a chatbot parked in a sidebar. It is an on-device action loop designed to click, fill, compare, and submit while keeping your data on your machine. Early details appeared in Reuters coverage of Opera Neon launch.

For a year, many teams have been betting on this direction. Neon makes the bet explicit with a price, a model, and a vocabulary that product leaders can adopt. It is also notable for what it does not do. It does not ask users to paste links and hope a cloud agent can infer the next step. It moves the agent into the tab where the work already lives.

From chat to execution

Think about the last time you tried to book a flight with points. You searched award space across a few carriers, logged in twice, checked seat maps, compared fees, and pasted confirmation numbers into your calendar. A chat agent can outline steps, but you still end up doing the clicking. Neon flips that script. You create a Task, state the goal, and let Do operate inside the page. It reads the form like a human, not via a private integration. It enters loyalty numbers, selects a window seat, and pauses for approval before purchase. Cards record each step and result so you can reuse, audit, or share the run later.

That flow matters because it compresses the distance between intent and outcome. The agent is not a separate app window that summarizes content. It is a set of verbs living where the work is. When the work is the web, verbs win.

The three primitives that matter

Neon’s primitives are designed to be both understandable and composable.

Do treats the browser as a controllable instrument, not a black box. It perceives the structure behind the pixels and applies rules that users can inspect.
Tasks package a multi-step flow into a reusable recipe. A team can standardize how to file expenses, reconcile invoices, or collect research with a single shareable artifact.
Cards capture state in small, portable chunks. Think of them as the browser’s build artifacts. A Card can hold a scraped receipt number, a submitted form ID, or a snapshot of the fields that produced a result.

Together, these primitives turn one successful run into something a colleague can repeat. That is the bridge from novelty to reliability.

Why local-first is a strategy, not a slogan

Local-first is often framed as a speed upgrade. It is also a trust and cost strategy.

Trust. If the agent perceives and acts locally, fewer keystrokes and page elements leave the device. That reduces the chance that sensitive content lands in third party processors or model training logs. For teams with strict data handling policies, this is a meaningful difference.
Security posture. Browsers are hostile environments. Hidden instructions or deceptive UI can trick agents that treat the screen as ground truth. A local-first design can pair on-device perception with explicit confirmation and granular site scopes. Recent reporting captured this risk surface in Ars Technica on agent risks.
Unit economics. Shifting perception and many decisions to the device reduces cloud inference minutes. That lets a product sustain a consumer-friendly price while reserving server resources for updates and genuinely hard jobs.

Local-first does not end the need for remote sandboxes or model refreshes. It does reframe the default, which helps both procurement and practice.

The new race around the tab

Neon is not alone. All summer, the category accelerated. Perplexity’s Comet pushed on-page action layered over a search agent. Anthropic’s Claude for Chrome put a research preview of computer use into Google’s browser with guardrails and confirmation dialogue. Dia, the successor to Arc from The Browser Company, aligned its narrative to enterprise work by emphasizing integrations with systems of record. The pattern is clear. The next browser is an agent surface. The competition is not who has the prettiest new tab page. It is who can finish a job without leaving the page.

What distinguishes Neon is the choice to charge a clear monthly price from day one and to “name the parts” so teams can reason about them. That shaping matters for adoption inside organizations that need shared language for design reviews, security questionnaires, and runbooks.

Why a 19.90 dollar subscription can work

A paid browser feels counterintuitive until you consider who buys it. Power users, contractors, and teams do not buy browsers. They buy throughput. If an agent saves one hour per month at a bill rate of 50 dollars, the math clears. If it saves an hour per week, the line item sits next to a calendar assistant or a research tool.

Pricing is also a segmentation tool. A paid tier filters for motivated testers who give higher fidelity feedback. It creates room for premium compute features without diluting the core. And it sets expectations that privacy is part of the value, not just a policy page.

Finally, local-first changes cost curves. If more work happens on the device, the vendor can share savings through a lower monthly fee compared to cloud-heavy agents. Server costs do not vanish. But the default moves in a consumer-friendly direction.

What local-first changes for enterprises

Enterprises reliably care about three things in this category: data control, auditability, and procurement friction.

Data control. On-device actions and perception simplify privacy impact assessments, especially for departments that handle sensitive data. Fewer subprocessors show up on vendor questionnaires.
Auditability. Cards and Tasks create a detailed trace of what the agent did, where, and why. That log is more practical than a generic model transcript because it is anchored to real elements on a page.
Procurement friction. A paid, clearly scoped agentic browser with local defaults can pass review faster than a general purpose cloud agent that sees everything. Teams will still ask about model updates, key handling, and whether the agent can post or purchase without two-person controls. But the story is easier to defend when default behavior keeps data local.

For leaders planning guardrails, we recommend pairing Neon-like agent loops with an enterprise security strategy that understands agent surfaces. Our report on agent-native security for enterprises outlines patterns like site scopes, verb gating, and explicit consent for high-risk actions.

Design the action loop, not just the chat

If you lead a product built around the browser, Neon’s launch forces clarity. Map verbs before models. Pick three to five on-page actions your agent will do reliably. For each verb, document the exact cues, fields, and failure modes.

A simple template:

Fill. Which fields can the agent complete? What validation rules exist? What markings indicate success?
Compare. What elements hold the values to compare? How should ties break? What is the tolerance for fuzzy matches?
Extract. Which DOM structures carry the target data? How do you anchor selectors across page updates?
Submit. What signals confirm a successful submit? What is the rollback path on failure?
Escalate. Which actions require a human check? How is that pause surfaced in the UI?

Run ten end-to-end jobs with users. Track three metrics: time to completion, number of confirmations, and number of corrections. Ship changes that cut confirmations by half without increasing risk.

For teams standardizing execution, we have seen strong results when a product team publishes a minimal internal library of Tasks and Cards, then invites frontline operators to suggest changes. That keeps the loop tight and avoids a sprawling marketplace too early.

Choose integration surfaces with intent

Surface area is a trade-off. The more places an agent touches, the more you must defend.

Essential surfaces for an agentic browser:

Sidecar panel for context and controls that persist across tabs.
Inline highlights to reveal elements the agent plans to touch before it acts.
Command palette for verbs with typed parameters when necessary.
Bridges to clipboard, file system, and calendar with explicit prompts and logs.

For each surface, write the abuse cases. What happens if a page injects hidden text under an off-screen element? How does the system block it? How do you show the user what the agent will do before it acts? Our look at open rails for agent commerce discusses how policy-level rails shape safe execution without smothering speed.

Build or buy the agentic runtime

You can build your own execution runtime, or assemble one from a platform.

Build. Write the page controller, memory store, and action dispatcher. You own security and the upgrade path. If your differentiation is a unique way to act inside complex software, treat the runtime as core intellectual property.
Adopt. Use a browser platform or library that exposes action primitives. You ship faster, but you accept their update cadence and roadmap. If your differentiation is domain logic, this can be the right path.

Regardless of approach, plan for a monthly cadence of Chromium merges with budget reserved for security updates. And write formal evaluations that mirror production tasks, not toy benchmarks. The production shift for agents highlights why production-minded evaluation beats synthetic scores.

Security and consent are product features

Action agents must earn trust with clear intent and reversible steps. Four controls are non-negotiable:

Site-level permissions. Agents should only act on domains that users approve, with scopes a human can read.
High-risk action gates. Purchases, posts, deletes, and transfers require explicit confirmation with the precise objects named.
Input sanitization and isolation. Treat page text as untrusted input. Sanitize it. Isolate model prompts from direct injection.
Human-in-the-loop pauses. For steps with financial or reputational impact, pauses should be the default, not an afterthought.

Neon’s local-first stance can help here, but design details determine outcomes. The more transparent the plan and the preview, the more users will let the agent act without hovering over every step.

Pricing math and the enterprise story

At 19.90 dollars per month, Neon walks a useful line. It is inexpensive enough for individuals and small teams to try without procurement, yet serious enough to support continued development and support. The price also amplifies a message: a browser funded by users optimizes for completion, not for page views. If completion is the product, the roadmap favors better Do over lateral features that increase dwell time.

For enterprise champions, this simplifies the internal pitch. Local-first reduces data flow. On-device perception trims risk. Named primitives enable training and standardization. A price that fits departmental budgets means pilots can start now, not after a quarter of legal back-and-forth.

What to watch next

The market will answer a few questions over the next two quarters:

Reliability at depth. How well does Do perform on complex, dynamic single page apps that obfuscate structure? What is the error rate on long forms with conditional logic?
Template ecosystems. Do Tasks and Cards gain a marketplace with verified automations? If so, who certifies them and how are risks contained?
Platform responses. Expect native action APIs from Chrome, Edge, and Safari, along with stronger defenses from sensitive sites. Standards for agent permissions will emerge. The winners will integrate early without fragmenting their own experience.
Procurement proof. Which compliance packages and deployment options does a local-first browser need to pass enterprise review efficiently? Device management, signed builds, and pinned model versions will rise in priority.

What startup builders should do now

If Neon is your wake-up call, here is a practical plan for the next 90 days:

Pick one killer job. Choose a job your target users do weekly that currently spans three to five tabs. Design an end-to-end Task with Do and Cards that completes it.
Instrument for outcomes. Measure time saved, confirmations required, corrections, and rollback rate. Publish these metrics to users and iterate openly.
Harden your loop. Add site scopes, verb gates, and previews for every destructive action. Write regression tests that attempt prompt injection via hidden elements and off-screen text.
Decide build versus adopt. If your power is domain expertise, adopt an execution scaffold. If your power is novel control of the browser, invest in the runtime.
Ship a trust story. Make security and consent visible. Show the plan before the action. Offer a log that a manager can read without translation.

The shift to doing is now visible

Neon did not invent the agentic browser. It did pin the concept to a date, a price, and a set of primitives that anyone can learn. That matters. It gives buyers a vocabulary and a direction. Local-first by default. Action loops instead of chat. Named parts you can reason about and build on.

The race will not be won by the first team to stuff a large model into a sidebar. It will be won by the teams that make the browser a reliable place to finish work. When you can point at a page, say do this, and watch the right fields fill with the right values, the web has crossed a line. On the other side of that line, answers are not the point. Outcomes are.

For operators, the message is simple. Watch the verbs. For founders, the call is clear. Build the loop. For enterprises, the upside is practical. Turn the browser from a place where work starts into a place where work ends.