url-ingest Billing
Three billing events (processing, storage, retrieval), each with the same shape: backend reports credits, platform applies a multiplier, self-deployed backends pay a flat circulation fee.
Formulas
| Event | Platform formula | Self-deployed |
|---|---|---|
| Processing | raw_credits × content_type_rate × cache_hit_mult? | min_circulation_fee |
| Storage | storage.credits × storage_cost_multiplier × cache_hit_mult? | min_circulation_fee |
| Retrieval | storage.credits × retrieval_cost_multiplier | min_circulation_fee |
When is each charged?
- Processing — once per ingest (fresh or cache hit).
- Storage — once per (project × resource × storage backend). If the project deletes the resource access, the next ingest charges again.
- Retrieval — once per /search call.
Cache-hit semantics
On a dedup hit the cache_hit_cost_multiplier applies to both processing and storage charges (retrieval doesn't dedup — it always runs a fresh vector search). A hit requires the storage backend to still have the content AND url-ingest to have both the processing and storage cost caches. Any miss → full reprocess.
The storage backend's per-Mtok / per-GB pricing lives inside the backend (see ctx-storage credits_per_* settings), mirroring how processing backends like glm-ocr or MinerU-OCR bake their own list prices into the credits they report. url-ingest never decides raw pricing — it only applies the platform multiplier.