Skip to main content
Yir uses credits for Gateway tasks. The current public price and purchasable credit packages are shown on the pricing page; your live balance, purchases, and usage history are shown in Yir Console.

​
What happens at submission

Before accepting a task, Yir verifies that the API key is eligible and that enough credits are available. It reserves a bounded amount so concurrent long-running tasks cannot spend the same balance. An idempotent retry of the same logical request does not create a second independent charge. Reuse the same Idempotency-Key and identical request data.

​
What happens at completion

  • Confirmed success: Yir settles the task against the actual user price and releases any unused reservation.
  • Confirmed failure: Yir releases the reservation according to the confirmed failure fact.
  • Unknown or reconciling: Yir keeps the accounting state explicit while it resolves the missing fact. It does not invent a zero charge or treat a timeout as a confirmed failure.
The usage page distinguishes consumption from reversals and shows the resulting net consumption. A browser return from Stripe is not proof that purchased credits have arrived; Console reads the server-side order and entitlement facts again.

​
Fallback attempts

Protect can create a fallback attempt only after the primary attempt is confirmed failed and the immutable execution plan permits another route. A slow or unknown attempt is not treated as failed. Each Managed fallback is authorized separately before submission, and one task can submit at most three compute attempts. The user-facing task price remains separate from Yir’s internal procurement cost; internal route costs and provider credentials are never exposed through the public Gateway contract.