Pluno - Browser agent that’s 10x faster than Claude
by•
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.
Replies
Pluno
@chirag_pareta Thanks a lot! The main speed advantage is that Pluno does not click through the UI like a human. It learns the app’s API logic and executes that directly. Reasoning and execution scale separately, so we can add capacity as usage grows.
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!
looking forward to it, drop the link here when it's out. would help a lot of people on the fence decide
Mailwarm
How do you add support for a new web app, do you rely on OpenAPI style specs ?
Pluno
@thamibenjelloun Great question!
It's mostly that the agent figures it out directly by checking how the UI / browser communicates with the web app's server. So it can be API, RPC, websocket, etc. - the agent tries to understand it and remembers for future interactions :)
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!
Skipping the UI and going straight to the API feels like the real shift here - not just a speed improvement, but a completely different way of getting work done.
Curious how you handle actions that aren’t easily reversible though. Is there some kind of confirmation or preview layer, or does it just execute once the intent is clear?
Either way, this is a really interesting direction - congrats on the launch!
Pluno
@jared_salois Thanks and great question!
As a safety layer, we do have it prompted to ask for confirmation for critical irreversible actions. Would love to hear your feedback when you get the chance to try it on a couple of tasks!
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 👀)
viral.app
This is sick! We are already automating everything in our workflows with Codex, but this looks like a super efficient addition to save on tokens. Congrats on the launch!!
Pluno
@mikes_producthunt Makes sense. Are you using the Chrome connector for Chrome?
How exactly did you compare it with Claude? I need to benchmark my AI against all the popular models.
Pluno
@natalia_iankovych We did it all in-house. We are planning to open-source it in the future.
Awesome idea excited to try it out and use my own benchmarks. I've found large tasks eat up token limits on Claude relatively quickly
Pluno
@ryanbutz Yes faster in this case also means less tokens used. Let me know how it performs on your benchmarks Ryan!
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