Pricing and billing

Shared capacity is AnyPath’s supply model and settles in USDT after successful requests. Customer pricing does not change when a referral reward applies.

Settlement modes

Mode	Who can use it	Buyer charge	Route provider earnings	AnyPath fee
Shared route	Eligible buyers	Platform-set price	95% of settled usage	5% gross platform fee

Shared-route price

buyer_price = official_list_price x route_provider_multiplier x usage
platform_fee_gross = ceil(buyer_price x 5%)
supplier_net = buyer_price - platform_fee_gross
referral_reward = active_referral ? min(platform_fee_gross, ceil(buyer_price x 2%)) : 0
platform_net = platform_fee_gross - referral_reward

The official list price used for charging and the provider that actually served the request may differ. AnyPath records both in settlement evidence and applies the multiplier owned by the actual routed Provider. Route providers provide capacity; they do not set buyer prices.

Multiplier

Each provider has one multiplier, set by AnyPath and never above the official list price. It changes only when AnyPath changes it, and a change applies to requests that start after it: your request is priced at the multiplier in effect when processing starts. The current multiplier of every provider and its recent changes are public on Live supply and price.

Referrals

Each user can share a referral link. When a referred customer has successful shared usage, the referrer earns an extra 2% from AnyPath’s platform fee. The serving provider still keeps 95%, and the customer’s price stays unchanged. Referral rewards sit with your earnings: in Billing -> Earnings & payouts you can withdraw them or move them to your usage balance, the same as route earnings.

For referred customers, AnyPath prefers healthy shared supply owned by the referrer when it fits the route policy. If that supply is unavailable, rate-limited, cooled down, emergency excluded, or outside the selected provider boundary, AnyPath continues with other eligible shared routes.

Balance and pending charges

• Buyer balance funds shared-route traffic.
• In-flight shared requests can reserve balance until they finish.
• Failed requests do not create provider earnings.
• Finalized transactions appear in Billing.
• Route provider earnings and payout status appear in the same Billing area.
• Referral rewards and platform net are shown with the related settlement when they apply.

Request evidence and account activity

Use Requests when the question starts with one API request: routed Provider, model, endpoint, input/output/cache/reasoning or modality usage, latency and TTFT when measured, buyer spend, provider earnings, multiplier, settlement, and ledger posting. The request detail and its CSV export use the same evidence contract.

Use Billing when the question starts with the account: available and held balance, ledger entries, deposits, provider credits, referral rewards, transfers, payouts, and reconciliation. Search, type/status/time filters, pagination, and the billing-activity CSV all query the same server-side view. A request-linked activity opens the canonical request evidence instead of duplicating request logs in Billing.

New shared settlements retain an immutable charged-price snapshot. Older settlements created before that evidence existed show the charged price as unavailable instead of joining a current catalog price and presenting it as historical truth.

The actual Provider is the route that served the request. The official price Provider is the provider whose official list price is used to calculate the charge. They can differ—for example, a Vertex AI route serving a Claude model—and the Console and CSV keep both fields separate.

Cost control

• Use shared routes when their official list price, Provider multiplier, health, and reliability fit the workload.
• Review your account tier, then set API key route policy, model access, narrower RPM/TPM, and budget limits for each workload.
• Inspect spend in Requests.

BSC deposits and payouts

The AnyPath-operated BSC rail accepts deposits and sends payouts. Billing shows its live capability status and your verified deposit address; do not send funds to an address shown in a development or test environment. Before sending funds, confirm Binance-Peg BSC-USD (symbol USDT) on BNB Smart Chain Mainnet, chain ID 56, contract 0x55d398326f99059fF775485246999027B3197955, and the complete address. This asset is not described as a Tether-issued BSC USD₮ deployment. Sending another asset or using another network may result in permanent loss.

Deposits can appear as detected, awaiting finality, credited, or held for review. A deposit is credited only after its block meets the approved finality policy; the receipt is successful; the exact selected-contract Transfer event and destination ownership match; two independent BSC data sources agree; the 18-decimal chain amount converts exactly to the 6-decimal ledger; and risk checks and reconciliation pass. A transaction hash by itself is not proof that account credit is final.

What you can pay out: route earnings and referral rewards, at any time. Unspent deposit balance is not withdrawn at will; you can ask for it back as a deposit refund in Billing -> Earnings & payouts, and an operator reviews every refund before it is sent, whatever the amount. Both go only to an address you added with your passkey, both need a passkey confirmation, and both carry the same network fee, minimum and limits, shown before you confirm. Cancelling a request before it is sent returns the reserved amount to the balance it came from.

Payouts reserve funds before submission. A payout can require operator review, and may be delayed or rejected by risk, liquidity, rail-health, reconciliation, or policy controls. Blockchain transfers are irreversible after broadcast. AnyPath shows the canonical movement ID once and links the BSC transaction hash to BscScan when it is available.

Account deletion does not erase financial evidence that AnyPath must retain for ledger integrity, reconciliation, fraud prevention, dispute handling, or legal obligations. Personal identifiers are deleted or anonymized where possible while immutable financial records remain linked to a pseudonymous financial-party reference. Pseudonymous records are not anonymous or non-personal data when they can still be linked to a person.