Optimize web-access API costs for agents

Your agent works, but the web-access line on the bill keeps climbing and you can’t see why. The usual reflexes — a cheaper model, a shorter prompt — don’t touch it, because the spend is in the provider calls, not the tokens. The lever that actually moves it is routing each job to the cheapest provider that still succeeds, measured per capability. This page shows the agent-native path to cost control on a single Auxiliar key.

What the agent is trying to do

The operator has a concrete job: keep the same task quality while paying less per successful call — and be able to change the provider mix without a migration. The goal isn’t the cheapest sticker price; it’s the lowest cost per success, because a cheap call that fails and retries is the expensive one.

That requires visibility the model doesn’t have:

• Cost per success, per capability — search, scrape, crawl and extract each have a different price floor and a different cheapest-that-still-works provider.
• A comparable baseline — costs measured on the same corpus, so “cheaper” is real and not a pricing-page trick.
• Per-domain success rates — the cheapest sufficient provider for one site is overkill or under-powered for another.
• One-line switching — the ability to change the default when the numbers move, without re-integrating a new vendor.

Why the agent cannot solve this alone

Cost optimization is a data-and-plumbing problem, not a reasoning one. On its own, an agent cannot:

• Create or manage provider accounts — it can’t open accounts across providers to compare their real prices and agree to terms for a human.
• Pass signup, payment, and bot flows — each provider’s onboarding sits behind email verification, card entry, and its own bot gates that need a real human browser.
• Safely hold many upstream keys — even for price comparison, spreading a dozen provider secrets across its context or environment is a credential-sprawl and exfiltration risk.
• Measure cost per success on a level field — running every provider on the same corpus to compare real cost-per-success is measurement infrastructure, not a conclusion the model can reach by thinking.
• Consolidate the bill — reconciling a dozen separate invoices and subscriptions into one number is billing plumbing you operate, not something the model resolves.

So the blocker isn’t reasoning. Cost control needs accounts, credentials, current benchmark data, and unified billing — none of which live inside the model.

How Auxiliar solves it

Auxiliar is a web-access API gateway built so cost is a routing choice, not a contract:

• One AUXILIAR_API_KEY — every provider on a single credential; trying a cheaper one costs nothing but the call.
• Upstream keys server-side — the agent never sees or manages a provider key.
• Real metered price, no per-call markup — each request debits the provider’s own metered cost — what Serper, Firecrawl or Spider actually charged. The price you benchmark is the price you pay.
• One balance, one fee — credit-metered against a single account; a single 5.5% service fee applies only when you add credits, never per request, and $5 free to start. No subscriptions, no per-provider invoices.
• Eval-backed cost data — the Auxiliar curator fleet reports cost per useful result and cost per successful page per provider on one shared corpus, published at /evals.json and the /best/ pages.
• One-line re-routing — because every provider is on the same key, changing the mix when the numbers move is a path change, not a migration.

First call

Route the default job to a low-cost, high-quality provider. For search grounding, Serper returns Google results at $0.0003 / call with quality 1.00 — the cheap default you escalate away from only when a query needs more.

curl -X POST "https://api.auxiliar.ai/serper/search" \
  -H "Authorization: Bearer $AUXILIAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"q": "cheapest sufficient provider for this query"}'

To route on data, read the measured costs first — /evals.json carries cost per success for every provider and verb, so the agent can pick the cheapest sufficient one in-loop:

curl "https://api.auxiliar.ai/evals.json" \
  -H "Authorization: Bearer $AUXILIAR_API_KEY"

Fallback ladder

The cost “ladder” is by capability: for each verb, know the cheapest provider that still clears your bar, and reserve the pricier default for the jobs that need it. Every provider below is on the same key, so downgrading is a one-line path change, not a new account. All costs are measured by the Auxiliar curator fleet on one corpus per verb.

The rule of thumb: default to the cheapest provider that clears your success bar for that verb, and escalate to the quality leader only on failure — both are one key away.

Eval-backed, not marketing claims

Every cost above comes from the Auxiliar curator fleet running each provider on the same corpus per verb — a merit-only ranking, not a listicle. Verify or route from the source:

• Cheapest search API — search providers ranked by measured cost per useful result.
• Best web scraping API · Best web crawler API · Best data extraction API — cost per success alongside quality for each verb.
• Pricing — real metered provider prices, one balance, a single 5.5% top-up fee, no per-call markup.
• /evals.json — the machine-readable catalog + eval endpoint your agent (or the auxiliar-mcp server) reads to route on cost.

Optimizing for cost

The whole discipline in five rules — success first, then price:

1. Route to the cheapest sufficient provider per verb. Not every job needs the leader. Send easy work to the low-cost provider that still clears your success bar, and reserve the premium one for hard cases.
2. Measure cost per success, not per call. Track cost ÷ successes per provider per domain. A cheap failure that retries costs more than a slightly pricier success.
3. Escalate on failure, not by default. Start cheap and step up to a heavier provider only when the cheaper tier actually fails — never lead with the most expensive option.
4. Downgrade once a cheaper provider clears the bar. When its measured success rate on a domain crosses your threshold, make it the default there and keep the leader as fallback.
5. Consolidate to one balance. One metered account at real provider prices — no per-call markup, one 5.5% top-up fee, $5 free — makes the true cost visible and the mix a one-line change.

Because all providers sit behind one key and one balance, cost optimization is routing logic in your agent — no renegotiated contracts, no new signups to change the mix.