SparkProxy vs Thordata: SERP API or Raw Proxies

There are three things you can buy to collect search results, and they are not substitutes.

The bottom layer is bandwidth: an IP pool that will carry your HTTP request to a search engine and bring the HTML back. You write the URL, you set the locale, you parse the response, you own it when the markup changes. Both vendors sell this layer, Thordata metered by the gigabyte and SparkProxy on a flat plan priced by concurrent threads.

The middle layer is a general scraping API: rotation, headless rendering and anti-bot behind one endpoint, still returning a document you parse. SparkProxy's Scraping API sits here. Thordata's Web Scraper API and its "Webpage" block-bypass product sit here too.

The top layer is a SERP API: you hand over a query string and a locale and get back result objects. Thordata sells one. SparkProxy does not sell anything at this layer, and there is no honest way to narrow that gap with a feature table.

So a comparison that runs "pool size, price, protocols, verdict" answers the wrong question for search work. Pick the layer first. Then, and only then, does vendor price matter, and for the bottom two layers it turns into arithmetic you can do in an afternoon. Our overview of proxies for SERP scraping at scale covers the bottom-layer mechanics; this page is about which layer to put on the invoice.

Here is what the top layer actually absorbs, with Thordata's own documented parameters as the evidence. All of this is readable at doc.thordata.com.

1. Query construction. Thordata's Google endpoint takes q plus google_domain, tbm for search type (images, shops, news, videos), tbs for time and content filters, num and start, safe, nfpr and filter. On raw proxies you build and maintain those query strings yourself, and the undocumented ones are the ones that break.

2. Locale and device emulation. Thordata documents hl for interface language, gl for country, location, cr, lr, and uule, which its docs describe as "Specify precise geographic location based on coordinates (Base64 encoded)". The Bing endpoint takes mkt, cc, lat/lon and adlt. Pinning a SERP to a coordinate is a different problem from pinning an exit IP to a country, and it is the one most rank-tracking projects get wrong.

3. Pagination. start and num on Google, first and count (range 1 to 50) on Bing. Trivial until you discover which combinations silently return a different result set.

4. Structured output. Thordata's json parameter is the whole pitch: no value returns HTML, json=1 returns JSON, json=2 returns "JSON + HTML". q and json are both marked required for Google search. One caveat worth acting on before you commit: the docs name organic_results but we did not find a published field list, so if your pipeline depends on a specific block, ask Thordata for a sample response rather than assuming a field exists.

5. Absorbing layout churn. Google changes its results page constantly, and every change lands on whoever wrote the parser. Buy the top layer and that is Thordata's problem. Thordata also exposes an ai_overview parameter for AI-generated summaries, which is the clearest example of the category: that block did not exist a few years ago, and someone had to write a parser for it.

A fair counterweight. Everything a SERP API abstracts, it also hides. If you need a field nobody parses, a raw page you can re-parse next quarter against new rules, or a search engine outside the supported set, the bottom layer is the only layer that gives you the artefact. Thordata's docs list "Google, Bing, Yandex, DuckDuckGo, and specialized search types", which is broad, and still finite. Our explainer on what a SERP scraping proxy is and how it works covers the bottom-layer version of the same job.

Monthly subscription, USD. No sale or strikethrough was displayed on this page when we read it, unlike the residential one.

Every row's arithmetic checks out against its own rate: 150,000 responses at $0.90 per 1,000 is exactly $135. That sounds like faint praise until you have audited a few vendor pricing pages.

Two details on this page are worth more than the rates. First, the trial: "7-Day Free Trial" with "500 responses" at "$0.00/1K responses", and "No credit card required." Five hundred queries is enough to check whether the parsed output has the fields your pipeline needs, which is the only question a trial should answer.

Second, and this is the one that changes budgets: billing is pay-per-success. Thordata's billing doc states that "Charges apply only when a single request returns a 200 status code; no charges are incurred for other status codes," and its table marks 300, 400, 401, 403, 404, 429, 500 and 504 all as not billed. On a hard target where a real share of attempts fail, that moves failure risk off your invoice and onto the vendor. Metered bandwidth does the opposite: you pay for the bytes in a block page exactly as you pay for the bytes in a result.

Now price the bottom layer for the identical job. SparkProxy's Scraping API bills credits, and the credit costs are what decide this, not the plan price.

A plain HTTP fetch on the default rotating pool is 1 credit. render_js defaults to true and costs 5, so for SERP HTML you usually want it off, which is also about three times faster. country_code pins the exit country and adds 5. So a country-pinned, unrendered SERP fetch on the rotating pool is 6 credits.

