Job cost (EF)

EF is outsend's cost unit. It is estimated as a range before launch, never exceeds the per-job ceiling, and measures what proxies and the browser actually consume.

Every job carries a cost expressed in EF. This page explains what EF means, why you see a range instead of a single number, the guarantee that you never overshoot, and what actually drives the cost.

During the alpha, everything is free. EF exists today to calibrate the perception of cost before commercial opening, so the unit and its scale already appear everywhere in the product.

What EF means

EF = "France-equivalent". 1 EF = scraping the whole of France, once, for one query.

So 1 EF is a lot. A single city or region costs a small fraction of an EF; the whole reference baseline is one full pass over France. EF is a reference scale, not a currency: it lets you reason about the size of a job at a glance, independent of any price. France is only the yardstick — you can scrape any of ~199 countries, and a country larger than France simply costs several EF (a smaller one, less than 1).

The baseline is measured from the real scrape grid, so a zone's cost reflects the number of map points it actually covers — which is also what drives scrape time.

Why a range [low – high]

You don't know how many results a zone holds before running it. A dense area returns far more listings than a sparse one, and the scrape subdivides saturated tiles to dig deeper (see Scrape modes). The same zone can therefore cost very differently depending on density.

So before launch outsend estimates a lower bound and an upper bound:

• Low — what the job costs if nothing saturates (sparse case).
• High — the worst case, equal to the ceiling the job is allowed to reach.

The launch form shows this range live; it widens as you add queries, enlarge zones, or pick a deeper mode.

The guarantee: decided at launch, never stopped midway

The check happens before launch: a job or pipeline can only start if its high bound fits under your EF ceiling. If the high estimate is above your ceiling, the launch is refused — reduce the pipeline (zones, queries or steps) or raise your ceiling in Settings.

Once launched, it runs all the way to the end — never paused, capped or truncated midway. No half-scrapes, no partial enrichment. If reality occasionally exceeds the high estimate, that overflow is absorbed (not billed to you), and the estimate tightens over time as real usage is measured.

Fair by design: overruns are on us

What you're charged is capped at the high estimate shown before launch. If a job ends up costing more than predicted — typically a large job on a denser-than-expected area — the overage is on us, not you. You never pay above what we quoted.

In other words: we cap the cost, not your results. Small jobs pay their honest small cost (tools are free, products almost nothing), and large jobs are never inflated past the estimate. We don't make small jobs subsidize big ones — it's the opposite: the gap is absorbed on the big jobs.

The per-job EF ceiling

The ceiling is per user and adjustable:

Set it in Settings. Leave it on the default and a single job stays well-sized; raise it when you knowingly want one large job instead of splitting the work. The server clamps any value to [0.1, 50].

What actually costs

The real cost is proxies (and the headless browser). Jobs that use neither cost little or nothing:

Cost is measured per job, and the estimate gets sharper over time as real runs feed continuous calibration. The figures above are relative orders of magnitude, not fixed prices.

Good to know

• EF is a size/cost scale, not money. In alpha nothing is billed.
• The range is the pre-launch estimate; the high bound is what's checked against your ceiling at launch. Once launched, the run always completes in full.
• import and other pipeline-internal moves consume no EF.
• Deeper scrape modes raise the estimate because they fire more requests — see Scrape modes.

What's next

• Scrape modes
• Limits & quotas
• Jobs & lifecycle