benchmarks/lookalikes
03 · lookalikes

Lookalike Benchmark

What is a company lookalike. A company lookalike is defined as a company that has an identical core business as a given seed company, sells to the same kind of buyers, and offers at least one of the same products or services as the seed company. We are judging company lookalikes on two criteria: an anchor - the company must have an identical core business as the seed company, and sell to the same kind of buyers, and capabilities - the company must offer at least one of the same products or services as the seed company.

How it is measured. Each vendor gets the identical seed, plus the same seed context wherever the endpoint accepts it, and is asked for up to 100 results. Precision@K divides by K, not by how many results came back, so returning fewer than K lowers the score. Scoring is done by an LLM panel because there is no ground truth list to check against. So every returned company goes to three models from independent labs (majority(n=3): claude-opus-5,gpt-5.6-terra,kimi-k3) under one fixed prompt with the same seed context.

Vendors benched. 9 providers across 48 B2B seed companies: Seltz, Extruct, Ocean.io, Parallel, Exa, Discolike, CUFinder, PredictLeads, ZoomInfo. Vendors that could not be compared on a single-seed request are listed at [01.b] with the reason for each.

How to pick a provider. Start from what consumes the list, not from the top of a ranking. No provider wins every cutoff, which is why the boards below are split rather than merged into one rank.

  • Short list lookalikes. Only top-of-list precision matters, and depth is irrelevant: ten good companies beat a hundred that are six-tenths right. Read the Precision@10 board.
  • Long list lookalikes. Sequences, ad audiences, and enrichment pipelines consume the whole list, so relevance has to hold at the bottom of it. Read the Precision@100 board.
  • In a product path. A similar-companies lookup called on page load is bounded by latency. Choose on speed only among providers whose top ten is worth showing.
  • Cost-bound at volume. Compare judged-relevant companies per dollar at the depth you will actually consume. Per-request and per-result pricing rank differently depending on how deep you read.

2026-09-02 Seltz added to the board, last judged 2 Sept 2026. Full changelog →

open data + codeEvery cell on this benchmark is reproducible from a literal HTTP envelope + LLM judge prompt committed in openbenchmarks-labs/lookalikes · verify any number end-to-end.github →

Measured results

Two boards, because deep relevance and top-of-list relevance are different products and the same vendor rarely wins both. Numbers only, no interpretation.

long listPrecision@100: how relevant a vendor stays a hundred companies deep. The metric for lists that feed automated sequences. 3 vendors cannot appear here: their endpoint returns fewer than 100 results.
Long-list lookalike quality: aggregate Precision@100 by company lookalike API vendor
RankVendorPrecision@100Avg latencyRelevant / $1 at 100
1Seltz63.4%4,835 ms12,683
2Extruct61.1%2,361 ms624
3Ocean.io59.5%2,444 ms37
4Parallel56.9%2,680 ms11,383
5Exa48.6%3,014 ms501
6Discolike34.6%1,164 ms66
short listPrecision@10: how relevant the top of the list is. The metric that matters when a person works the results by hand and only the first few rows get touched. Every measured vendor appears here, and the only question asked of them is whether the companies are right.
Short-list lookalike quality: aggregate Precision@10 by company lookalike API vendor
RankVendorPrecision@10
1PredictLeads89.8%
2Seltz84.4%
3Exa80.8%
4Extruct75.0%
5Ocean.io74.3%
6Parallel69.2%
7ZoomInfo67.1%
8Discolike41.9%
9CUFinder38.9%
[02] methodology and metric definitions+

How the matrix is built

  1. Fix a canonical list of 48 seed companies across 13 verticals. Each seed has a name, domain, and short description - the benchmark seed context used by every runner.
  2. For every (seed, vendor) cell, call the vendor's lookalike API with K = 100. Capture the ordered top-K result list and credit cost.
  3. Feed the seed + each returned candidate to the LLM judge (majority(n=3): claude-opus-5,gpt-5.6-terra,kimi-k3, high reasoning effort). Judge returns a binary relevance label per candidate plus a one-line rationale. Identical prompt and rubric across all vendors.
  4. Persist Precision@10 and Precision@100. Aggregate per vendor as avg_precision_at_10 and avg_precision_at_100.