Credits come out of a monthly plan, not a one-time purchase. The allowance resets with the billing month:

At 6 credits per query, the Growth plan prices a SERP fetch at about $0.59 per 1,000 and the Pro plan at about $0.50 per 1,000. On the rotating pool, both undercut every rung of Thordata's SERP ladder on the fetch alone. Drop the country pin and it's 1 credit per query, roughly $0.10 per 1,000 at Growth, which is an order of magnitude under the top layer.

The pool you pick decides whether that holds, so here is the other number. Six credits is the cheapest route we sell, and Google is not a soft target. Our docs also publish a premium pool, selected with premium_proxy=true, which they describe as routing the request through "a residential proxy from our premium pool". The credit table prices "Premium proxy, no JS (premium_proxy=true, render_js=false)" at +10, so a country-pinned premium fetch is 15 credits, not 6. That works out to $1.485 per 1,000 queries on Growth, $1.245 on Pro and $1.123 on Scale.

Those undercut no rung of Thordata's ladder except the $1.20 entry rate, and only at the Scale plan. So the claim in the paragraph above is conditional, and we'd rather write the condition than let you find it: on the rotating pool the bottom layer beats the whole ladder on rate, and on the premium pool it does not. Every figure in the crossover arithmetic below assumes 6 credits. If your target needs the premium pool, the per-query gap that the parser hours get amortised against mostly vanishes, and the case for building rests on the monthly plan price instead of on the rate. Which pool you need is an empirical question about your target rather than a pricing question, and the test for it is in the last section.

Here is that fetch, with the one mistake everyone makes written out. json_response=true is the only parameter that returns the envelope, and the envelope's body is base64-encoded. Decode it before any string match, or your "did this page contain results" check silently fails on every request:

import base64, requests

params = {
    "url": serp_url,
    "render_js": "false",      # 1 credit instead of 5, and ~3x faster
    "country_code": "us",      # pins the exit country, +5 credits
    "json_response": "true",   # returns the ENVELOPE; body is base64
}
r = requests.get(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": API_KEY},
    params=params,
    timeout=60,
)
env = r.json()
html = base64.b64decode(env["body"]).decode("utf-8", "replace")  # decode FIRST

print(env["job_id"], env["status_code"], env["credits_used"], env["duration_ms"])
results = parse_serp(html)   # <- this function is the subject of the next section

Note what is not in that snippet: format=json does not give you the envelope, it converts the page content. And extract_rules replaces the normal response with an extracted object, so it must not be combined with json_response. Batch mode is cheaper still, 1 credit for the whole batch, but only works with render_js=false.

For comparison, the top-layer call against Thordata's documented endpoint, which serves both Google and Bing from one path selected by engine:

# Endpoint and parameter names per doc.thordata.com, read 9 Oct 2026.
# Auth is omitted deliberately: we are not quoting a header we did not read.
curl -G "https://scraperapi.thordata.com/request" \
  --data-urlencode "engine=google" \
  --data-urlencode "q=rotating proxy api" \
  --data-urlencode "gl=US" \
  --data-urlencode "hl=en" \
  --data-urlencode "json=1"

One call returns objects. The other returns a document and a problem. Put a figure on that problem at a single volume, because the per-1,000 rates on either side belong to different rungs and do not both apply at once. Both of these ladders are monthly step floors, not marginal rates: you pay the whole rung. At 500,000 queries a month, Thordata's own tier is $400 and the plan that covers 3,000,000 credits is Pro at $249, so the top layer costs $151 a month more at that volume. From the published rates it is the same figure: ($0.80 minus $0.498) times 500 is $151.00. Whether $151 is expensive depends entirely on the next section.

Nobody puts this line in a vendor comparison, which is why the comparisons are wrong.

A SERP parser is not a one-off build. It is a small piece of software that has a permanent dependency on a page you don't control and that is changed by people who are not thinking about you. The failure mode is nastier than a crash: selectors keep matching, the shape stays valid, and the field quietly goes empty or picks up the wrong block. You find out from a downstream dashboard a week later, by which time the week's data is suspect.

Price it the way you'd price any other maintained component: hours per month, times your loaded engineering cost. Go and get the first number from your own git history rather than guessing:

# Months in which someone touched the SERP parser, and how often
git log --since="18 months ago" --format="%ad" --date=format:"%Y-%m" \
  -- src/parsers/serp/ | sort | uniq -c | sort -k2

