What can you build with Claude’s new computer use that people will pay for?

What changed with Claude computer use recently?

Claude computer use has crossed an important threshold: developers can now build production agents that combine screen control, browser structure, company procedures and persistent files in the same workflow.

Anthropic recently made Computer Use, the Skills API and the Files API generally available on the Claude Platform. The more interesting addition for most business workflows is Browser Use. Claude can inspect the structure of a webpage and target a particular field or button instead of relying entirely on screenshot coordinates.

That sounds like a technical detail, but it removes a common source of failure. Early computer agents often worked by taking a screenshot, deciding where to click, performing one action and starting the loop again. A small layout change could move the target by a few pixels. The newer system can also batch several actions into a single turn, reducing the number of model round trips.

Anthropic has now pushed the same idea into the consumer product. Claude in Chrome recently became generally available across paid Claude plans and can navigate tabs, type, click and fill forms using an existing browser session. Claude can even perform many browser actions without asking for approval each time, while Anthropic runs a safety classifier around those actions.

Two changes are happening together. Computer control itself is getting better, while Anthropic is packaging the surrounding pieces needed to turn that control into repeatable workflows.

That makes a much larger class of back-office software worth looking at today.

Is Claude computer use actually reliable enough to sell today?

Claude computer use is reliable enough today for narrow workflows with clear checks and human fallbacks, while fully autonomous high-consequence work is still a bad bet.

Anthropic’s own computer benchmark shows how far the models have moved. Claude Sonnet 5 reached 81.2% on OSWorld-Verified under Anthropic’s updated evaluation setup, compared with 78.5% for Sonnet 4.6. Opus 4.8 reached 83.4%. OSWorld tests agents on hundreds of tasks inside real computer environments rather than asking models to describe what they would do.

An 81% benchmark score obviously cannot be translated into “81% of customer workflows succeed.” A carefully designed insurance submission or freight-status workflow is far narrower than OSWorld. It can include fixed instructions, validation rules, retries and escalation. Still, the benchmark shows that general computer operation has become much less fragile.

The stronger evidence comes from Asteroid, which runs computer-use automation inside healthcare systems. Asteroid says its computer-use volume grew eightfold within five months as it expanded from EHR charting and claims processing into appointment scheduling.

When Asteroid tested Anthropic’s newer interaction loop on four production-style workflows, model calls fell 32% to 52% and cost per task fell 25% to 32%. Completion reached 100% across all four tests, compared with results as low as 77% on the older setup. Its claim-intake workflow also became 59% faster.

We should treat those numbers as one company’s production tests rather than a universal benchmark. But they answer the commercial question much better than another flashy browser demo would. A team already operating computer agents at scale measured a substantial improvement in cost, speed and completion without having to invent an entirely different workflow.

Claude computer use has reached the point where we can sell completed work, provided the product knows when to hand an exception to a person.

Why can Claude computer use automate work that RPA still misses?

Claude computer use can now reach the messy workflows that companies often left manual because traditional RPA was too brittle or too expensive to maintain.

There is already overwhelming evidence that businesses pay for software operating other software. UiPath finished its latest fiscal year with $1.61 billion in revenue and $1.85 billion in annual recurring revenue. Its ARR has since passed $1.9 billion. Microsoft currently charges $150 per month for a Power Automate Process bot running unattended RPA and $215 for a Microsoft-hosted version.

Traditional RPA works extremely well when the process is predictable. A script knows which element to select, which field receives which value and what comes next. The economics become less attractive when a portal changes its layout, documents arrive in five different formats or the next action depends on what appeared on the screen.

Claude can reason through more of those variations. The computer-use layer can interpret a visual interface, while Browser Use can interact with structured web elements. APIs can still handle the parts where APIs exist.

The combination is more useful than forcing one technology onto the whole workflow. A good product might read an invoice with a document model, pull vendor information through an API, operate a supplier portal through Browser Use, fall back to visual computer control inside a legacy desktop application, then ask a person to approve an unusual discrepancy.

That opens the long tail of automation: processes valuable enough to consume human labor every week, but previously too awkward to justify a custom integration.

Would anyone pay for a general-purpose Claude computer agent now?

A general-purpose Claude computer agent is a weak startup idea now because Anthropic, OpenAI, Google and browser infrastructure companies are quickly turning computer control into a standard capability.

Anthropic itself is the most immediate problem. Claude in Chrome can already read pages, move across tabs, fill forms and take browser actions for every paid Claude user. Cowork pushes Claude further into computer-based work. A startup selling “Claude, but it can click around your browser” would be packaging something increasingly close to the underlying product.

