Summary: Parallel’s April 2026 Task API Harness has the model write Python for a sandboxed interpreter, keeping intermediate data in persistent variables and reporting Ultra results up to 82% on DeepSearchQA. The comparison suggests that context and data-flow engineering can matter as much as a model change, but the figures are Parallel’s own, tied to a specific causal-chain benchmark and not a promise for every workload.
Deep research agents run into a basic constraint: every search, extraction, and reasoning step pushes raw material into the model’s context window. Twenty steps of this can eat 128K tokens, and the model ends up devoting more capacity to re-reading stale results than to actually thinking. A Parallel blog post from April 2026 lays out a different architecture: rather than a tool-calling loop, the agent writes Python and runs it inside a sandboxed interpreter. Intermediate data lives in the interpreter’s variables instead of the conversation history. The payoff: a 20-step research task that would swamp a 128K context window under tool calling comes in below 30K tokens.
What the Benchmarks Show: Accuracy and Cost
Parallel reported figures on Google’s DeepSearchQA benchmark, which strings together 900 multi-step information-seeking questions across 17 fields. The questions form causal chains — the second part cannot be answered until the first is resolved. Accuracy is counted only when an answer is “fully correct”: semantically identical to ground truth. The headline results:
| Provider | Model | Cost (per 1K requests) | Accuracy |
|---|---|---|---|
| Parallel | Ultra 8x | $2,400 | 82% |
| Parallel | Ultra 4x | $1,200 | 81% |
| Parallel | Ultra 2x | $600 | 77% |
| Parallel | Ultra | $300 | 70% |
| OpenAI | GPT-5.4 with code execution | $701 | 63% |
| Gemini 3.1 Pro with code execution | $707 | 62% |
A caveat: these figures come from Parallel itself. Cost per 1,000 requests (CPM) sits on a log scale. The Opus 4-6 entry ($36,231 CPM) is skewed by a possible Anthropic billing issue in which prompt caching savings may never reach users. Read them as a picture of Parallel’s product positioning, not a promise for every workload — real-world outcomes vary with source quality, answer format, and latency requirements.
Inside the Code Execution Approach
The standard agent loop goes like this: the LLM picks a tool, the tool returns content, the LLM picks again. Parallel’s Task API Harness breaks that pattern by having the model author Python code that calls research tools as ordinary functions. The code runs in a sandboxed interpreter built on Rust with no network, filesystem, or OS access, and only each code block’s final output flows back into the model’s context.
Example: Tracking Revenue Year by Year
Take a query that compares Company X’s revenue from 2020 to 2024. Under a standard agent loop, context balloons at every step:
Step 1: search("company X revenue 2024") → [5 results in context]
Step 2: extract(url_1) → [full page content in context]
Step 3: extract(url_2) → [full page content in context]
Step 4: search("company X revenue 2023") → [5 more results in context]
...context grows with every stepUnder Parallel’s approach:
# First, use one search step to discover the URL pattern.
results_2024 = search("Company X 2024 annual report")
report_2024 = results_2024[0].url
# e.g. https://investors.companyx.com/financials/annual-reports/2024-annual-report.pdf
# Infer a reusable template from the 2024 URL and a parse function parse_fn.
url_template = "https://investors.companyx.com/financials/annual-reports/{year}-annual-report.pdf"
years = [2022, 2023, 2024]
reports = {}
for year in years:
url = url_template.format(year=year)
reports[year] = parse_fn(extract(
question=f"What was Company X's reported revenue in {year}? Return the value and supporting quote.",
urls=[url],
))
return reportsSearches, extractions, and analysis all fold into a single execution step. The page content in full — potentially tens of thousands of tokens — never reaches the research agent’s context; only the extracted revenue figures come back.
Persistent State as Working Memory That Survives
Variables defined in one execution step remain available in the next. When the model stores findings["report"] = report_2024 during iteration 3, that value is still within reach at iteration 7, when revenue gets cross-referenced against employee headcount. The separation is the point: the conversation history holds high-level reasoning, while the interpreter’s variable state holds raw data. The conversation can be compacted without granular details going missing.
Letting the Budget Steer Execution
The system follows cumulative cost across iterations — both the orchestrating model and any sub-model calls. Once remaining spend falls below a threshold, budget warnings get injected, nudging the model to synthesize its findings and deliver a final answer. Difficulty sets the pace: easy queries may close out in 2 iterations costing cents, while complex multi-source comparisons stretch past 15 iterations. Higher-priced Processors (Ultra 2x, 4x, 8x) come with larger budgets, leaving room for more research paths before synthesis.
Compaction When Context Runs Low
Code execution keeps intermediate data out of context, but long research sessions still pile up history: reasoning, code blocks, and execution summaries. As context nears its limits, Parallel runs compaction — a summarization pass that shrinks earlier turns while keeping key findings and the current research trajectory intact. The interpreter’s persistent variable state is untouched, which allows far more iterations than the raw context window would seem to permit.
A Sandbox You Cannot Skip
Granting a model the ability to run code introduces risk. Parallel answers with a Python runtime built on Rust that exposes no network, filesystem, or operating system; code touches the outside world only through explicitly injected functions — search, extract, and a small set of state-management utilities. That boundary is what makes the design defensible: the model can express filtering, aggregation, and conditional logic while side effects stay boxed inside the platform’s stated tool surface. Wire arbitrary code execution straight into a production agent and the likely result is not a more capable agent but a wider attack surface.
Who Uses It, and How
Teams at Opendoor, Attio, Modal, and elsewhere run Parallel’s Task API in production. Deep research takes one simple API call:
import parallel
client = parallel.Client(api_key="your-api-key")
task = client.task_runs.create(
objective="Identify every researcher who co-authored papers "
"with Dr. Maria Chen at Stanford, MIT, and Caltech "
"between 2010 and 2020, then determine which of those "
"co-authors later joined the NIH Advisory Committee "
"to the Director.",
processor="ultra8x",
)
print(task.output)Processors span Lite (basic lookups, $5/1K) up to Ultra8x (hardest deep research, $2,400/1K). The architecture targets multi-step searches, document comparison, and data aggregation — the jobs where context management decides the outcome.
Limits and Trade-offs to Weigh
-
Sandbox constraints: The Python sandbox offers no network, filesystem, or OS access. Interaction happens only through the injected
search,extract, and state management functions. The security boundary is necessary, but it also rules out arbitrary libraries and tools. -
Benchmark specificity: DeepSearchQA questions are causal chains. Results on other research shapes (summarization and fact-checking, for instance) may not match. The numbers are self-reported by Parallel and still need independent validation.
-
Cost scaling: Ultra 8x runs $2,400 per 1,000 requests — right for high-value research, hard to justify for high-volume, low-complexity work. Cheaper tiers trade accuracy for economics.
-
Model dependence: The whole technique rests on the model writing correct Python. Buggy code means the sandbox can return errors or incomplete results.
The Takeaway: Keep Reasoning State and Data State Apart
The lesson in Parallel’s design is that agent quality often moves further when you engineer how data flows than when you swap models. For any agent doing multi-step research or data extraction, put three questions to your setup:
- Does every tool output land directly in the LLM context?
- Can intermediate results be kept in a structured state (variables, a database) outside the conversation?
- Is the execution environment isolated enough to allow programmatic tool use without risk?
Solving those engineering problems — context compaction, persistent state, and sandboxed code execution — can outperform an upgrade to a bigger model. Parallel’s 82% accuracy on DeepSearchQA is not only about the model; it reflects keeping the model busy with reasoning instead of hauling raw data.