I agree that there is communication overhead between the agents, although so far it looks like they can communicate very effectively and efficiently. We’re also working on efficient ways to transfer more contextual information

we run headful browsers with a fingerprinting that is as stealth as possible and on top of that we can use your ip

anecdotally, making all requests originate from your own residential address has been a major success compared to other cloud-only solutions

it will be interesting to see how this will play out, having to “hide the agent” feels like a temporary work around until society accepts that agents actually do exist

the main issue with this interface is that the commands are too low-level and that there is no way of controlling the context over time

once a snapshot is added to the context those tokens will take up very precious context window space, leading to context rot, higher cost, and higher latency

that's why agents need to use very large models for these kind of systems to work and, unfortunately, even then they're very slow, expensive, and less reliable than using a purpose-made system

I wonder if a standardized interface will organically emerge over time. At the moment SKILL.md + CLI seem to be the most broadly adopted interface - even more than MCP maybe

I'd be curious to try and see if practically the difference is so little that it doesn't matter

1. it exposes low-level tools which make your agent interact directly with the browser which is extremely slow, VERY expensive, and less effective as the agent ends up dealing with UI mechanics instead of thinking about the higher-level goal/intents

2. it makes Claude operate the browser via screenshots and coordinates-based interaction, which does not work for tasks like data extraction where it needs to be able to attend to the whole page - the agent needs to repeatedly scroll and read one little screenshot at the time and it often misses critical context outside of the viewport. It also makes the task more difficult as the model has to figure out both what to do and how to do it, which means that you need to use larger models to make this paradigm actually work

3. because it uses your local browser, it also means that it has full access to your authenticated accounts by default which might not be ideal in a world where prompt-injections are only getting started

if you actively use the --chrome command we'd love to hear your experience!

you should be able to tell it to go to your localhost address and it should be able to navigate to your local app from the remote browser

let us know if you have any questions!

Agents that start using subagents rather than humans using the subagents directly

our current model is a subscription plan that determines the number of browsers available + credits top-ups for increased usage

there will be demand for AI-first online services as people continue to delegate more and more tasks to agents and this will drive implementation

For example, with remote browsers you get to give your swarm of agents unlimited and always-on browsers that they can use concurrently without being bottlenecked by your device resources

I think we tend to default to thinking in terms of one agent and one browser scenarios because we anthropomorphize them a lot, but really there is no ceiling to how parallel these workflows can become once you unlock autonomous behavior

We'll continue to make Smooth more affordable and accessible as this is a core principle of our work (https://www.smooth.sh/images/comparison.gif)