Parallel Decisions API tested: what web-grounded decisions get right, and where they fail with confidence
Parallel's Decisions API searches the live web and returns typed answers with probabilities and sources in one call. We ran eight test calls against facts we had checked. It was right on stable facts, misled by richer subject descriptions, and wrong at 0.999 on a version change three weeks old.
BY MEI LIN · FDEINTERVIEWS EDITORIAL · UPDATED NOVEMBER 3, 2026 · 7 MIN READ
PRACTICE THIS:Web-grounded decisions, the concept ·Design it: a nightly CRM refresh with web decisions ·Evaluate it when the truth moves
Parallel's Decisions API puts a web search and a typed decision in one call: you describe a subject, ask up to 100 yes/no, multiple-choice or scored questions, and get probabilities plus the pages it read, typically in under a second. We tested it on eight calls against facts we had checked at the source the same day. On stable facts with an easy-to-find primary source it was right every time. A more detailed description of the subject made one answer wrong. And on a fact that had changed three weeks earlier, it was wrong at 0.995 and then at 0.999, with real citations, because many secondary pages repeated the old answer. That is the shape of the tool: excellent at what the web agrees on, and confidently wrong when the web lags. Below: what it is, what we measured, what the launch claims do and do not show, and how we would use it.
What it is
The request has two parts. state describes the subject as JSON, such as a company name and website. questions names each question and gives it a type:
| Type | Asks | Returns |
|---|---|---|
noul | Is this statement true? | A probability from 0 to 1 |
choice | Which of these 2 to 255 named options applies? | The chosen key and a probability per option |
score | Where does the subject sit on 2 to 10 ordered levels? | A probability-weighted position, which can be fractional |
Any question can come back as {"type": "refusal"} instead, which is a successful response, not an error. All questions in one request share one set of retrieved evidence, and the response carries one citations list for the whole call. As of 3 November 2026 the price is $1 per 1,000 requests regardless of how many questions each holds, with a default limit of 600 requests a minute. The same capability is available as a free web_decisions tool in Parallel's MCP server, which is how we ran our tests.
The type names are TypeSafe's. Jev, the decision model TypeSafe released in September, answers the same three question types over the state you supply. The Decisions API adds retrieval in front, so it can answer about things no model was trained on. Parallel's launch post shows one example where Jev, without web access, answered a question about Parallel's own EU data residency incorrectly and the Decisions API answered it correctly. That is a real failure mode for a model with no retrieval, shown on one question.
What we measured
We picked questions whose answers we had verified that day against the primary source: NVIDIA's Auto Ontology repository, TypeSafe's models documentation, and Clay's developer docs. We called web_decisions through Parallel's public MCP server with no API key, from India, and timed each call end to end.
| Test | Result |
|---|---|
| Six questions about Auto Ontology, subject given by name only | All six right; every citation from NVIDIA's repository or container catalog |
The same six, with the vendor name and repository URL added to state | Snowflake support fell from 0.995 to 0.278, a wrong answer. A repeat call returned identical numbers |
Which version TypeSafe's jev-latest alias points to | jev-1.13 at 0.995, citing aggregator pages, cheat sheets and integration docs. TypeSafe's models page says jev-1.14.0, available since 14 October |
The same, with TypeSafe's docs URL in state | jev-1.13 at 0.999. The citations included the docs home page, which names no version, but not the models page |
| Does Clay offer a CLI, by name only | Right at 0.995, but the sources included a different project's claycli repository and an unrelated Rust crate named clay-cli. With the website added, the namesakes dropped out |
| A fact the web does not record, asked two ways | As a noul, 0.049, which a threshold reads as false. As a choice with unknown, 0.988 on unknown |
Calls took 0.76 to 1.03 seconds including the MCP round trip, and reported 2,275 to 3,139 input tokens with zero output tokens.
Eight calls is a probe, not a benchmark, and we would not quote an accuracy rate from it. What it does show is where to look. Three behaviors deserve a test in any evaluation you run:
Recency loses to repetition. Three weeks after a version change, most pages about Jev still said 1.13. The evidence set reflected the web's majority, and the probability reflected the evidence set. Calibration cannot fix this, because the model was well calibrated about what it read. Pointing state at the official docs did not steer retrieval to the right page.
The subject description is part of the system. Adding the vendor and repository URL should have helped. It changed which pages were retrieved and moved one answer from right to wrong. Treat the state template like a prompt: version it and evaluate it.
Namesakes slip into the evidence. The Clay answer was right, so a spot check would pass. The evidence still included two unrelated projects with the same name. On a less famous company the namesakes might outnumber the real one.
Reading the launch claims closely
Parallel's launch post reports a perpetual know-your-business engine that rechecked 426 public companies in under ten seconds for 85 cents, with 98 percent of its flags holding up, and a lead router that ran 500 inbound leads, with 97 percent of the leads it routed on its own landing in the right segment. Both are Parallel's own demos, and the post does not describe how correctness was judged. The post also says the API runs at "10x lower cost than a standalone model" without naming the model. None of that makes the claims wrong. It makes them a reason to run your own test rather than a substitute for one.
The docs, by contrast, are unusually candid about limits, and their warnings match what we found: do not treat missing evidence as false, handle refusals as their own outcome, and group questions about one entity in a request rather than mixing entities.
How we would use it
Use it for bulk checks of public facts that change slowly and are widely reported: firmographics, product features, whether a company still operates, whether a policy is in force. Those are the cases where the web's majority is usually right, and $1 per thousand subjects makes nightly refreshes cheap.
Make every gating question a choice with an explicit unknown option, and never let unknown or a refusal change a record. Put an identifier in state, such as a domain, and check that at least one citation comes from the subject's own site before you write a change. Store the decision ID, probabilities and cited URLs with every write so you can explain it and undo it.
Do not use it for facts that changed recently and have one authoritative page, such as current versions, prices or leadership. Fetch that page yourself and pass its text in state, or use Parallel's Search API and decide over the passages you chose. Do not use it where an auditor will ask which source supported which field, unless each field gets its own request. And do not batch unrelated companies into one call to save money, because their answers would share evidence.
The one-sentence version for a design review: the probability is the model's belief given the pages it found, so the work is making sure it finds the right pages, and catching the cases where the web itself is behind.
Turn it into offers. Work the real questions and concepts this maps to:
FAQ
A Parallel Web Systems API, launched in late October 2026, that takes a subject and up to 100 typed questions, searches the live web once, and returns an answer for each question with probabilities and a list of cited sources. Question types are noul (probability a statement is true), choice (one of 2 to 255 named options) and score (a position on 2 to 10 ordered levels).
As of 3 November 2026, $1 per 1,000 requests, with up to 100 questions in each request, and a default limit of 600 requests per minute. It is also available as the free web_decisions tool in Parallel's MCP server, with higher limits after signing in.
TypeSafe's Jev answers typed questions over the state you send it and does not search the web. The Decisions API uses the same question types but retrieves web evidence first, so it can answer about things that changed after a model was trained. It also inherits the web's problems: stale pages, namesakes and evidence that does not exist.
No. The citations array covers the whole call. If one request asks several questions, nothing in the response says which source supported which answer.
Not safely. Parallel's docs say not to treat missing evidence as proof that a statement is false. In our test, a question the web could not answer scored 0.049 as a noul, while the same question as a choice with an unknown option put 0.988 on unknown.
Discussion (3)
The richer-state result is the one I would have bet against. Teams will write a careful state template once, test two questions by hand and ship it. Run the eval across the templates you will actually send.
Version questions are a good canary for any web-grounded system. A vendor moves a pointer like jev-latest in one docs table, blog posts and cheat sheets keep the old answer long after, and only that one table is authoritative.
Call-level citations are fine for enrichment and a problem for anything an auditor reads. If someone will ask which page supported field seven, put field seven in its own request.