Engineering · · 4 min read

Letting a Local Model Search the Web Without Letting It Set the Bill

TheYgent 1.3 adds crawler nodes: hosted Apify actors as tools a local model calls. We measured what a model sees, what it spends, and what breaks when it gets every field — and built the node around the answers.

By Arman Bahlakeh

A local model that can search the web is far more useful than one that can't. The hosted scrapers in the Apify Store — web search that returns pages as Markdown, map places, site crawls — are an obvious way to give it that. The question we wanted answered before building anything: what is the right shape for that tool when the model is a local one, and someone else's account pays for every call?

TheYgent 1.3 ships the answer as the crawler node. This post is the measurements behind it.

What a model sees when it gets every field

An actor's input schema is written for a form. Across the store's 100 most popular actors, the median actor has 10.5 input fields and the largest has 65 — proxy settings, CSS selectors, result counts, paid add-ons, hidden tuning knobs. A generic actor-as-tool bridge offers the model all of them. For three popular actors (a web browser, a map scraper, a site crawler), that came to more than 51,000 characters of tool schema, about 13,500 prompt tokens on every call.

A crawler node offers only the fields the person building the agent ticks — one or two per actor — and fixes the rest. The same three actors as nodes: 2,207 characters, about 780 tokens.

Does the smaller tool cost accuracy?

We asked six questions, five of which need a specific crawler and one of which needs none. The facts in the canned results were invented, so an answer that states one proves the model read the tool result. On a 36 GB Apple Silicon Mac, on MLX:

  • Qwen3.6-35B-A3B (4-bit, thinking off): 6 of 6 right tools and 6 of 6 facts in the answer, both ways. The first call took about 1.1 s with node tools and 2.0 s with every field — 30 s before the engine had the long tool prefix cached.
  • Qwen3-0.6B (4-bit, thinking on): 4 of 6 with node tools, 3 of 6 with every field, and a first call of 1.7 s against 13.3 s. With thinking off it called no tool at all, either way.

A capable model copes with either shape. A small one does better with less, and both are much faster with less.

Who sets the spend

Most popular actors bill per event: per page fetched, per place scraped, per review. Offered every field of the map scraper, the 35B model asked for 50 places per search and switched on the paid reviews add-on. The node keeps both fixed: 5 places, no reviews. With pay-per-event pricing, that is the difference between cents and dollars per question, chosen by a model.

So the node takes those choices away from the model and gives them to the builder. The model fills the exposed fields; any other argument it invents is dropped. Every run also carries a charge cap — the node's own, $0.25 by default — held under a platform ceiling that no agent can raise.

What broke along the way

  • List arguments crash the request on MLX. In mlx-lm 0.31.3, the Qwen3 tool parser hands a list-typed argument that isn't valid JSON to a Python literal parser. The 35B model wrote ramen restaurant for a list of search terms, the parse raised, and the server closed the connection without answering. A crawler node offers list fields as one value per call by default and wraps it into the list the actor wants.
  • Models put JSON lists into string fields. Offered one URL, the model sometimes wrote a JSON-encoded list of one URL. The node unpacks it rather than crawling a URL made of brackets and quotes.
  • Results arrive whole. Through a plain HTTP tool, three documentation pages came back as one 50,175-character tool result, about 12,500 tokens. A crawler node keeps the item fields you choose and shares a character budget, 6,000 by default, equally across the results.
  • Synchronous runs stop at 300 seconds. Past that, Apify answers with a timeout while the run carries on. Interactive runs cap the actor's own timeout there; durable runs start the crawl, check on it, and read the results, so a long crawl survives a restart.

How much of the store works

Of the 100 most popular actors, 97 converted into a usable node with no configuration. The other three need a login cookie, which belongs in a secret, not in a model's arguments. 45 needed URL lists reshaped into the objects the actor expects, which the node does. The median 30-day run success rate was 99.2%, but seven actors were below 90% and one web-search actor had timed out on 36 of its 47 runs — which is why the Crawlers browser puts the success rate on every card.

The limits

Apify is a hosted service. A crawler node sends its input to Apify, which crawls from its own servers, and every run bills the Apify account behind your token. Per Apify's pricing page (checked October 19, 2026), its free plan includes $5 of usage a month. The runs above went to a local stand-in for Apify's run API with the documented response shapes, so real actor latencies and output sizes weren't part of this measurement. And unlike the rest of TheYgent, a crawler node needs the network.

If you'd rather give a capable model the whole store, Apify's own MCP server installs from TheYgent's MCP hub, and the docs cover it.

Try it