Can StageHand write scripts that can be rerun in the future without more OpenAI Calls?

[ConProgramming]

Use case is so that StageHand can run on a page just once, then I can keep scraping a page for latest data without more OpenAI calls.

[kamath]

Hey! Appreciate you making this an issue. Seeing a lot of people asking for this, so I'm glad to have a central source of discussion around this. Here are my thoughts:

Playwright is inherently not self-healing. It's vulnerable to minor DOM changes, which is a big reason we started developing Stagehand.

While Stagehand can be used to develop Playwright scripts with natural language scripts, you can use a plethora of tools to accomplish this, like Claude or even the Browserbase playground codegen. Stagehand is meant to be re-usable and resilient to the DOM changes that Playwright is vulnerable to, which is what we believe makes it the best SDK for AI web agents to turn natural language into repeatable Playwright actions.

If you want to see the generated Playwright actions, you can parse our logs to look for this log pattern that can easily be converted into Playwright logic.

We're also working on implementing caching (cc @navidkpr) that can cache Stagehand actions and results and re-implement them to avoid high token costs. As of now, we're limited to a local cache, but we're in active discussion about what it could look like to have a global cache for commonly repeated actions.

[navidkpr]

Yes, as @kamath mentioned we only support a local cache at this point. That being said, you can use local caching like this:

async function example() {
  const stagehand = new Stagehand({
    enableCaching: true,
  });

  await stagehand.init();
  await stagehand.page.goto("https://github.com/browserbase/stagehand");
  await stagehand.act({ action: "click on the contributors" });
  const contributor = await stagehand.extract({
    instruction: "extract the top contributor",
    schema: z.object({
      username: z.string(),
      url: z.string(),
    }),
  });
  console.log(`Our favorite contributor is ${contributor.username}`);
}

The cache will be created from the folder your script is being run from. So as long as you run scripts in that folder, you will have cache hits on the same action on the same page.

Hope this helps!

Also, it would be very helpful if you could in-depth describe your use case for the cache. So I can add it in the system if it's not fully covered right now

[ConProgramming]

Hey! This is good insight thanks.

My use case is scraping websites with tables of data. So the dom doesnt change, but the data in the dom does. Ideally, stagehand can generate cached code to get this data, then in future just rerun the cached code. And, if the cached code ever fails then stagehand can rerun to "self-heal".

I don't believe the current caching implementation can handle this?

[navidkpr]

I see.

Yes. Sadly this is not covered with the caching yet. I think this will be part of level 3 caching on Stagehand (we're currently at level 1)

[brig-pinkfish]

+1 - would be ideal if one of the outputs of a pass through was the PW code. so could be reused until it breaks. and then fire off another "learn" sequence at that time. also, b/c i'm betting that openAI call is going to fail much sooner than running PW against a relatively stable site.

Noting that i would expect to manage the "reuse until break" logic on my app side and not via stagehand.

[snoop244]

+1 - I don't know if this planned for, or is currently part of caching, but our use-case is not scraping but form filling. Our insurance broker client needs to enter between 50 to 80 fields of data into each of 20 or so insurer portals to get quotes and then, on purchase, handle the transaction. In my country, at least, insurance companies simply do not have APIs.

I would like to be able to feed an input schema with generic field names and values into stagehand and have it find the best-fit field on the page and enter the data. When it is successful, it remembers the success in some persistent store. When it struggles or fails it works to figure it out and then fails with an explicit method that we can address by hand. The ability for some level of self-healing on changes to the page/dom would also be amazing.

While an input schema is crucial, the output schema is less usefull for our use-case, but I get the value for sure.

I saw a note somewhere on your roadmap about removing Playwright. For my use-case, that would be a show-stopper I think. I would always want Playwright as a fallback in or around my stagehand code... I think.

I'm just starting to play with stagehand and look forward to learning it. Thank you for opensourcing it. If there is interest in having me test form-filling (RPA use cases), I'm here to help! We have a massive volume of work ahead of us. We will be Browserbase users for sure as we ramp up!