Enrich any number of entities in parallel with real-time progress tracking, automatic multi-model fusion, and export to JSON or Excel — bounded only by your plan's usage quota, not a fixed batch size.
Rows enter through the source strip above the grid — three tabs, one open at a time. Loading rows collapses the strip to a single line (“Paste / CSV · 12 rows loaded”) so the grid keeps the height; click that line to load a different set.
Paste rows straight out of Excel, Google Sheets or a CSV export. Comma, tab and semicolon are all understood, a quoted cell may contain the delimiter, and a first row of non-numeric names is taken as the column headers.
Drop a .csv, .tsv or .json file onto the tab, or pick one from disk. A JSON file may hold an array of objects or a single object; the columns are the union of their keys, so ragged records still load.
Fetch entities from any REST endpoint. Whatever comes back is read as a list of free-form objects, and the column set is the union of their keys.
Supported authentication:
If the API returns an object, the system checks keys like data, results, items for an embedded array.
After loading entities, they appear in a selectable list with validation status. You can choose which entities to include in the batch:
The sidebar mirrors the single enrichment configuration options:
| Option | Description |
|---|---|
| Schema | Target schema that defines the enrichment output structure |
| Strategy | Single pass, expert domains, or multi-expertise (parallel calls per domain) |
| Models | One or more AI models to run per entity. Multiple models enable automatic fusion. |
| Languages | Languages for multilingual field enrichment (e.g., English + French) |
| Classification | Optional fast model for entity type verification before enrichment |
| Arbitration | Model for LLM-based conflict resolution during fusion. If unset, rule-based merge is used. |
The estimated cost sits in the run bar, next to the button that spends it. It is calculated from your schema's property count, the selected models' token pricing, and how many entities you selected. With automatic model selection the model is only chosen when the run starts, so the figure shown is a median of the models it could pick. A confirmation dialog appears when the run carries a real risk — it writes to a linked database, the estimate is large, or selected rows will be skipped — rather than on every run.
All selected entities are processed simultaneously. Each entity goes through the full enrichment pipeline independently:
All entities share the rate budget of each API key and model — the requests and tokens per minute the provider grants that key, read from its responses or learned from a rejection. With 20 entities and 2 models, the calls to a model that allows 15 requests a minute are spread across the minute while the other model runs at its own pace, so the batch completes without 429 errors.
Starting a run opens a run strip between the toolbar and the grid, fed by Server-Sent Events (SSE): one progress bar for the batch, done / failed / skipped as separate counters rather than one blended number, elapsed time with an ETA derived from the rows that have already settled, and spend so far against the pre-flight estimate. Nothing opens over the grid — the rows stay where you left them, and each one carries its own state in the Status column beside the Time and Cost it took.
The row has not been through a run yet — the Status cell shows a dash rather than repeating itself down the column.
Admitted to the batch, waiting for room in the key's rate budget.
The label gives way to an inline bar counting the expertise steps finished out of the total.
Every model returned. Time and Cost fill in, and the Result columns become readable.
No model produced a result for this row. Once the batch stops, the strip offers to retry just the failed rows.
Discarded before enrichment — a confident classification mismatch, for instance — so the row never cost anything.
The toolbar's Done / Failed / Skipped chips filter the grid to those rows, and the Input / Both / Result switch shows the same rows as what you sent, what came back, or both side by side.
You can cancel a running batch at any time. Cancellation is cooperative — entities already in-flight complete their current LLM call, but no new calls start. Partial results from completed entities are preserved.
Batch processing is designed to be resilient. Individual failures do not stop the batch:
After batch completion, export results in three formats. For each entity, the fusion result is preferred if available; otherwise, the best model result is used.
Download the full results as a structured JSON file with all entity data, model outputs, and fusion metadata.
Copy the JSON results directly to your clipboard for pasting into other tools or scripts.
A three-sheet workbook: Results (one row per entity with flattened properties), Summary (batch metadata, models, costs), and Conflicts (per-entity conflict details with resolution reasoning).
| Limit | Value |
|---|---|
| Max entities per batch | No fixed cap — bounded by your plan's usage quota |
| Max entity data size | 50,000 characters |
| Max prompt length | 100,000 characters |
| URL fetch timeout | 30 seconds |