I built a custom search action with Wingman this week and learned some things about search
architecture on Pickaxe the hard way. Sharing in case it saves someone else the diagnosis time.
The problem
I run a tool that finds in-person events for authors. It verifies dates, websites, and vendor costs,
so one run makes eight to twelve web searches. Those runs started timing out. Completions on my
workspace fail at right around 300 seconds, and I measured the xAI web search action at roughly 30 seconds per call round trip. Eight calls at 30 seconds spends 240 seconds on search alone. The math never closes.
The lesson is that per-call speed was never the issue. Thirty seconds is fine for a tool that scrapes
one page and reviews it. The trouble is stacked sequential searches, because every search is a full
model round trip and the seconds multiply.
The action
Parallel.ai is a search API built for exactly this. One call takes a natural language
objective plus up to three queries, and their turbo mode answers in well under a second. Batching
three queries per call means twelve queries of coverage in four round trips instead of twelve.
The before and after on my tool: with sequential searching it timed out on every run. With batching it finishes in three to four minutes and returns more events with more confirmed dates. Same model, same knowledge base, same prompt otherwise.
I have also set the action’s visibility to public, if any of you want to play with it. You will need to bring your own key but Parallel gave me $25 in free credits on sign up.
I built the action by pasting one prompt into Wingman. Here it is if you want the same action, just
add your own Parallel API key when Wingman asks:
Create an action called “Parallel Fast Search” that searches the web using the Parallel Search
API. Make a POST request to https://api.parallel.ai/v1/search with the header “x-api-key” set to
a secret variable named PARALLEL_API_KEY and Content-Type application/json. The request body has
three fields: “objective” (a one-sentence natural language description of what we are trying to
find, provided by the model), “search_queries” (an array of one to three short keyword query
strings, provided by the model), and “mode” set to the fixed value “turbo”. Return the response’s
“results” array to the model, where each result contains url, title, publish_date, and excerpts.
The action should pass the excerpts through to the model unmodified so it can quote them as
evidence.
Pricing is about a dollar per thousand calls on turbo, and they give signup credits, so testing
costs nothing.
When to use which search option
This is what my testing suggests so far. Your mileage may vary.
Built-in Google Search or the xAI search actions. Fine for tools that make one or two searches
per response. A page scanner, a fact checker on a single claim, a scraper that reviews one URL. The
per-call latency does not matter when there is only one call.
A batching action like this one. The choice for research tools that need many searches in one
response. The win is not the fast API by itself. The win is restructuring the prompt so the model
sends three queries per call instead of one, which cuts the round trips that actually spend the
clock.
Perplexity Sonar models. Still the right call for single-shot retrieval tools where one search
pass feeds one answer, since search runs server side inside the request. Note that Sonar models do not support actions at all if you use them as the main LLM. You could add Perplexity as an action though.
Two honest caveats
Parallel returns excerpts, and excerpts do not always carry the exact detail you need. My tool
wants day-specific event dates, and I am still tuning query phrasing to raise the hit rate.
Second, search results are only as good as their sources. One run pulled an event date from an
aggregator page that was stale by one day. If accuracy matters, have your prompt prefer the
subject’s own website over listing sites, and require quoted evidence for the facts you care about.
One operational warning if you share or update an action by manifest: updating the manifest resets the trigger prompt on every Pickaxe that has the action attached, back to the new default. If your tools use customized trigger prompts, re-apply them after any manifest update. This cost me a silent trigger overwrite before Claude Code caught it.