Interpret a zero included allowance without inventing free usage

Zero is a quantity, not a price

A zero included allowance means the plan contributes none of that metered quantity. It does not establish a zero retail price, unlimited use or provider availability. Read allowance, retail rate, product readiness and purchase flow as separate fields or documented behaviors before designing an agent’s budget.

Lupin’s shared plan catalog contains zero entries for some units even on paid plans. Its billing documentation also states that proxy allocation is separately purchased and phone usage needs destination-specific quotes. An application should not interpolate those products’ costs from an unrelated email or browser allowance.

Distinguish included activity from add-ons

An included allowance offsets eligible consumption within the applicable billing period. A separately purchased allocation can have a different lifecycle and payment mechanism. A resource limit, such as concurrency or storage capacity, is another type of entitlement and does not become purchasable merely because a usage unit has a price.

Read the account’s active entitlement rather than assuming the public catalog replaces every existing agreement. Lupin documents a legacy Developer recipient allowance retained for eligible existing subscriptions. Enterprise allowances require an explicit contract. A plan name alone is insufficient evidence for a precise remaining quantity.

Check whether overages are actually authorized

Paid overages are disabled by default. An active paid account must explicitly accept the catalog, authorize overages and set a positive monthly retail cap. Free accounts cannot enable paid overages. A customer’s subscription payment is therefore not blanket authorization for every metered quantity beyond its allowance.

Even with consent, a product may have another hard limit or unavailable purchase path. Lupin currently keeps retained storage under a hard cap and does not expose self-service purchases for extra browser concurrency or nondefault sandbox sizes. Avoid a universal “buy more” action unless the actual product supports it.

Account for allocation separately from consumption

For proxies, the documented billable quantity is allocated quota rather than actual traffic observed through the credentials. Allocating capacity and later using it are different events. A zero bundled allocation therefore cannot be interpreted as a free traffic budget, and unused allocated quota does not prove no purchase happened.

The same general caution applies to runtime and resource units: understand what is reserved at admission and what is settled later. Display the unit next to every number. A count labeled simply usage can hide whether the system means recipients, seconds, actions, allocated megabytes or retained bytes.

Write a capability-aware planning rule

Before an agent begins work, require a supported product path, account authority, remaining allowance or explicit purchase consent, and any applicable cost budget. If one part is unknown, return that unknown rather than converting it to zero. Explain which fact the user or operator needs to establish.

Use local catalog fixtures for zero, positive, absent and legacy allowance values. Check that zero yields a quantity of zero, absent stays unknown or unsupported, and no branch silently enables overages. This small distinction prevents a pricing parser from becoming an accidental spending authorization mechanism.

Sources & verification

Reviewed against the checked-in Lupin implementation and official reference documentation on 2026-11-05. Operational examples are illustrative; no live paid action, provider mutation or external message was executed.

• Lupin billing, metering and retained storage ↗Checked 2026-11-05
• Lupin usage ledger and spending limits ↗Checked 2026-11-05
• Lupin proxy provisioning ↗Checked 2026-11-05

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