The competitive picture is getting even tighter. OpenAI’s GPT-5.5 supports computer use through its API. Google’s current computer-use documentation recommends Gemini 3.8 Flash for high-accuracy UI interaction across browser, mobile and desktop environments. Gemini also includes configurable safety controls and prompt-injection detection for computer-use workflows.

Specialized infrastructure is becoming cheap as well. TinyFish currently prices its agent execution at $0.016 per step and its browser infrastructure at $0.002 per minute. Browserbase, Browser Use and other companies are competing to make reliable web execution something developers can plug into their own products.

The market can still support horizontal enterprise automation platforms. UiPath proves that. Those companies sell governance, orchestration, integrations, monitoring and enterprise deployment rather than a clever browser demo.

A new startup needs a much clearer promise. “Every shipment updated automatically” has economic meaning. “An AI that can use your browser” increasingly just describes infrastructure.

Which Claude computer-use jobs are actually worth selling?

The best paid Claude computer-use jobs are repetitive workflows that cross several systems, happen frequently and finish with an outcome the customer can easily check.

Frequency separates products from demos. Saving somebody fifteen minutes once a month creates very little willingness to pay. Removing two hours of portal work every working day is a different proposition.

The ownership of the software matters too. External portals are especially attractive because the customer cannot simply ask its engineering team to improve the API. An insurance agency has no control over twenty carrier websites. A freight forwarder cannot force every shipping line to use the same booking interface. A distributor selling to large retailers may have to work inside whatever procurement portal each retailer chose.

We also want a clean boundary between clerical execution and judgment. Claude can collect a shipment status, download a POD and update the TMS. A human can decide how to respond to a major delay. Claude can prepare an insurance submission across carrier portals. The broker still chooses where to place the risk. Claude can enter an invoice. Someone else can approve a large payment.

The most attractive workflows also generate a simple operational metric. How many submissions were completed? How many shipments were updated? How many purchase orders were acknowledged? How many exceptions required a person?

Once the customer can count completed units of work, pricing becomes much easier.

Does insurance prove people will pay for computer-use agents?

Insurance currently gives us the clearest proof that companies will pay for agents that perform real work across portals, documents and old software.

A recent Applied Systems survey of 702 independent insurance agents found that 74% named re-keying risk data across carrier portals as their biggest submission pain point. Commercial submission automation was the most requested carrier capability at 79%. Even more strikingly, 90% said they had reduced business with a carrier because of submission friction.

Those are unusually strong numbers because the problem affects revenue, not merely employee convenience. If a carrier makes submissions painful enough, brokers place business elsewhere.

The workflow also repeats at enormous scale. The latest US Bureau of Labor Statistics occupational data counts about 214,000 insurance claims and policy-processing clerks, with median pay around $49,000. That represents more than $10 billion in direct annual wages before we include benefits, supervisors, underwriters and outsourced insurance operations.

We can also see actual AI companies converting the pain into production volume. Pace says insurers used its agents to complete more than 250,000 critical workflows during roughly its first year. Prudential uses Pace across customer-acquisition operations, while Palomar says 90% of its policy-servicing tasks are resolved without customer-service headcount rising at the same rate. Pace subsequently raised a $46 million Series B led by Thrive Capital and Sequoia.

Applied Systems is moving in the same direction from the incumbent side. It recently launched an agentic email-to-quote product that turns unstructured broker emails into carrier-ready submissions and can return a quote, decline or referral without somebody manually re-entering the intake.

Insurance passes three different tests at once: the labor pool is large, customers explicitly complain about the exact workflow and real companies are already processing hundreds of thousands of tasks.

The downside is equally clear. We would no longer be entering an undiscovered market.

What insurance workflow could a new Claude computer-use startup still own?

A new Claude computer-use startup could still own carrier submission and renewal operations for smaller independent insurance agencies, especially where staff repeatedly enter the same account into several carrier portals.

The workflow is painfully specific. An agency already has most of the insured’s information inside an agency-management system, old policies, PDFs, spreadsheets and email. An employee then gathers missing information, chooses the relevant carriers, enters much of the same risk data several times, uploads attachments, checks statuses, retrieves quotes and records the result back in the agency system.

That is exactly where Applied Systems found the strongest frustration.