What each metric means

  • Precision@10/100 · relevant results in the top N ÷ N. The denominator is the fixed cutoff - not how many the vendor returned - so returning fewer than N, or padding with junk, both lower the score.
  • avg Precision@100 · headline comparison metric. Mean Precision@100 across all judged seeds. Higher is better.
  • relevant companies / $1 · average judged-relevant companies inside the cutoff ÷ what one request costs at that same cutoff. Both halves are evaluated at the same depth, so the figure describes the list being scored beside it. Shown on the long-list board only, since that is where a list is bought and consumed whole. Rates use the linked public price or the verified Ocean.io account rate, and per-result charges are capped at what the vendor actually returned. Example: Parallel averages 56.9 relevant companies in a 100-result list at $0.005, so 56.9 ÷ 0.005 = 11,383.

Why an LLM judge panel instead of a hand-labeled set

A fully hand-labeled lookalike set would require labeling K × seeds × vendors candidates (100 × 48 × 9 = 43200 judgements) every time we re-run a snapshot. That doesn't scale, and it isn't how the buyer actually evaluates a vendor - the buyer reads the list and decides if it is close enough to their ICP.

The panel is three models from three independent labs - Claude Opus 5 (Anthropic), GPT-5.6 Terra (OpenAI), and Kimi K3 (Moonshot AI, open weights). Different families matter: models from one lab share training data and post-training, so they tend to share blind spots. A candidate is relevant by strict majority.

The judge is shaped by the input. Each vendor is handed the same two-part definition - an anchor it must match and capabilities it may match - so the scorer has to test those two things specifically rather than form a general impression of similarity. That is why the rubric is a gate plus a check rather than a single holistic score, why the anchor is decided before the verdict, and why the final label is computed from the structured answers instead of being taken from the model.

The rubric follows the same split as the query. First the anchor, as a hard gate: is this candidate the same kind of company, for the same kind of customer? A candidate that fails it is not a lookalike however many capabilities it shares. Then capability overlap: which of the seed's capabilities does it also do? A candidate is relevant when it clears the anchor and shares at least one. The anchor does the great majority of the work in practice - capability overlap changes the outcome for well under two percent of candidates - so read it as an anchor test with a capability check rather than two equal stages. Each judge decides the anchor before the verdict, and the final label is re-derived from those two fields rather than taken from the model, so the gate is enforced rather than suggested. Every judge's rationale and vote is persisted alongside the label, so any cell can be audited by a human in seconds.

How Exa and Parallel are queried

Domain-first providers receive a company domain, which is unambiguous. Exa and Parallel take natural language instead, so the wording is part of the test and is written down rather than improvised. Each seed has one hand-authored query, and Exa and Parallel receive the identical string - that identity is what makes the two comparable. Seltz also takes a natural-language query, but not that shared string: its input follows the runner they submitted in lookalikes PR #8. See [02.e].

The query states the two halves of the lookalike definition separately, because the judge scores them differently:

  1. Anchor - who the seed sells to and what it fundamentally is. A hard requirement: every lookalike must be the same kind of company for the same kind of customer.
  2. Capabilities - what the seed does, joined by any of. A lookalike needs at least one, not all of them.

Which gives the shape Find companies similar to {Company} ({domain}): {anchor} that offer any of {capabilities}. Return companies a buyer would realistically evaluate alongside {Company}. - for Toast that is Find companies similar to Toast (toasttab.com): restaurant point-of-sale platforms that offer any of payments, online ordering, payroll, or inventory management. Return companies a buyer would realistically evaluate alongside Toast.

The seed is the subject, anchored by name and domain - the same company the domain-first providers receive. What the query does not do is rank, weight, or define similarity beyond that split: finding companies that fit is the vendor's job, and is what the benchmark measures. Every seed's query is published in the per-cell audit trail alongside the response it produced. If the query returns zero candidates, one concise fallback is retried.

