Derive a Client From Traffic

Instead of having the agent click through a website every time, have it record the site's network traffic once and write a client from it.

The prompt

"record network requests into a HAR file then it can derive a client" (Dax Raad, crediting James Long)

Dax Raad had an agent browse Uber Eats while recording network requests to a HAR file, then build a small CLI from what it saw. Source: X/@thdxr, 2026-07-19 agent-browser supports it directly (network har start, browse, network har stop) and ships a derive-client skill. Source: X/@ctatedev, 2026-07-19 For sites that only expose data through the DOM, save .mhtml instead. Source: X/@_ontologic, 2026-07-19 Similar tools: a browse network --tail command, and a CLI "printer". Source: X/@pk_iv, 2026-07-19; Source: X/@davidfano, 2026-07-19

Why it works

Driving a browser is the slowest, most expensive and most brittle way for an agent to use a site: every action is a snapshot, a click and a wait. The site's own API calls are already a clean interface, and a HAR file records them with real parameters and responses. One recorded session gives the agent enough to write a typed client, and every later task becomes a fast API call that does not break when the layout changes.

When to use it

  • Any site you or your agent will use repeatedly: ordering, dashboards, internal tools.
  • When browser automation is flaky or slow.

Use it only on accounts and sites you are allowed to automate, and keep session tokens out of the HAR you commit.

Which skill runs it

agent-browser records the HAR and its derive-client skill writes the client. Browser to API covers turning a site into an OpenAPI spec the same way.


Timeline