Understand proxy allocation, remaining traffic and usage

Use distinct names for distinct quantities

A proxy user's quota, remaining traffic and derived usage describe different things. quota_mb is the target balance the refill logic tries to maintain. traffic_mb represents the recorded remaining allocation. used_mb is derived from cumulative allocated traffic minus the observed remaining amount. These values should not be collapsed into one balance label in a dashboard. A user can consume traffic while a refill returns its remaining amount near quota. If you only watch the remaining number, that usage can be hidden by replenishment. Track consumption and allocation events together when explaining the account's behavior.

Understand what Lupin meters

The current shared billing catalog prices proxy.allocated_mb at three dollars per 1,000 megabytes, commonly expressed as $3 per GB under that decimal convention. The billable product is allocated megabytes, not a separate real-time counter of every byte the client transferred. Creation can allocate the chosen opening quota, and manual or automatic top-ups can allocate more. Review the workspace's current catalog and billing state before acting because allowances and eligibility still apply. Do not present an upstream provider's deposit price or marketing rate as Lupin's customer retail price; provider costs are a separate accounting concern.

Choose refill policy explicitly

Creation accepts quota_mb, traffic_mb, auto_refill and low_threshold_mb. The quota defaults to traffic_mb when omitted, and auto_refill defaults to true. In the current code, the default low-water mark is the smaller of one hundred megabytes and ten percent of quota. That implementation detail matters for small quotas and differs from prose that might suggest a minimum of one hundred. If a strictly bounded allocation is the intended experiment, set auto_refill false at creation and obtain approval for the chosen amount. The public API does not currently expose a general policy-update endpoint for changing it later.

{"username":"research-task","quota_mb":100,"auto_refill":false}

Treat usage synchronization as operational work

Reading an individual active proxy user can synchronize provider remaining traffic and trigger a configured refill. A background sweep also performs synchronization. Consequently, a read may be connected to paid allocation behavior; it is not always a purely observational operation. The tool catalog flags this sensitivity for human approval. If upstream synchronization fails, the route can return its previous stored state rather than failing the whole read. Treat the numbers as a recent operational view with possible staleness, not an authoritative byte-level invoice or an immediate measurement of the last request your client made.

Reconcile the budget at allocation boundaries

Record opening allocation, subsequent top-ups, refill events and the usage observations that explain them. A proxy.pool.low event can reflect a dry pool or another refill failure, so investigate before assuming a purchase is the only remedy. Preserve stable Idempotency-Key values for creation and manual top-ups to avoid duplicating an uncertain allocation. Stop client traffic when the approved task ends and use the supported operator lifecycle for further changes. A clear budget report distinguishes what was allocated, what was observed as consumed and which refresh or provider outcome remains uncertain.

Sources & verification

Reviewed against the current Lupin route, provider adapter and shared input contracts, plus the linked official references. Examples were not run against live services.

• docs.dataimpulse.com · resellers · deposit-calculation-update ↗Checked 2026-11-05
• docs.dataimpulse.com · traffic-limit ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.