# Rough hours, if your commits carry a time-tracking trailer
git log --since="18 months ago" --format="%(trailers:key=Time,valueonly)" \
  -- src/parsers/serp/ | grep -Eo '[0-9.]+' | awk '{s+=$1} END {print s "h over 18 months"}'

If you have never built one, the honest range is a one-time build of a few days plus steady-state upkeep somewhere between one hour and a full day a month, spiking when a layout changes or a new block appears. Teams that track every surface (organic, ads, local pack, AI summaries, people-also-ask) sit at the top of that range. Teams pulling ten organic links and nothing else sit at the bottom, and some months pay nothing at all.

That variance is the whole decision. Use $100 an hour as a loaded cost placeholder below and substitute your own; the shape of the answer doesn't change, only where the line falls.

Put both layers on one table. Self-built cost is the SparkProxy monthly plan whose credit allowance covers 6 credits per query, plus parser upkeep at $100 an hour.

Read the last two columns against the first. At every tier Thordata publishes, a team spending six hours a month on its parser is paying more to build than to buy. At one hour a month the lines cross just above Thordata's 150,000-response tier, because that is where its ladder steps from $135 to $400 while the Growth plan still covers the volume at $99. The sign flips between the 150,000 and 500,000 rows of this table, not higher up. At zero hours, which is to say if you already maintain that parser for other reasons and the marginal cost really is zero, the bottom layer wins from just above 50,000 queries, which is where the ladder steps from $55 to $135.

The general form is simple enough to keep in your head. On the rotating pool the top layer costs more per query, and the bottom layer costs more per month. Set them equal and the crossover is:

crossover queries/month  =  monthly parser cost  /  (API rate - fetch rate)

Both sides of that subtraction are step functions, so the gap depends on which rungs cover your volume, and the only honest way to use the formula is to pick the pair that does. Both figures below are at 6 credits on the rotating pool.

Mid-ladder, where most buyers sit, the pair is Thordata's 500,000-response tier at $0.80 per 1,000 against the Pro plan's $0.498 per 1,000 country-pinned fetch. The difference is $0.302 per 1,000. Divide $100 by it and you get the number worth remembering:

Every engineer-hour a month you spend on the SERP parser pushes the break-even up by about 330,000 queries a month.

That one is self-checking. The exact figure, 331,126 queries, sits inside the 166,667-to-500,000 band where both of those rates are the rates you'd actually be charged. Take the cheapest rung of each ladder instead, Thordata's $0.70 against the Scale plan's $0.449, and the gap widens to $0.251 and the coefficient to about 399,000 queries per hour of parser work. That pairing is only available from 1,000,000 queries up, though, so it belongs to the long end of the curve and not the short one. Use it there: six hours a month puts the break-even just under 2.4 million queries. Zero hours puts it at zero, and you should build. Either way you can recompute it with your own hourly rate in about ten seconds.

Two caveats on that long end. Above 1,000,000 responses Thordata's ladder says "Contact sales", so the $0.70 is our extrapolation and not their quote. And the Scale plan's 8,000,000 credits cover only 1,333,333 country-pinned queries, so past that our own side is an extrapolation too. Get a real number from both vendors before committing at that scale.

A reminder about what this arithmetic does not cover: the top layer is also the layer where the "did we get blocked" problem lives. Thordata only bills HTTP 200s. If your own attempts at the bottom layer fail 30% of the time, your effective fetch cost rises by 43% and the crossover moves against building. Measure your success rate before you trust the table.

Leave search and the SERP API stops being relevant. For product pages, listings, reviews, APIs, anything that isn't a search engine, Thordata's top-layer advantage simply doesn't apply, and the comparison collapses back to pool and price. So here is that comparison, priced honestly.

Thordata's residential ladder, read 9 October 2026, pay-as-you-go, with an active sale displayed:

Look at the 50 GB row. The total is exactly $75.00, which is also SparkProxy's entry plan price. That coincidence puts one price point side by side on the sticker, and reduces the whole decision to a question you can answer about your own job: will it move more than 50 GB a month? One qualifier before you lean on the symmetry: our page says "All prices exclude VAT/GST", and Thordata publishes no VAT position we could find, so the two $75 figures match on the sticker and not necessarily on the invoice. Check what each one bills you in your own jurisdiction.

At $75, Thordata gives you 50 GB of metered residential traffic. At $75, SparkProxy gives you 100 concurrent threads on a pool of 1M+ datacenter IPs across 80+ countries, with unlimited bandwidth, 1 Gbps ports, random or 5-minute rotation, HTTP/HTTPS/SOCKS5, and IP-whitelist or user:pass auth.

Convert 50 GB into pages and the question answers itself. A render-heavy target serving about 3 MB per page burns a gigabyte every 341 pages, so 50 GB is roughly 17,000 pages of that target. A lean JSON or static-HTML target at 150 KB a response gets about 6,990 per gigabyte, so the same 50 GB is close to 350,000 requests. Same money, a twentyfold difference in what it buys, decided by page weight rather than by either vendor.

That is the structural point. Per-GB billing makes your invoice a function of page weight, which you do not control: a redesign that adds a hero video doubles your bill without changing your code. Plan billing makes it a function of concurrency, which you set in a config file. Our write-up on whether unlimited bandwidth proxies are worth it runs through where that trade stops paying, and how to forecast proxy bandwidth needs has the measurement method.

Two caveats that keep this honest. Thordata's residential figures were on sale when we read them, so they may not hold. And these are different IP categories: Thordata's metered product is residential, SparkProxy's flat plan is datacenter. If your target rejects datacenter ranges outright, the $75 column on the left is the only one that exists for you, and no amount of per-GB arithmetic changes that. Our Scraping API's premium pool is documented as residential, but it bills per request in credits rather than per thread, so it is a different purchase and not a flat-plan substitute. Residential vs datacenter proxies is the test to run first.

Thordata advertises residential "from $0.65/GB" and SERP responses "from $0.70/1K". Both are real, and both are the last rung.

$0.65/GB is the 5,000 GB tier, a $3,250 purchase. Thordata's homepage shows that $0.65 as a sale price against a regular rate of "$1.05/GB". $0.70 per 1,000 responses is the 1,000,000-response tier, a $700 monthly commitment. The entry rates on the same two pages are $2.00/GB and $1.20 per 1,000.

This is not a criticism. It's how volume ladders work, and SparkProxy's own credit plans behave identically: $0.196 per 1,000 credits at Starter down to $0.075 at Scale, which is a 2.6x spread. The point is procedural. Any article that quotes "$0.65/GB" against SparkProxy's "$75/month" is comparing a $3,250 purchase to a $75 one, and that comparison is meaningless in either direction. Price the tier you will actually sign. Our breakdown of residential proxy pricing per GB covers how to read these ladders generally.

Buy Thordata, not SparkProxy, for these jobs. Each one is a capability SparkProxy has no product for, so none of this is a close call.

• Parsed SERP data at any volume. SparkProxy ships no SERP API. If the job is "give me ranked results as objects", Thordata is the purchase and everything in the crossover table above is irrelevant to you.
• Google AI Overview capture and coordinate-level SERP localisation. ai_overview plus uule, gl, hl, google_domain, cr and lr. Rebuilding that on raw proxies is weeks of work before you have a single row of data.
• Pay-per-success on a target with a high failure rate. Billing only on HTTP 200 is genuine risk transfer, and on a hard target it is worth real money.
• Small one-off jobs and bursty volume. 1 GB for $2.00 with no subscription beats a $75 monthly floor on absolute cost. Anyone whose total need is under roughly 50 GB a month should buy Thordata on price, full stop.
• ASN-level targeting. Thordata documents continent, country (2-letter ISO), state/region, city and ASN filtering, with location parameters embedded in the username string. SparkProxy's published targeting is country-level across 80+ countries. If you must exit through a specific network rather than a specific place, Thordata has the knob.
• Sessions that must hold one IP for half an hour. Thordata documents sticky sessions via a sessid suffix on the username with duration set by sesstime, stating "The maximum session duration is 90 minutes", with sessions also ending after 90 seconds of inactivity. SparkProxy's published rotation is random per request or 5-minute auto-rotation. Multi-step authenticated flows fit Thordata's model, and what a sticky session proxy is explains why the difference bites.
• Long-tail country coverage. Thordata's residential product page claims "Over 100 million real residential IPs from genuine users across 190+ countries", against SparkProxy's 80+. Coverage you don't have can't be beaten on price.
• Product lines SparkProxy doesn't sell at all. Mobile proxies from $2.20/GB, static ISP and datacenter proxies at $0.75/IP (sale, regular $1.50/IP), a Web Scraper API from $0.50 per 1,000 results, a "Webpage" block-bypass product from $1.00 per 1,000 responses, and a Scraping Browser from $2.5/GB, all as listed on thordata.com/pricing/ on 9 October 2026. A buyer who wants mobile carrier IPs from the same vendor has no SparkProxy option to weigh.
• Very large metered volume with genuinely light pages. At $0.65/GB and $3,250, a team with tight control over payload size and a predictable burn can land under the cost of stacking flat plans. The volume discount is real and published.