Each provider runs one fixed query per seed. Earlier snapshots swept three phrasings per seed for these two vendors and kept the best-scoring one; that sweep has been retired, so the published figure is a single query's result rather than a per-seed maximum.

How each vendor was queried

  • Ocean.io · /companies/lookalikes with seed domain. Default similarity model, K = 100.
  • Exa · /search with category: company and the seed-first query Find companies similar to HubSpot (hubspot.com), the CRM and marketing automation platform. Return companies a buyer would realistically evaluate alongside HubSpot., K = 100.
  • Parallel · FindAll Entity Search API, POST /v1beta/findall/entity-search, with the seed name, description, and an explicit similar-product-and-buyer objective, K = 100.
  • Seltz · POST /v1/search with scope: companies and max_results: 100. The query is not the shared Exa/Parallel seed.query. It is composed from the seed's authored anchor and capabilities as {anchor} for {cap1}, {cap2}, ..., and {capN}, matching the runner in lookalikes PR #8. For Toast that is restaurant point-of-sale platform for payments, online ordering, payroll, and inventory management.
  • PredictLeads · /api/v3/companies/{domain}/similar_companies; ranks via shared tech, news, and jobs co-signals; returns at most 25 results, so it is scored at Precision@10 only.
  • Extruct · /v1/companies/{domain}/similar, K = 100.
  • CUFinder · /v2/fcl with the seed domain; the endpoint returns at most 10, so it is evaluated through Precision@10.
  • Discolike · /v1/discover with the seed domain and max_records=100.
  • ZoomInfo · gtm companies similar --name "{seed}", run through the ZoomInfo GTM CLI rather than an HTTP API, so this vendor's audit trail records a command invocation instead of a request envelope. Queried by seed name, not domain. The endpoint returns a fixed, non-paginated top 25, so it is scored at Precision@10 only. Its results carry no website and no description: each is a company name plus ZoomInfo's own attributes (industry, country, revenue band, headcount band) and a similarity score. The benchmark records what the endpoint returned and does not enrich the candidates in a second call, so the judge sees less context here than for vendors that return a domain and a description.

Verify any number end-to-end

The full benchmark - runner code, judge prompt, benchmark snapshot, and per-cell raw audit trail (the literal HTTP request/response we sent each vendor + the literal LLM judge prompt/response per candidate) - is mirrored in a public repo: openbenchmarks-labs/lookalikes. Auth headers are scrubbed via an allow-list; everything else is verbatim.

To audit a single cell, open data/lookalike-runs/<dataset>/<seed>/<vendor>.raw.json in that repo and replay any of the vendor_calls[] with your own credentials, or re-score with your own LLM by replaying judge_calls[].messages against any OpenAI-v1 compatible model - useful for measuring judge bias or drift across model versions.

What this benchmark does not tell you

A number is only usable if you know what it excludes. Everything below is a real limit of this benchmark, stated so you can decide where the ranking applies and where it does not.

Single-seed lookalike, and nothing else

Every cell here is one seed company in, similar companies out. Exa and Parallel are queried in natural language rather than by domain, but that query is built entirely from the seed: the seed named, its domain given, its anchor and its capabilities stated. See [02.d] for the exact shape.

What is never asked is a query carrying constraints the seed does not supply, of the kind “Series B fintechs in New York hiring ML engineers”. Funding stage, headcount, geography and hiring signals appear in no request on this board. So this measures similarity retrieval from a seed, not constrained search, and a vendor built for the second can score poorly here without that saying much about it.

Structured filter and firmographic search is out of scope for the same reason: no request here carries a filter. Enrichment quality, contact data and intent signals are measured on other boards, not this one.

What latency, cost and blank cells actually mean

Latency is measured at benchmark time on an unthrottled path. Read it as a ranking signal between vendors.

Cost is computed from public list prices, so the ratio between two vendors survives a procurement conversation better than either absolute figure does.

