One Prompt, a Full Airline Scraper: Announcing Our Claude Code Plugin

Here's how you should use AI to build web scrapers: use it once, to build the scraper, and never again at runtime.

That cuts against how most "AI powered" scraping works today, and it's the idea our new Claude Code plugin is built around. To make the case, we launched the plugin, then let it write a complete, working scraper for a real airline from a single prompt. We did not touch the code, and it runs with zero AI in the pipeline.

Use AI to build your scraper, not to run it.

#The way most AI scraping works is backwards

There's a wave of "AI powered" scraping tools that put a language model inside the runtime: an agent drives a headless browser, clicks around, and reads the page on every single run. It demos well. At scale it's a margin killer.

Every run pays for:

• a full browser, tens of megabytes of HTML, JS, images, and XHR, per page,
• residential proxy bandwidth on all of it, and
• LLM inference and latency, every single time.

You end up paying the most expensive part of the stack, the model, over and over to do the same thing.

The hard part, figuring out a site's antibot flow and writing correct request code, is a one time job, and it's exactly what an AI is good at. The repetitive runtime work is exactly what it shouldn't be doing. Spend the model once, up front, then run plain request code with no AI at all.

#Meet the plugin

The Hyper Solutions Claude Code plugin is built around that split. Think of it as a web scraping oracle for the Hyper Solutions APIs:

• Build a request based scraper from a recorded browser session.
• Ask general questions about integrating the Hyper Solutions APIs.
• Debug a broken flow in a scraper you already have: point it at the failing requests and it tells you what's off.

It bundles the Hyper Solutions integration skill plus two MCP servers, powhttp (live wire capture: real header order and TLS fingerprint) and our HAR analyzer, so Claude can inspect exactly what a browser put on the wire and replicate it as request code.

#The demo: one prompt, one scraper

The setup: powhttp capturing traffic with its MCP server enabled, and one navigation to Etihad's award search (CDG→ICN). The page fired 282 requests before the pricing API, api-des.etihad.com/.../air-bounds, returned its JSON.

Then, in Claude Code with the plugin loaded, one prompt:

I've recorded a browser session to search for flight results on etihad.com, it's your job to implement the requests to scrape the JSON api endpoint https://api-des.etihad.com/airlines/EY/v2/search/air-bounds?... and figure out how to bootstrap the session with antibot solving. the requests must be implemented in golang in this project and use bogdanfinns tls client.

16 minutes and 31 seconds later: a complete Go scraper, untouched by us, that bootstraps the antibot and pulls live award pricing.

#What actually happened in those 16 minutes

This is the interesting part, and it's why the result works. Claude didn't guess. Using the powhttp MCP, it read the real wire traffic and worked out the flow:

• It saw both Akamai (on digital.etihad.com) and Imperva/Incapsula reese84 (on the API), and correctly determined the API path only needs the reese84 x-d-token, so it skipped the Akamai flow entirely.
• It identified the reese84 "dynamic" (Pardon Our Interruption) variant with a Proof of Work step, and reconstructed the full bootstrap: homepage → fetch the challenge script → PoW POST → sensor POST (solved via the Hyper Solutions API) → token.
• It noticed the challenge script path rotates on every load, so it parses it from the page instead of hardcoding it.
• It pulled the browser's JA4/TLS fingerprint and the exact Chrome header order from powhttp, the things DevTools and HAR files can't show you, and matched them with a bogdanfinn tls-client profile and fhttp's header ordering.

The result is five bootstrap calls (homepage, reese84 script GET, PoW POST, sensor POST, homepage reload) that mint a session token, then two API calls (OAuth exchange, then the search). After that, you can call the search endpoint as many times as you want on the same session.

The complete code Claude wrote for this, untouched, is on GitHub: github.com/Hyper-Solutions/etihad-claude-demo. Read it and see exactly what a one shot build produces.

#The numbers

One search, measured on a single run.

First result (cold start):

• Full page load: 19.25 MB, 8.05 s
• Direct API, our scraper: 862 KB, 2.89 s (bootstrap + search)

Each further search (session already held):

• Full page load: 19.25 MB, 8.05 s
• Direct API, our scraper: 22 KB, 1.81 s

The distinction that matters isn't "browser vs. no browser": it's whether you load the whole page for every data point or call the API directly once you hold a session.

Loading the full page every time is exactly what unblocker / "web scraping API" products and page rendering AI agents do: you hand them a URL, they render the whole thing, and you pay for all 19.25 MB, every single search. Scale that to a million price checks at a mid range residential proxy rate of $4/GB and it's ~19.25 TB → on the order of $77,000 in proxy cost alone, plus, for the AI ones, an LLM inference bill on top of every run.

Our scraper bootstraps once and then calls the JSON endpoint directly: 22 KB per search, about 875× less bandwidth. The same million searches come to ~30 GB → roughly $120.

To be fair: if you already have a real browser in hand, you can optimize it the same way, bootstrap once, then fetch() the API directly instead of reloading the page, and land near that 22 KB too. But doing so means working out the exact bootstrap and API flow first... which is precisely the analysis the plugin just did for you. And once you've done it, the browser (and any model driving it) is dead weight in the loop. So drop it, and ship plain request code.

(Figures are from a single measured run and are illustrative.)

#Try it

The scraper Claude produced is plain Go: no model, no browser, no per run inference. Its cost scales with kilobytes of bandwidth, not a browser farm and a token meter. That's the whole point, and the plugin is how you get there.

Install it in Claude Code:

/plugin marketplace add Hyper-Solutions/hypersolutions-claude-code
/plugin install hypersolutions@hypersolutions

All you need is a Hyper Solutions API key. Grab one, record your own flow, and point the plugin at it.

There's a Codex build too, and a full rundown of what ships in each on the plugins page.

This demo uses publicly available fare data and is provided for educational purposes only.