Pluno
10x faster than Claude in Browser
425 followers
10x faster than Claude in Browser
425 followers
Pluno just killed Claude in the browser. It’s 10x faster, and completes your tasks instantly in the background. No clicking around the UI like a drunk intern. Prompt less, and get more done. Learns instantly and uses every web app like a pro. Tested and outperformed Claude in 500+ web apps.
This is the 4th launch from Pluno. View more
Pluno
Launched this week
Pluno just killed Claude in the browser. Claude clicks around the UI like a drunk intern - instead, Pluno talks directly to the API to act 10x faster, with 10x fewer tokens. Learns new tools instantly and uses every web app like a pro. Tested and outperformed Claude in 500+ web apps. Claude clicks - Pluno gets it done. Launch day: get $50 in free credits.
Free Options
Launch Team / Built With
Pluno
Hey makers!
Here’s what Claude & other browser agents got wrong:
They use software like humans.
They wait for pages.
They stare at screenshots.
They click buttons.
They get stuck in dropdowns.
You’ve probably seen this - impressive for a demo, painful when you actually need work done.
So we built Pluno.
Pluno skips the UI entirely and talks directly to the APIs underneath your web apps. You tell it the outcome, and it gets the task done in the background.
No clicks.
No dropdowns.
No babysitting.
Just: Done ✅
You can use Pluno as a browser extension to update records, extract data, fill forms, run bulk actions, create dashboards, and handle annoying SaaS tasks that normally eat up your day.
We benchmarked Pluno across 312 real-world tasks in 24 tools (incl. HubSpot, Notion, Stripe, Linear), and the results speak for themselves: 34% higher success rate than Claude’s browser extension, at ~14x the speed.
Why we’ve built it? Because we loved the idea of Claude’s browser extension, but in reality it was way too slow to be useful.
For founders, operators, and tiny teams doing the work of ten people:
This one is for you 💜
What I’d love to know: Which browser task would you use to test Pluno’s limits?
P.S. Get 50$ in free credits, today only.
@syed_ali319 Seems interesting, will it be able to bypass CAPTCHAs?
Pluno
Hi @chatabhishek - it can't bypass CAPTCHAs currently.
But it will use your user session, so you can login once and then let Pluno handle the tasks inside.
Which use case did you have in mind where you need the CAPTCHA bypass?
@korbinian_abstreiter Many websites ask users to complete a CAPTCHA before filling out a form. Common examples include appointment booking and job applications.
Pluno
@chatabhishek totally makes sense, thanks for sharing!
Would love to hear your feedback how it's working for you :)
the API-first approach makes sense for speed but I'm skeptical of the 10x number without knowing the benchmark setup. every web app has a different amount of custom JS and auth flow behind it, so "learns instantly and uses every web app like a pro" is doing a lot of work in that sentence. what happens on a site that doesn't expose a clean API path and you're stuck reverse engineering internal requests, does it fall back to clicking then?
Pluno
@omri_ben_shoham1 Yes, you're right. It falls back to clicking for unclean API paths. However, in our experience, that's quite rare these days. And once it has gone through the clicking flow once, it will have learned the API paths.
Would love to hear your experience of trying Claude with Chrome vs Pluno side by side.
@koalabs fair enough, haven't run them head to head yet. if you've got a public benchmark writeup with the actual sites tested i'd read it, that would settle it faster than my anecdotes
Pluno
@omri_ben_shoham1 Sure, we'll publish the full report soon!
For browser agents, speed only matters if the failure state is inspectable. The handoff should leave behind what it clicked, what it inferred, where it got stuck, and what still needs human approval; otherwise a fast agent just creates faster uncertainty.
Pluno
@krekeltronics That's right. A browser agent should not disappear after a failed run. The durable output is the audit trail: actions, assumptions, blockers, and approvals needed.
The human-in-the-loop feedback cycle only works efficiently if the browser agents acts fast enough, the results are presented well and the AI learns quickly from the feedback
The talk-to-the-API-directly bet is the right one for speed, but the wall we keep hitting is that a lot of modern web apps don't expose a callable API in any stable sense. The one I automate safelists its persisted GraphQL queries and 500s anything that isn't on the list, so we're forced back to driving real DOM clicks. How does Pluno handle apps where the underlying calls are signed per-session or the operation set is locked to a safelist?
Pluno
Hey @dipankar_sarkar - Korbi here, technical co-founder of Pluno.
Amazing question, that's exactly why existing browser agents fail on such apps.
Instead, Pluno checks the code of the UI to understand how it makes requests to the server.
Whichever way it is, Pluno learns this functionality and starts communicating to the backend the same way the UI does.
Happy to go deeper on anything you'd like to know!
That makes sense for apps where the request-building lives in readable bundle code. Where I'd expect it to get hairy is when the signing isn't static, like a token minted at call-time inside a web worker or a wasm blob, so you can't lift the recipe once and replay it. Do you keep the page's own JS context alive per session to mint each call, or pull the logic out ahead of time?
Pluno
@dipankar_sarkar great insight - and also a problem we stumbled on and had to fix!
The key thing is that the UI has to be able to make those same requests too, and the agent can do anything the UI can do. So instead of treating the API call as something fully separate from the app, the agent can handle those cases by learning the execution path the UI already uses. If the request needs a fresh token, signature, worker roundtrip, or WASM call at runtime, we keep that logic in the loop and execute the same code path programmatically.
So yes, JS context is being kept alive. (We're exploring how far we could go by working around it 👀)
The "skip the UI, talk directly to the APIs underneath, reuse my logged-in session" approach is what makes the speed claim believable — screenshot-clicking was always the bottleneck. Where does that execution actually happen: does the agent run locally in the extension, or does my authenticated session/token get relayed to Pluno's backend to make those API calls? And how does it map each app's private/internal API — reverse-engineered per tool, or something more general that adapts on first run?
Pluno
@noctis06 The execution happens locally in the extension. We have pre trained it on hundreds of apps’ APIs, and if it encounters a new API, it learns it by exploring it naturally. Since many APIs follow similar patterns, it picks them up very quickly.
@koalabs Local execution plus a pretrained API library makes the speed claim land better than a screenshot-clicking agent would. When it hits a new app and learns the API by exploring, does that learned map persist locally and get reused on my next session, or is it re-derived each time — and is the map per-device, or pooled across users so someone else's exploration speeds up mine?
Pluno
@noctis06 Love your thoughts. It is pooled, so everyone helps everyone else move faster
Is Pluno mainly focused on faster prompting and responses, or does the workflow automation / AI agents side mean it can also take actions across tools?
Pluno
@crystalmei great question! Pluno can take actions across tools, e.g. you could export attendee data from a conference website and directly have them imported into Salesforce.
What use case do you have in mind for taking actions across tools?