Under-filling lowers a score, it does not remove one. Precision@100 divides by 100 whatever comes back, so a vendor that returns 84 companies is scored as though it returned 100 and 16 of them were wrong. Most vendors on the long-list board return fewer than 100 on most seeds and are still ranked there: the shortfall is already inside the number.

An endpoint cap is a different thing. Where a provider documents a maximum below 100, ranking it on Precision@100 would report that ceiling rather than the provider, so it is left off the long-list board instead of shown near zero. The per-cell value still exists in the audit trail; it is the published average that is withheld. Those providers are ranked on Precision@10, where every vendor competes on the same terms.

Ranks are comparable, absolute scores carry an offset

The panel has its own calibration and its own blind spots. They are held constant across every vendor, so vendor-to-vendor rank comparisons are valid, while the absolute Precision@K carries a panel-specific offset. Do not port an absolute percentage from this page into a business case as though it were a hit rate you will reproduce. The reasoning behind the panel design is in the methodology.

Relevance is decided in two stages, and in practice the first one does nearly all the work: a hard anchor gate on what the seed company is and who it sells to, then an optional overlap on what it does. Capability overlap flips well under 2% of verdicts. So this measures “same kind of company, same kind of buyer” far more than it measures feature-level similarity, which is worth knowing if feature adjacency is what you are actually shopping for.

Company lookalike APIs: common questions

Answers that quote a number read it from the board above, so they cannot fall out of step with it.

What is a company lookalike API?

A company lookalike is defined as a company that has an identical core business as a given seed company, sells to the same kind of buyers, and offers at least one of the same products or services as the seed company. We are judging company lookalikes on two criteria: an anchor - the company must have an identical core business as the seed company, and sell to the same kind of buyers, and capabilities - the company must offer at least one of the same products or services as the seed company.

How does Openbenchmarks score company lookalike APIs?

Every vendor receives the same seed company, using whatever input that provider's endpoint expects: a domain where one is required, or the seed name plus a description for semantic endpoints. Each is asked for up to 100 lookalikes. A panel of three LLMs from independent labs then scores every returned company, and a candidate counts as relevant only on a majority vote. The reported numbers are Precision@10 and Precision@100, each shown only where an endpoint supports that depth, plus the total relevant companies returned across the cohort. There is no internal ground truth and no vendor self-reporting. Providers whose request shape, access model or product surface makes a single-seed comparison impossible are listed as not benched, each with the specific reason.

What is the most accurate company lookalike API in 2026?

On identical seed companies, Seltz leads long-list relevance at 63.4% Precision@100, and PredictLeads leads top-of-list precision at 89.8% Precision@10. Those are different products rather than a contradiction: a sharp top ten and a list that stays relevant a hundred rows deep are two different jobs, and which one is "most accurate" depends on whether a human works the shortlist or an automated sequence consumes the whole list. The board covers 9 providers across 48 B2B seeds, judged by one panel held constant across every vendor.

What are the best company lookalike tools in 2026?

Measured on identical seeds, Seltz leads long-list relevance at 63.4% Precision@100, and PredictLeads leads top-of-list precision at 89.8% Precision@10, across 48 B2B seeds and 9 providers. "Tool", "provider" and "finder" all describe the same measured surface here, which is a lookalike API scored on a shared cohort, so the ranking on this page answers all three. Anything whose lookalike quality is a vendor claim rather than a measured Precision@K number is listed as not benched with the reason.

How do I find companies like my best customers?

Take your closed-won accounts as seed companies, send each seed to a lookalike API, and judge the returned lists instead of trusting the rank order you get back. That is exactly the shape of this benchmark: 48 B2B seeds, up to 100 companies returned per seed, and every returned company scored for relevance. The practical lesson from running it is that top-of-list and long-list quality are close to independent. A provider that gives you ten excellent companies is not necessarily the one to use when a sequence needs a hundred, so pick the cutoff that matches how the list will actually be worked.

Is there a free lookalike company finder?

Several benchmarked vendors have free tiers or trial credits, and the setup section on this page notes each one's access model, including which can be signed up for without talking to sales. Free tiers are generally capped in results per request, which matters here because a capped endpoint cannot be compared at depth. The benchmark's own output is free and openly licensed: every number, every returned company and every judge call is published under CC-BY-4.0.

What is Precision@K and how is it measured in this benchmark?

Precision@K is the fraction of a vendor's top-K returned companies that the judge panel scored relevant, so Precision@K = relevant_count / K. The denominator is fixed at K rather than at the number of companies the vendor actually returned. That choice is deliberate and it is the single most important thing to understand about these numbers: a vendor that returns thirty companies when asked for a hundred is scored against a hundred, so under-filling costs it directly instead of being hidden by a smaller denominator. The benchmark requests up to 100 results and reports Precision@10 and Precision@100, each only where an endpoint supports that depth.

[05] changelog+

One vendor added. Existing Precision@K numbers were not re-run.

  • Seltz now appears on the board. It is a companies-scope search API, scored at the same cutoffs as the other K=100 vendors. The published figure is from the same three-model judge panel as every other row.
  • Its query follows their submitted runner. Seltz does not receive the shared Exa/Parallel lookalike sentence. The request body uses the query composition from lookalikes PR #8: the seed's authored anchor and capabilities, joined as {anchor} for {cap1}, {cap2}, ..., and {capN}. That input is documented in [02.d] and [02.e].

One vendor added. No existing number changed.

  • ZoomInfo now appears on the short-list board. Its similar-companies endpoint returns at most 25 results, so it is scored at Precision@10 and is absent from the Precision@100 board for the same reason CUFinder and PredictLeads are: ranking a provider at a cutoff its endpoint cannot reach would report the ceiling rather than the provider.
  • It was re-judged by the current panel before publishing. ZoomInfo had previously been scored by the older single-judge setup. Carrying that number over would have put a vendor graded on one rubric next to seven graded on another, which is exactly the comparison this benchmark exists to make valid. The published figure comes from the same three-model panel as every other row.
  • It is driven through a CLI, not an HTTP API. ZoomInfo's similar-companies surface is reached with gtm companies similar, so its audit trail records the command, its arguments, its exit status and its raw output rather than a request envelope. Reproducing a ZoomInfo cell needs the gtm binary rather than an API key. Sign-up is self-serve at gtm.ai and there is a free tier, so the barrier is the install, not procurement.

Every number on this page was re-measured. Queries, judge, and rubric all changed, so figures below are not comparable with the previous snapshot.

  • Split what a lookalike means into two parts. A seed description like "Restaurant point-of-sale, payments, online ordering, payroll, and operations platform" is really two claims. The anchor - who the company sells to and what it fundamentally is ("restaurant point-of-sale platform") is a hard requirement every lookalike must clear. The capabilities - payments, online ordering, payroll, inventory management - are matched any-of: a lookalike needs at least one, not all.
  • Rewrote the natural-language query around that split, replacing the previous description-led prompt. Exa and Parallel now receive one identical, hand-authored query per seed (see [02.d]).
  • Retired the three-prompt sweep. Exa and Parallel previously ran three phrasings per seed and published the best-scoring one; they now run a single fixed query, so the published figure is that query's result rather than a per-seed maximum.
  • Replaced the single judge with a three-model panel across independent labs - Claude Opus 5 (Anthropic), GPT-5.6 Terra (OpenAI), and Kimi K3 (Moonshot) - aggregated by strict majority vote, ties resolving to not-relevant. Every per-candidate vote is kept in the audit trail.
  • Rewrote the judge rubric to match the split. The judge decides the anchor first, then capability overlap, then the verdict; the final label is re-derived in code from those two fields rather than taken from the model, so the anchor is a hard gate rather than a suggestion.
  • Vendors whose input did not change (Ocean.io, Extruct, Discolike, PredictLeads, CUFinder) moved by at most three points under the new judge, which is the evidence that the judge change itself is close to neutral.
  • Expanded the seed cohort from 24 to 48 companies across the same seven providers.
  • Added Extruct, CUFinder, and Discolike.
  • Reworked the reported cutoffs. CUFinder returns at most 10 results and PredictLeads at most 25; other providers are measured through 100 where results are available.
  • Added a shared post-fetch duplicate check before scoring. Repeated companies count once, and each run records how many duplicates were removed.
  • Updated the judge rubric for the actual lookalike task: candidates must share a core product and buyer. Size, geography, funding, and maturity are not relevance constraints.
  • Rejudged all returned candidates with gpt-5.6 at high reasoning effort.
  • Exa and Parallel use the documented three-prompt natural-language sweep, retaining the best judged prompt per seed.
  • Added relevant companies per $1 at each provider's tested maximum list depth, using verified plan or account rates.

