Why vouchers, not a tier ladder

Most platforms issue referral rewards in one of two forms: in-account rebate balance, or shareable coupon / credit codes. The former is stuck to one account and naturally turns into a personal tier ladder; the latter is transferable and therefore suitable for team settlement. In 2026 most mainstream API platforms and aggregation gateways offer both, so the key move is to prefer redeeming rewards as transferable vouchers rather than leaving them as personal balance.

Steps

Step 1: Filter for platforms whose rewards are transferable

On the referral page, confirm only three things:

  1. Whether the reward arrives as a coupon, credit code, or gift credit (not just account balance);
  2. Whether the voucher has an expiry date and a minimum-spend threshold;
  3. Whether the invitee must make a first top-up or first API call before the rebate triggers.

Keep only platforms meeting "transferable + clear trigger" on your list; treat the rest as personal backup.

Step 2: Design who you invite, not how many

Voucher value depends on whether the invitee actually generates usage. Prioritize:

  • New colleagues not yet registered on that platform (register with a shared company email for easier reconciliation);
  • Partner developers who genuinely run inference;
  • Small teams with a real project but no vendor chosen yet.

Avoid inviting accounts that will never be used — most platforms delay or claw back rewards after risk checks, which lengthens your settlement cycle.

Step 3: Convert rebates into cost per thousand tokens

Do not look at face value alone. Divide the voucher amount by the model's per-thousand-token price to estimate the call volume it covers. Results vary widely across models, so usually allocate vouchers to the highest-priced inference tasks first, such as long-context or multimodal calls.

Step 4: Keep a credit ledger and roll it over monthly

Track in one table: voucher source (inviter), face value, expiry, consumed, remaining, and project. At each month-end, assign soon-to-expire vouchers to the project with the largest usage that month, and hold newly arrived vouchers for the next month. This prevents expiry waste and avoids the "voucher in account A, usage in project B" reconciliation mess.

Caveats

  • Most platforms prohibit bulk registration and self-referral. If flagged, both rebates and account credits may be frozen.
  • Vouchers are usually non-withdrawable and non-mergeable across accounts; transfer typically happens by entering a code at checkout, not by account-to-account transfer.
  • Some platforms require the invitee to complete identity or business verification before rewards are issued; arrival typically takes days to weeks.
  • In corporate reimbursement, voucher-covered amounts often cannot be invoiced; mark them separately in the ledger.
  • Face values, expiry windows, and triggers differ by platform — always defer to the current referral terms.

When it fits

  • Small teams or studios with steady inference usage that prefer not to top up in full each month;
  • Open-source maintainers who want to hand small credits to contributors;
  • Teaching or community settings where credits must be distributed to multiple users.

When it does not fit

  • Solo long-term use: leaving rewards in account balance is simpler;
  • Production environments needing large, stable budgets: rebates fluctuate too much to be a primary budget source.