The startup should keep underwriting judgment outside the initial product. We would automate information collection, portal entry, document retrieval, status checks and renewal preparation. Anything involving an unusual coverage decision, ambiguous answer or final placement can appear in an exception queue for the broker.

Loss-run retrieval is another good wedge. Employees routinely visit carrier portals or send requests simply to obtain a document that another workflow needs. Policy-document retrieval and renewal-data gathering have similar characteristics.

Starting there keeps the product close to clerical execution. It also gives the company a chance to accumulate the thing that becomes valuable later: detailed knowledge of how hundreds of insurance portals behave, where each field lives, which documents each carrier expects and which situations require intervention.

Insurance can support very high contract values. It will also demand stronger security, integrations and domain knowledge than most of the alternatives we examined.

Is freight a better Claude computer-use startup than insurance?

Freight looks like the better first market for many new teams because the workflows are frequent, messy and valuable without carrying the same regulatory burden as insurance or healthcare.

The US currently has roughly 100,000 cargo and freight agent jobs, with median annual pay around $52,000. The Bureau of Labor Statistics expects employment in the occupation to grow 6% through 2035. That gives us a labor pool above $5 billion per year before dispatchers, overseas operations teams and managers enter the calculation.

More importantly, a freight employee often acts as the integration layer between software systems. A rate confirmation arrives by email. Somebody reads the PDF, builds the load in a TMS, checks information against the customer request, coordinates with a carrier, monitors shipment status, retrieves the POD and updates the TMS again.

Current products show how naturally agents fit the process. Shipflow now advertises operators across quotation, booking, documents, tenders, track-and-trace, invoice processing and exception management. The company says its system already handles millions of transactions per month and connects directly to email, TMS products, ERPs and carrier portals.

Champ uses browser agents to pull statuses from carrier portals and write updates back to a TMS. Emulon combines document parsing, carrier calls, appointment scheduling and TMS synchronization, with browser control available when a portal lacks an API.

Three companies converging on almost the same workflow is useful evidence. Freight operators are already buying or testing software that performs the work rather than merely explaining what the operator should do next.

For a startup, we would narrow the first product much further: monitor every active shipment, retrieve missing delivery documents, update the TMS and escalate exceptions. The customer immediately understands the outcome, while the agent avoids decisions such as accepting a bad rate or committing to a costly operational change.

Once that workflow works, booking, document processing and carrier coordination become natural expansions.

Is supplier-portal automation an overlooked computer-use business?

Supplier and customer portals are one of the strongest under-discussed computer-use opportunities because employees spend hours operating software controlled by other companies.

A manufacturer may receive orders through several large customers’ procurement portals. Staff download purchase orders, compare them with ERP records, confirm quantities, acknowledge dates, upload shipping documents, respond to exceptions and later retrieve remittance information. The underlying transaction may already exist digitally at both companies, yet a person still moves the information between the two systems.

Browserbase now markets agent infrastructure directly around this problem. Its supply-chain product describes agents operating supplier portals, freight systems, ERPs and internal tools, including multi-vendor order processing, inventory synchronization and shipment tracking. That is useful evidence that infrastructure vendors are seeing enough demand to build industry-specific pages and tooling around the workflow.

The better startup opportunity sits one level higher than browser infrastructure. A distributor should be able to connect its ERP and its ten largest customer portals, then let the system collect new orders, compare them with inventory, prepare acknowledgements, upload approved documents and flag mismatches.

Customer concentration can make the economics surprisingly good. A wholesaler might have hundreds of buyers but receive most of its volume from a small number of large accounts, each with demanding portal procedures. Automating ten portals could therefore touch a large percentage of the company’s orders.

The same product can later work in reverse across supplier portals.

Compared with generic browser automation, the customer is buying a much clearer outcome: fewer people spending their day copying orders between systems.

Is legacy accounts payable still worth building for?

Legacy accounts payable is worth entering only through a narrow software or industry wedge because generic invoice automation is already crowded.

The raw labor pool looks enormous. The United States still has about 1.53 million bookkeeping, accounting and auditing clerks, with median annual pay of $50,670. That is roughly $78 billion in direct wages. The Bureau of Labor Statistics expects the occupation to shrink 6% through 2035 and explicitly attributes part of that decline to software automating routine work.

That last point changes our interpretation of the market. Accounts payable has been under automation pressure for years. Bill, Ramp, Tipalti, Stampli and a long list of ERP vendors already read invoices, route approvals and synchronize accounting data.

