Scale and batching
One call per list, never one call per row. Batching tiers, the 1000-row cap, worker concurrency, and how to size a run before starting it.
One call per list, never one call per row. Looping a single-entity command over a list is the single most expensive mistake available in this CLI — it burns time, rate budget, and context for no gain.
eximagent enrich company --inputs companies.ndjson
One call in, one streamed batch result out, one context fill.
Sizing a run
| Rows | Approach |
|---|---|
| 1–10 | Single call, or bulk — either is fine |
| 10–50 | Bulk only |
| 50–200 | Bulk, and shortlist before touching contacts |
| 200+ | Bulk, with aggressive shortlisting first |
The shortlist step is what keeps a large run affordable. Contact discovery across an unfiltered 200-row list spends most of the budget on companies you were never going to contact.
Hard caps
- 1000 rows per
--inputscall. Above that the call fails withINVALID_ARG; split into sequential bulk calls. - 25 server-side workers. Passing a higher
--concurrencyis silently clamped, and thestartedevent reportsconcurrencyClamped: true. - Default concurrency is 10 and reduces automatically under upstream rate pressure.
Long runs
Bulk enrichment over 200+ rows, and any confirmed search run, can take
several minutes. The client timeout defaults to 180s — raise it with
EXIMAGENT_TIMEOUT_MS or re-run with --stream to watch progress live.