Model repair costs in a recurring job

A careers monitor can visit the same site every morning and reuse its extractor for weeks. When the site redesigns its vacancy cards, one visit may need to repair that extractor. To budget for the next six weeks, start with the charged repairs your job actually saw. Multiplying every planned visit by the price of a repair would charge the same working layout over and over in your forecast.

This guide builds a repair allowance for an existing single-page extraction job. You need its recent run history, receipts from the same workload, and Node 22 to run the example. The example runs offline. If you are planning your first run and have no receipt history yet, start with the pre-run workload estimator.

Identify the repair on a receipt

Read the result of each original successful scrape. A response with meta.tier: "healed" and a positive meta.credits.compile contributes one charged repair to this model. Preserve the compile amount as well as the count so you can reconcile historical spend. A paid network fetch has its own meta.credits.egress field. Adding the total charge on a healed response would put that network charge into your repair budget. Scraipe API reference

Here is a sequence we ran through Scraipe’s local extraction pipeline. A fixture served two versions of a careers page at the same URL, with the same requested field. We bypassed the response cache, supplied a test compiler and measured the test wallet before and after each run. The returned role changed from Engineer to Writer when the markup changed.

The wallet spent two credits. Only the third visit used the repair allowance. Direct model extraction (llm) can also carry a compile charge. Keep it in a separate fallback budget. An empty result or a changed row count alone tells you nothing about the tier that answered. How to read a request receipt

Build a weekly history for one job

Choose a stable workload, such as the same daily watch list, schema and schedule. Save the job identifier, timestamp, original request ID, tier, compile credits and egress credits. Skip responses marked as idempotent replays. Deduplicate duplicate log entries for the same original operation. Two separately charged repairs on the same URL still count twice.

Group the charged heals into consecutive weeks starting Monday at 00:00 UTC. For each week, reconcile the scheduler’s attempted runs with their recorded outcomes. If every outcome is accounted for and none had a charged repair, record zero. If a request timed out and its billing outcome is unknown, resolve it against the original request record. Leave the week incomplete until you can account for it. A week when the job was switched off represents a different schedule and makes a poor baseline for an active job.

Use individual page receipts for this exercise. A multi-page result can combine several tiers under mixed, which does not identify how many pages healed. Account-wide repair totals are a useful cross-check when several jobs share a key, but you need job-level evidence to assign those credits to this watch. If your inputs only cover an account or a mixed result, narrow the observation scope before setting the allowance.

Run the repair forecast

Download the calculator, four-week sample and tests into the same directory. The weekly counts are an illustrative history. The one-credit unit price matches the public pricing response checked for this example. Recheck the rate when preparing a new budget. Current Scraipe pricing in credits

node --test forecast.test.mjs
node forecast.mjs weeks.json

The sample includes four complete weeks with 0, 1, 0 and 3 charged repairs. The plan covers six future weeks and allocates ten credits to repair. The calculator prints two separate cases.

Read the withinAllowance field for each case. A negative headroom is the additional amount the case would require. The program exits successfully when it can calculate both cases, including when the stress case exceeds your allowance. To test an input failure, set one week’s complete to false and run it again. It reports incomplete coverage and exits with status 2. Removing an interior week also fails. You choose the observation window and must check that its first and last weeks are complete.

Decide what to do with the range

With ten credits available for repairs, the example job can absorb its recent average. A repeat of its busiest week would use three credits each week and exhaust the allowance during week four. When planning around that case, reserve another eight credits for the six-week horizon or review the workload before week four. Set up a separate alert on actual cumulative repair spend if the budget matters operationally. Running the calculator alone does not enforce a spending cap.

Investigate a cluster of heals before extrapolating it. Group the original receipts by host, requested fields and layout. If one redesign explains three heals across different extractors, keep those three real charges in the history and record the shared cause. If the same extractor healed repeatedly, inspect the returned fields on a representative page before changing the schedule. Handle layout changes in an extraction workflow

Both six-week figures depend on keeping roughly the same job and price. A redesign affecting every watched layout could exceed the busiest week you have seen. A new schema, a doubled watch list or a long period of missed captures calls for a new baseline. For a total operating budget, add initial learning, fallback and network charges from their own estimates, counting each credit component once.