Computer use becomes interesting in the stubborn parts those products do not handle cleanly. An employee may still need to enter approved information into QuickBooks Desktop, Sage 100, an old Dynamics installation or another application with limited integration options. Staff also visit vendor portals to download invoices, investigate mismatches or retrieve supporting documents.

A focused product could therefore target one environment rather than selling another broad “AI AP employee.” Something like invoice entry and reconciliation for distributors running Sage 100 gives the startup a finite set of screens, exceptions and accounting procedures to master.

We would keep payment approval firmly outside the autonomous workflow. Invoice retrieval and data entry can absorb plenty of labor without asking a new product to move company money on day one.

Should you build Claude computer-use agents for healthcare?

Healthcare has huge computer-use economics, but Claude computer use currently has a tougher compliance constraint than a quick reading of Anthropic’s HIPAA-ready offering might suggest.

The operational fit is excellent. Hospitals and clinics still rely heavily on EHRs, payer portals, Citrix environments and other interfaces originally designed for people. Asteroid says its agents already work across EHR charting, claims and scheduling. One of its current workflows spends around eight minutes inside an EHR while extracting clinical and demographic information across more than 85,000 patients.

Asteroid now expects to automate roughly 10 million healthcare tasks over the coming twelve months, many involving computer use. That is one of the strongest production-scale signals we found anywhere in this market.

The compliance situation requires more care. Anthropic offers HIPAA-ready API and Enterprise configurations under a Business Associate Agreement, but its current documentation explicitly lists Computer Use as excluded from BAA coverage. Files API and Skills API are also excluded in the HIPAA-ready API configuration. Cowork is excluded as well.

That distinction makes a direct “Claude computer-use agent for protected health information” harder to deploy through Anthropic’s standard covered configuration today. Healthcare automation companies can still build their own compliant execution architecture or use computer-control approaches outside that particular Anthropic feature, which helps explain why companies such as Asteroid can operate in the sector.

The market remains extremely attractive. The immediate path is simply more complicated than freight or supplier portals.

A team that already understands healthcare security, enterprise procurement and EHR deployment should absolutely investigate it. For a small team trying to reach its first paying customers quickly, we would choose an easier environment.

Which Claude computer-use ideas look better than they really are?

Generic assistants, single-app automations and low-frequency portal work are the easiest Claude computer-use ideas to overestimate.

Consumer shopping, arbitrary form filling and “do anything in my browser” products look impressive in demonstrations. Claude in Chrome already covers a growing share of those jobs, while Google and OpenAI are building comparable computer-control capabilities. It becomes difficult to explain why somebody should maintain another subscription.

Single-application automation has a different problem. If most of the workflow happens inside one modern SaaS product, the incumbent can usually automate it with cleaner access to its own data and actions. Property-management software is a good example. Platforms such as AppFolio and Buildium are already adding AI automation inside their products. A startup whose entire pitch is operating those interfaces from the outside sits in a vulnerable position.

Permits and government portals are more interesting technically because APIs are often poor, but frequency can kill the economics. A restaurant submitting one license renewal occasionally will not pay much for automation. A permit expediter, large contractor, property operator or franchise network processing hundreds of filings is a much better customer.

Software testing is real too, but computer use alone gives little differentiation. Playwright, coding agents and specialist AI-testing companies already automate large parts of browser testing.

The same thing keeps showing up. Computer use becomes more valuable when several systems have to be crossed, the workflow runs constantly and no single software vendor can absorb the whole process.

How much can a Claude computer-use product charge?

A Claude computer-use product can support serious pricing once it removes dozens of hours of monthly work; saving a few scattered clicks leaves very little room for a meaningful subscription.

The labor data across the strongest markets is remarkably consistent. Insurance-processing clerks earn around $24 per hour at the median, bookkeeping clerks about $24 and cargo or freight agents around $25. Benefits, management overhead and office costs make the employer’s real cost higher, but using $25 per hour gives us a conservative baseline.

Suppose a workflow removes 80 hours of manual work each month. At $25 per hour, that is $2,000 of direct wage value. A $500 monthly product still gives the customer four dollars of direct wage savings for each dollar spent before we count faster processing, fewer errors or avoided hiring.

The same calculation explains why tiny automations struggle. Ten hours saved per month are worth only about $250 in direct labor. Even a very good product has limited pricing power there.

The most interesting contracts appear when the software absorbs enough workload to postpone an additional operations hire. A $50,000 employee costs roughly $4,170 per month in salary alone. A product priced around $1,000 to $1,500 can become an easy decision if the customer genuinely avoids that hire.

Usage-based pricing can work too. Insurance submissions, shipments, purchase orders and invoices are all countable units. The customer can compare the price per completed workflow with the human time previously required.

Human work removed each month	Direct wage value at $25/hour	Example price with strong customer ROI
10 hours	$250	~$50–$80/month
20 hours	$500	~$100–$165/month
40 hours	$1,000	~$200–$330/month
80 hours	$2,000	~$400–$665/month
160 hours	$4,000	~$800–$1,330/month
One ~$50K employee	~$4,170/month	~$1,000–$1,500/month

What becomes the moat when every model can use a computer?

The moat will come from workflow depth, exception data and distribution because Claude itself is already surrounded by capable computer-use alternatives.

Google’s current computer-use stack has already moved beyond the Gemini 3.5 generation discussed only recently: Google now recommends Gemini 3.8 Flash for computer-use workloads. OpenAI exposes computer use through GPT-5.5. Browser infrastructure companies are pushing execution costs down at the same time.

A startup should therefore assume it will switch or combine models over time. Claude might handle one workflow better, Gemini another, while deterministic code handles most easy actions without calling either model.

The proprietary asset accumulates above that layer.

After 100,000 freight workflows, for example, the company knows which carrier portal hides a POD under an unexpected reference, which TMS produces duplicate records under a particular sequence, which customer wants status codes mapped differently and which exception actually requires an operator.

Historical executions also become an evaluation set. Every model upgrade can be replayed against real cases before going live. A competitor with access to the same Claude API does not automatically receive those cases, recovery strategies or accuracy measurements.

Distribution becomes stronger once the product owns the work queue. If tasks arrive automatically from email or the TMS, run through the system, escalate there and leave a complete history there, replacing the product becomes more disruptive than swapping one chatbot for another.

The technical architecture should follow the same logic. Use APIs for deterministic actions, browser structure where available and visual computer control where the interface leaves no cleaner option. Expensive model reasoning should be concentrated on ambiguous steps and exceptions.

Over time, customers should care less about which model clicks the button. They will care about the percentage of jobs completed correctly without their team touching them.

What should you build with Claude computer use right now?

Build a vertical back-office operator: freight or supplier portals offer the best startup wedges today, while insurance gives us the strongest evidence that companies will pay serious money for this kind of automation.

Freight would be our first choice for a new company. The labor pool is large, workflows run all day, employees jump constantly between email, documents, TMS products and carrier systems, and current vendors are already showing that companies want AI to execute the work. A narrow first product could keep every shipment status current, retrieve missing documents and synchronize the TMS while sending exceptions to an operator.

Supplier and customer portals come next. The basic problem appears across manufacturing, distribution and wholesale: two companies already have digital systems, yet an employee still copies transactions between them because their software does not communicate. Computer use finally makes many of those integrations economical.

Insurance is probably worth more per customer. The recent Applied Systems survey gives us unusually strong evidence that portal re-entry affects where brokers place business, while Pace has already processed more than a quarter-million insurance workflows. Competition, security requirements and domain complexity make it a harder first market.

Legacy AP also works when narrowed to an old ERP or underserved industry. Healthcare could eventually be larger than all of them, but the deployment and compliance burden is currently much heavier, including Anthropic’s present exclusion of Computer Use from its BAA-covered API features.

We would stay away from generic browser assistants. The underlying capability is becoming commodity infrastructure remarkably fast.

The product should promise one completed unit of work rather than access to an agent: every shipment updated, every carrier submission prepared, every customer PO acknowledged or every approved invoice entered. Customers can count those outcomes, compare them with labor costs and decide quickly whether the product deserves a budget.

Opportunity	First workflow we would sell	Willingness to pay	Startup difficulty	Our view now
Freight operations	Track shipments, collect PODs, update TMS, escalate exceptions	High	Medium	Best first wedge
Supplier/customer portals	Pull POs, prepare acknowledgements, sync ERP records	High	Medium	Excellent overlooked wedge
Insurance operations	Prepare submissions, renewals and carrier-portal work	Very high	High	Strongest proof of demand
Legacy AP	Enter and reconcile invoices in one legacy ecosystem	High	Medium-high	Good when very narrow
Healthcare administration	EHR, claims and scheduling execution	Very high	Very high	Huge, but harder right now
High-volume permits	File forms and monitor government portals	Medium-high	Medium	Good niche at sufficient volume
Generic computer assistant	Arbitrary browser and desktop actions	Weak differentiation	Low	Avoid