Thordata also publishes per-location residential counters, including United States 3,876,096 IPs, United Kingdom 1,850,036, Germany 1,267,993, France 1,252,964 and Japan 526,642. Those appear to update, so read them as a snapshot taken on 9 October 2026. Where the pool comes from is a separate question worth asking any residential vendor, and where residential proxy IPs come from covers what to ask.

Short list, because unanswered questions are cheaper to ask than to discover. These are the things we went looking for and could not find, including in Thordata's full llms-full.txt export.

Ask Thordata about:

• Concurrency. No thread or connection limit for residential proxies appears anywhere in the readable documentation. This matters specifically because concurrency is SparkProxy's billing unit, so the one axis you'd most want to compare has no published number on one side. Don't assume it is unlimited. Ask sales, in writing.
• SOCKS5. The docs demonstrate HTTP and HTTPS through t.pr.thordata.net:9999, with user/pass and whitelisted-IP auth and code samples for cURL, C#, Go, Java, PHP, Python, Node.js and Ruby. SOCKS5 is not mentioned. That is not the same as unsupported, and we won't claim either way.
• Whether purchased traffic expires. No statement found on the pricing page, the billing FAQ or the docs about rollover or expiry of residential gigabytes. For pay-as-you-go that's a real buying consideration.
• Whether unused SERP responses roll over at month end. Also unstated.
• Minimum commitment, contract length and refunds on residential plans.
• Residential trial terms. The homepage carried a rotating "3 Days Free" promo plus 10% off for existing users on the 1 GB to 350 GB tiers, with no documented trial traffic allowance. The 7-day, 500-response free trial is specific to the SERP API; do not assume it extends to the proxies.
• Coverage count, because Thordata's own properties disagree: "190+ countries" on the marketing pages, "over 195 countries" in the residential docs, "195 locations" in the location-settings doc. All three are theirs. Pick the one that appears in your contract.

Ask SparkProxy about: the absence of a SERP API, which is stated plainly on this page; sub-country targeting, which we do not offer; and ASN or subnet breakdowns, which we publish pool size and country count instead of. Understanding concurrent connections in proxies explains how to size the thread count you'd be buying.

Read the Acceptable Use Policy before you buy a SERP API from anyone. It takes five minutes and it has nothing to do with price.

Thordata's Acceptable Use Policy, at thordata.com/acceptable-use-policy, prohibits among other things "Collection of nonpublic information (i.e data behind login)", "Any Search Engine Optimization (SEO) manipulation (i.e: fake clicks in search engines results)", "Reselling of proxies without Thordata's prior written approval", ad and click fraud, ticket bots, and DDoS. It states that "Thordata maintains a zero-tolerance policy toward any illegal, fraudulent, abusive, or non-compliant use" and that it will "cooperate fully with law enforcement authorities". Abuse reports go to abuse@thordata.com.

That SEO bullet is the one worth reading closely, and the parenthetical is doing the work. A large share of SERP API demand is rank tracking, which is read-only measurement, and Thordata's own worked example of SEO manipulation is fake clicks in search results. Fake clicks are writes. Rank tracking is a read. So on the face of the policy the clause is aimed somewhere else entirely, and rank tracking reads as permitted use of the product Thordata is selling. We flag the clause anyway because an AUP is the page nobody opens before committing a pipeline to a vendor, and because policies get revised: read the current text against your own use at the trial stage. That goes for every vendor in this category, us included, and it is cheaper to check then than after a suspension.

On sourcing, use Thordata's own words rather than anyone's summary. Its homepage states: "Our 100M+ IPs are ethically sourced, with SOC 2 & ISO 27001 certifications in progress," and references building on "GDPR, CCPA, and KYC standards". Note the exact phrasing on the certifications: in progress, which is Thordata's description, not a holding. If your procurement process requires a completed SOC 2 report, ask for the current status and a date rather than reading "in progress" as either a yes or a no.

