Evaluate Parallel Search

Turn the user's workload into a reproducible end-to-end comparison. Deliver a runnable harness when implementation is requested, or an actionable plan when planning is requested. Reuse an existing harness before creating another one. Do not invent a Parallel CLI eval command.

For product selection without a benchmark, use choose-your-parallel-api; for replacing an existing search integration, use migrate-to-parallel. Use this skill to measure the resulting quality, cost, and latency.

Start with the workload

Read the public evaluation guide, Search best practices, and Extract best practices before implementing requests. Check current modes and pricing; record the documentation date and configuration rather than embedding price or latency promises.

Establish the application, question types, providers, existing agent/model, verified answers, and quality/cost/latency target. Infer these from supplied code and data; ask only for missing decisions that change the comparison. Prepare offline artifacts while credentials or a live-run budget remain unresolved. Use existing authorization for paid calls; otherwise establish scope and spend limits before execution. Never request keys in chat.

Choose the product that matches the application: