I learned some hard lessons on how to make Perplexity work on Pickaxe on a tool to find comp titles for books.
First some background,
I rebuilt one of my author tools on Perplexity Sonar after Grok runs got expensive (Gemini was $7.00 a run, Grok was $2.50). The first Sonar outputs looked broken: no links, bare [1] markers pointing at nothing, and evidence lines that read like guesses. Ten test runs later, the same tool produces verified results for about 3 cents a run in under a minute.
That is way way cheaper. Like way cheaper.
Every fix happened in the prompt. If you tried a Sonar model on Pickaxe and concluded the model is bad, these notes may change your mind.
Sonar is a different machine
Sonar runs one web search before it generates, and the search is seeded by the user message alone. Your Role field (the system prompt) reaches the model after the search, when the results are already in hand. There is no tool loop and no function calling. Almost everything below follows from those two facts.
1. Put search-shaping language in the Prompt Frame Not The System Prompt
The Role cannot influence what Sonar retrieves. Perplexity’s own docs say instructions like “search only on Wikipedia” in the system prompt have no effect. Anything you want the search to find belongs in the Prompt Frame: the topic, the kinds of sites to draw from, phrases like “including books published this year and last year.” That last phrase does more for recency than any date logic, because it resolves against the live web at search time even when the model’s internal calendar is stale.
2. Use the Role for grounding rules
The Role governs how the model uses the results it got. Two lines from Perplexity’s prompt guide did more for my accuracy than a page of anti-hallucination warnings. First: “Only answer using the search results provided. If the results do not contain the answer, say so rather than guessing.” Second: require the model to disclose near-misses, such as a similar title or a different year, instead of presenting them as matches. Give the model an honest exit and it takes the exit instead of inventing.
3. Keep example content out of the Prompt Frame
My old prompt illustrated instructions with examples like “cozy fantasy” and “grief and rebuilding.” On Grok those were harmless. On Sonar they became competing search seeds, because the search reads the whole user message. Perplexity warns that pasting example content can pull the search toward the example topic. Few-shot the format if you must, never the content.
4. Stop the model from researching your subject
One run returned a comp list containing the Wikipedia article for Snow White, a retail listing for a book already on the list, and a pirated PDF from a document-sharing site. The cause: my user’s manuscript title sat at the top of the Prompt Frame, and Sonar spent its search investigating the title instead of the market around it. One instruction fixed it: “The book described below is an unpublished manuscript. Do not search for the book itself, its title, or its source fairy tale.” If your tool analyzes something the user provides, firewall that thing from the search.
5. Handle links yourself, because Pickaxe drops Sonar’s citations
The Sonar API returns sources in a separate citations field with every response. Pickaxe currently has a bug where it does not render that field, so your users see [1] markers with no source list. I filed a feature request asking to display the citations array. Until then, two rules: ban numbered citation markers in the output (this suppresses most of them), and only allow URLs the model can reproduce from its search results, with “Link not retrieved” as the honest fallback. Never let it construct a URL from a pattern. A different model on this project fabricated a Goodreads link where the slug looked right and the numeric ID pointed at an unrelated novel. Copy-only rules prevent that class of failure.
6. Make the model quote its evidence
My strongest single rule: a result may only be included if the model can quote a retrieved sentence containing the key fact. For my tool the key fact is the publication year. Before that rule, one run produced seven real books with two wrong years, and both wrong years sat behind vague evidence lines like “the page identifies it as a 2022 title.” Paraphrased evidence correlates with errors. Quoted evidence forces the model to hold a real source in hand.
7. Teach it to search again before giving up
Strict evidence rules create a new failure: the model finds a strong result, cannot see the year in the snippet, and drops it. One of my runs excluded two excellent books for exactly that reason. The fix is a second-search rule: “Before excluding an otherwise strong candidate for lack of a quotable year, search again for that book’s publication year. Exclusion is the last resort.” Reasoning-tier Sonar models execute this well, since they can run more searches inside one request.
8. Forget Actions
Actions never fire on Sonar models. I wired up Get Current Time with a trigger prompt and instructions in the Role, following the usual two-places advice, and Message Insights showed “No actions used” on every run. Sonar has no function calling. Hardcode what you need, or phrase it in relative terms the search can resolve, like “within six years of the current year.”
9. Expect variance and design for reruns
Each Sonar request explores one neighborhood of the web. Run the same inputs three times and you get three different, honest, partial answers. On one manuscript, run one found a 2013 literary novella and an obscure 2024 small-press title, run two found the romance shelf, and run three found the military fantasy shelf. The union of those runs is an excellent answer. At 3 cents a run, I stopped fighting this and built it in: the tool’s output ends by inviting the user to reply “find more comps,” and the Role instructs follow-up turns to search fresh and never repeat a title. On a Form plus Chat tool, the Role persists across turns and each message triggers a new search, so results accumulate.
10. Pick your Sonar tier by failure mode
sonar-pro gave me more results per run with occasional sloppy years. sonar-reasoning-pro gave me fewer results with verbatim evidence, live links, and zero factual errors across two straight runs, and it cost less in my tests because it wrote shorter output. Reasoning adds 15 to 40 seconds of think time before the first token. If your tool’s output feeds decisions where a wrong fact costs your user money or credibility, take the reasoning tier and use rule 7 to fix its caution.
Cost comparison from my logs
The same task on Grok 4.5 with a search action cost $2.81 and ran 7 minutes, because every tool call re-sends the full conversation, and a large uploaded document gets billed on every round trip. Gemini Flash cost $5.85 on the same task and fabricated a link. sonar-pro ran $0.06 to $0.11 in 20 to 60 seconds. sonar-reasoning-pro ran $0.03 in 40 to 70 seconds. Sonar has no tool loop, so a big upload gets billed once instead of six times. If your Pickaxe accepts document uploads and needs web search, that difference dominates your economics.
Results
The old version of this tool drew user complaints that most of its recommendations were fabricated titles labeled as verified. The rebuilt Sonar version has now produced consecutive runs where I hand-checked six of six titles, authors, and years against live retail and publisher pages without finding one error, and the per-run cost dropped to about one percent of the Grok build. The model did not change between my worst run and my best run. The prompt did.
Happy to share field-level details if anyone wants them. Ask away.