• The output you need is result objects. Buy Thordata's SERP API. Start on the 7-day, 500-response trial and check the parsed fields against your schema on day one, because that is the only thing the trial can tell you and the field list isn't published.
• The output you need is pages, your target survives the rotating pool, and your parser upkeep is under about one hour a month per 330,000 queries. Fetch them yourself. SparkProxy's Scraping API at 6 credits per country-pinned query is the cheaper layer, and how to scrape Google search results has the mechanics.
• The work isn't search at all. Price bytes against threads. Under about 50 GB a month, or if the target rejects datacenter IPs, buy Thordata. Over it, on datacenter-friendly targets with heavy or unpredictable pages, buy a flat plan.

And the combination most large search projects end up at: the top layer for the surfaces that change often and the long-tail locales, the bottom layer for the high-volume queries whose parsing you already own. The two are not exclusive, and splitting them is usually cheaper than forcing everything through one layer.

Three measurements, one afternoon, and the answer stops being an opinion.

One: how many bytes is one SERP? Search pages are heavier than people expect, and this number tells you whether metered billing is even in play for the search half of your work.

# Average SERP transfer size, plain fetch, country-pinned
while read -r q; do
  curl -s -o /dev/null -w "%{size_download}\n" \
    -H "X-API-Key: $SPARKPROXY_API_KEY" \
    -G "https://scrape.sparkproxy.io/api/v1" \
    --data-urlencode "url=https://www.google.com/search?q=$q" \
    --data-urlencode "render_js=false" \
    --data-urlencode "country_code=us"
done < queries.txt | awk '{s+=$1; n++} END {printf "avg KB %.0f over %d queries\n", s/n/1024, n}'

Then multiply that out against the residential ladder, because it closes the other half of the search comparison. A gigabyte holds 1,048,576 KB, so at Thordata's 50 GB rate of $1.50/GB a SERP of W kilobytes costs $1.50 x W / 1,048,576 per fetch. Your measured W goes in there, not a page weight we invented: at 200 KB that is about $0.29 per 1,000 fetches, at 150 KB about $0.21. Whatever your number is, the shape of the answer holds. On the residential ladder the bandwidth for search work is close to free, and the parser is nearly the entire cost. That is precisely why the top layer prices itself against your engineering time instead of against bytes, and why the coefficient above is the figure to argue about.

Two: what is your success rate, and on which pool? Count non-200s over a few hundred real queries on the default rotating pool, then take the same sample again with premium_proxy=true. Thordata bills only 200s, so your own failure rate is the number that moves the crossover against building. The gap between the two pools is what tells you whether your real cost is 6 credits a query or 15, and that single choice matters more to the total than any rung on either ladder.

Three: run the crossover on your numbers. Change HOURLY and CREDITS_PER_SERP and nothing else.

# serp_crossover.py  Which layer is cheaper for YOUR search volume?
# Thordata ladder: thordata.com/pricing/serpapi, read 9 Oct 2026, USD.
THORDATA = [(15_000, 18.00), (50_000, 55.00), (150_000, 135.00),
            (500_000, 400.00), (1_000_000, 700.00)]
# SparkProxy monthly credit plans: sparkproxy.io/scraping-api/, credits reset monthly.
PLANS = [(250_000, 49.00), (1_000_000, 99.00),
         (3_000_000, 249.00), (8_000_000, 599.00)]
CREDITS_PER_SERP = 6      # rotating pool: 1 plain fetch + 5 for country_code.
                          # Use 15 for the premium pool (+10) and re-read the verdicts.
HOURLY = 100.00           # your loaded engineering cost

def thordata(q):
    for cap, price in THORDATA:
        if q <= cap:
            return price
    return q / 1000 * 0.70            # above 1M their page says "Contact sales"

def self_built(q, parser_hours):
    credits = q * CREDITS_PER_SERP
    plan = next((p for c, p in PLANS if c >= credits), None)
    if plan is None:
        plan = credits * 599 / 8_000_000   # extrapolated at the Scale rate
    return plan + parser_hours * HOURLY

for q in (50_000, 150_000, 500_000, 1_000_000, 2_400_000):
    for hours in (0, 1, 6):
        a, b = thordata(q), self_built(q, hours)
        print(f"{q:>9,} queries | {hours}h parser | buy ${a:>8,.2f} | "
              f"build ${b:>8,.2f} | {'BUY' if a < b else 'BUILD'}")

Run it and you'll see the flip happen at 2,400,000 queries and six hours, where buying costs $1,680.00 and building costs $1,678.20. That is how close a two-and-a-half-million-query decision can be, and why the parser-hours number is the one to measure rather than estimate.