Agent sign-up and use instructions

Not a ranking - the practical setup for pointing an agent at each vendor's lookalike / company search: what to call (MCP or API), how to authenticate, and the credits.

benchmarks/lookalike/agent-usage9 vendors · mcp + api
mcp
toolsearch_companies
authX-Api-Token — requires human key setup
credits0.2 credits / result · paid
mcp docs ↗
api
POST /v3/search/companieshuman key
authX-Api-Token
creditsaccount credits · paid
api docs ↗
mcp
toolno company search
authkeyless
credits
mcp docs ↗
api
POST api.exa.ai/search · category: companykey
authx-api-key from dashboard
credits$20 credits on sign-up · $10 free credits / mo
x402keyless pay-per-call — this /search call is x402-payable
api docs ↗
mcp
toolno entity search
authAPI key required
credits
mcp docs ↗
api
POST /v1beta/findall/entity-searchkey · free tier
authx-api-key from dashboard
credits16k free requests
x402pay-per-call via MPP gateway parallelmpp.dev · ~$0.01/req
api docs ↗
mcp
toolsearch · wraps POST /v1/search
authAPI key (Authorization: Bearer)
creditspay as you go $5 / 1,000 requests
mcp docs ↗
api
POST api.seltz.ai/v1/search · scope: companieshuman key
authx-api-key from dashboard
creditspay as you go $5 / 1,000 requests · public pricing at docs.seltz.ai/pricing
api docs ↗
mcp
toolunverified · key-gated
authX-Api-Key + X-Api-Token — requires human key setup
creditsplan-based
mcp docs ↗
api
GET /api/v3/companies/{domain}/similar_companieshuman key
authX-Api-Key + X-Api-Token
creditsplan-based
api docs ↗
mcp
toolcompany lookup, search, and lookalikes
authExtruct account sign-in (OAuth)
creditsplan-based
mcp docs ↗
api
POST /v1/companies/{domain}/similarhuman key
authBearer API token
creditsplan-based
api docs ↗
mcp
toolB2B company intelligence
authCUFinder API key
creditsGrowth plan · API units
mcp docs ↗
api
POST /v2/fclhuman key
authx-api-key
credits5 credits / returned record
api docs ↗
mcp
toolcompany discovery and enrichment
authDiscoLike account sign-in (OAuth)
creditsplan-based
mcp docs ↗
api
GET /v1/discover?domain={domain}human key
authx-discolike-key
creditsStarter plan
api docs ↗
mcp
toolno MCP server; the lookalike surface is CLI-only
authn/a
creditsn/a
api
gtm companies similar --name (GTM CLI, not HTTP)cli
authself-serve sign-up at gtm.ai, then the gtm CLI on PATH
creditsfree tier available · public pricing at gtm.ai/pricing
agent self-serve - the agent obtains its own key (OTP), no humankey · free tier - human self-serve key, free tier / x402human key - a person provisions a key/token; paid / gated

Per-vendor breakdowns, head-to-heads, and the guide

Drill into how any one vendor scored, compare two side by side, or start with the explainer - every page is built from the same live benchmark data.