Nope, you can also deploy and manage your own browsers as soon as they accept custom extensions.
209 karma · joined July 12, 2012
Regarding the local file issue: currently, caching keys are based on a Browserbase session. This means that with a purely local browser, the cache option has no effect, and there’s nothing to verify. Each call returns metadata (including status, miss reason, threshold, count, and tokens saved) so you can observe churn rather than make guesses about it.
More details here: https://www.stagehand.dev/evals
Every action performed requires a round trip between your script and the browser (short when running locally but increased when running in the cloud). We also saw multiple posts complaining about the eager token appetite of Playwright MCP.
For this reason, we rebuilt Stagehand from the ground up and shipped v4, where Stagehand controls the browser from an extension automatically loaded upon your browser startup.
Stagehand v4 comes with batch command support, dedicated token-efficient methods `act()` and `extract()`, and a brand new architecture making it 2x faster than Playwright and 80% more token efficient.
You can see for yourself by looking at our benchmarks, comparing its performance across a dozen models (frontier and open weights) and tools (Codex, Claude Code, and more): https://www.stagehand.dev/evals
Ask me anything!
I'm planning to try to make terminal STDIO work as a "human in the loop" pattern or even better as an "Agent in the loop" one.
2. All sensitive data (tokens, env vars) are encrypted on our side, however, we don't prevent users to print their values in the logs yet - it's planned in our next releases.
We aim to provide a similar feature set as Sidekiq (throttling, unique jobs) but with a complete hosted solution.
While Defer and Temporal can both be used for writing background jobs, workflows, and CRONs, there are some core design differences.
Temporal has been created as the Kubernetes of highly distributed systems, enabling developers to write code that runs on multiple regions without worrying about possible termination of the program and interruption of workflows spanning across multiple steps.
While Temporal can be used for background jobs, workflows, and CRONs, its main goal is to ensure that highly distributed tasks will reliably be executed. That's the main reason why Temporal API is so verbose, with many concepts to deal with.
Defer, on the other hand, provides comparable reliability while focusing on the developer experience.
You can write workflows, CRONs, and jobs that run for hours without worrying about them being terminated.
All this, with a simple API that enables you to write some workflows (background functions calling other background functions) in plain TypeScript, with no mental model to fit in.
For our users concerned about data locality, we recommend pushing the minimal data as arguments (ex: ids or external ids) and fetching the data during the execution on our side, if needed, through a dedicated SSH tunneling setup. Once an execution is done, its associated isolated container - gets a dedicated VPC and disk - gets destroyed permanently. We will also provide on-premises solutions for Enterprises.
In local environment (dev), background functions run completely synchronously and locally, no call is made to Defer.
When a background function gets a call from your application, the `defer()` wrapper intercepts this call and pushes an execution to the Defer API with the function’s name and serialized arguments.
I hope it makes thinks clearer, let me know!
[update: grammar]
We address privacy by encrypting all the data on our side (doing a second pass with a symmetric PGP key for tokens such as GH tokens, and environment variables) and advise companies that want to keep their data on their infra to push as minimum data in arguments while leveraging a dedicated SSH tunneling setup between our infra and theirs.
When it comes to the SLA/up-time of home grown, my POV would be that, again, achieving good results on those often requires SRE engineers, which is an investment.
We got our first customers from both channels: network (sales) and inbound (twitter discussions, etc). I agree that top-down is not working well for a newcomers but getting better at a later stage.
Node.js, with the flexibility of the JavaScript language, allowed the rise of great abstraction and other domain-oriented API designs, a bit like Ruby on Rails did with Ruby.
The arrival of React.js Server Components pattern enabled the isomorphic pattern (first applied to mobile and front-end apps) to reach the server side of things with patterns such as Server side rendering, popularized by frameworks like Next.js or Remix.
Those new patterns and abstractions allow Node.js developers to move faster while building more complex applications to match users’ requirements: real-time, performant apps, richly integrated with third-party products.
Beyond code, those new coding habits came with new products such as Vercel or Supabase that help them to get the infrastructure done in no time, without any DevOps knowledge (good article on this topic: https://vercel.com/blog/framework-defined-infrastructure).
“modern development standards”, applied to Node.js, do not only apply to coding experience and productivity (ex: the rise of monorepos, TypeScript, SSR) but also to enabling developers to configure their infrastructure from the code.
[update: typo]
As @thdxr mentioned, our goal is also to provide top-notch queueing/scheduling features that are complicated to achieve with Lambda/SQS/Cloud Functions, such as dead letter queue support, throttling, or a product-oriented dashboard. In the same idea, we plan to provide better integration, for example, as you mentioned on secrets management by integrating with Doppler, AWS Secrets Manager, and more - the same goes with linked deployment pipelines.
Right now our Executions list is not ideal for such pattern but we will soon release filtering based on arguments which will help to get all the executions linked to a specific sequence.