Models and applications
Yaoledge
Membership, model authorization and usage accounting
Yaoledge connects membership, model authorization and charges to one account. Users manage memberships, API keys and service credits. The server captures rates at authorization and settles matching final usage later. An independent chat application obtains identity and history-capacity entitlements from the same service, keeping commercial rules consistent across clients.
Explain a model call as a precise account change Retain the authorized model and rates before execution, price the complete terminal result afterwards, and record allowance, credits and charge details in one transaction. Users can trace the change through the original request and posting date without catalog updates rewriting history.
One account for developer access and browser conversations
Customers sign in through the existing identity service and receive a product session. Developers can create and revoke API keys. The chat service receives a separate model credential bound to the current session and valid for fifteen minutes. Each credential has a distinct purpose while charges remain attached to the original account.
A new request requires valid credentials and either available membership allowance or spendable service credits. Credits can fund model access without membership; Chat separately requires current membership and sufficient history capacity. Logout, revocation and expiry affect future admission. Already authorized requests retain their original settlement authority.
Follow a credential through to an auditable charge
A developer signs into their own account, checks current model offers and available resources, then creates an API Key for that purpose. The full secret is returned only at creation; listing exposes only management records for the current account. Revocation limits future admission without deleting authorization and charge records for already admitted requests.
The displayed offer explains the choice before a call, while settlement uses the rate snapshot retained by the original authorization. Afterwards, check terminal usage, the complete charge and its allowance and credit allocation under the original request. Recalculating history from the current catalog would use the wrong rates.
Review models and current resources
Identify the public model and rates, and confirm that the account has entitlement or credits available for a new call.
Retain the secret returned once
Use the API Key for developer calls. Browser Chat instead uses a short-lived credential bound to its product session.
Inspect accounting for the original request
Match final usage to the retained rates, then inspect the committed charge and allocation.
Capture rates first, then price the final usage
The authorization transaction retains the account, credential, model, provider target and price snapshot. It neither debits funds nor reserves a maximum charge. Concurrent work and delayed results can exceed the resources observed at admission. Later catalog or membership changes do not rewrite the request’s rates.
A final notification must match the original authorization. The server prices uncached input, cached input and total output, then rounds the combined charge upward once to a millionth of a yuan. Reasoning output is already included in total output and is not charged again.
Account changes, the usage entry, daily totals and original-request closure commit in one transaction. Repeated notifications return the retained result without another charge. To check a charge, use the rate snapshot from authorization and the account state at settlement for allowance and credit allocation.
| Component | Quantity used | Meaning |
|---|---|---|
| Uncached input | Input minus cached input | Ordinary input rate |
| Cached input | Terminal cached-input count | Cached-input rate |
| Output | Terminal total-output count | Includes reasoning output, charged once |
Explain allowance, credits and uncovered usage
During active membership, a charge uses available allowance first, then service credits. Any remainder stays as unreplenished excess allowance utilization. Credits never become negative. Later recovery or credit grants can offset excess. A posted record retains the full charge and its allocation when capacity changes later.
This example comes from the design: capacity is 10, utilization is 6, credits are 3 and the new charge is 10. It uses 4 units of available allowance, 3 credits and 3 units of excess. A later 5-credit grant offsets 3 and leaves a balance of 2. These are illustrative rule values, not operational data.
| Point in time | Allowance utilization | Credit balance | Available allowance / excess |
|---|---|---|---|
| Before the charge | 6 | 3 | 4 available |
| After the 10-unit charge | 13 | 0 | 3 excess |
| After a further 5-credit grant | 10 | 2 | 0 available; 0 excess |
Give membership changes explicit effective times
First membership starts with zero available allowance and recovers gradually over a seven-day window while active. A full allowance cannot bank future recovery, and inactive time earns none. Pre-existing excess survives activation. The current frozen term supplies both allowance capacity and history entitlement.
Renewal appends its purchased terms after the existing end date. An upgrade takes effect when payment is confirmed and begins its new full term. Cancellation returns service credits based on original purchase prices and remaining complete days; a complete future term that has not started can return its full price. This is a credit return rather than a cash refund.
Usage still in flight can consume returned credits or create excess after cancellation. Expiry, cancellation and a smaller later plan preserve conversation history. New conversation admission depends on the current entitlement and history capacity.
Report costs by the day they enter the ledger
Usage summaries cover seven or thirty reporting days in Asia/Shanghai. An inference that starts before midnight but settles afterward belongs to the later posting date. Gross charges, allowance-funded charges and credit-funded charges are updated with the original usage entry, without a separate financial recomputation worker.
Credit purchases, membership returns and excess offsets retain their own records without increasing model-cost summaries. Zero cost does not establish zero requests, and a failed read is not zero spending. The reporting interval can be passed to detail queries without downloading the entire history.
Distinguish current entitlement, purchased terms and late charges
To investigate membership or credits, locate the original purchase, frozen offer, original payment relationship and actual entitlement period before inspecting the current account. A catalog update changes future offers, not purchased terms. A future renewal term does not apply its capacities before the current term ends.
A charge crossing a boundary has two relevant times. Pricing comes from the original authorization snapshot; allowance and credit allocation use account state when the charge settles. Daily reporting then groups it by its actual Shanghai-time posting date. Credit changes after cancellation or charges posted after midnight are explained through the original request and charge record.
Supported conclusion: the original charge retains cost and allocation
Repeated results read the same committed outcome under the original request. Compare amounts against that record and its retained rates.
Unsupported guarantee: available allowance prevents every excess charge
Authorization neither deducts an amount nor reserves a maximum. Concurrent calls and late results can exceed the resources visible at admission.
Check next: posting dates and non-model ledger entries
Daily totals group posted model charges. Purchased credits, membership credit returns and independent excess offsets retain separate records and are not model charges.
Preserve original facts in operational changes
Operators can inspect accounts, purchases, original inferences and usage; restrict new commercial admission; directly set a membership interval; and grant credits under a unique grant identity. Repeating a matching grant returns its original result. Setting membership creates a replacement interval rather than extending the prior end or fabricating payment and refund records.
Verification focuses on retained rates after price changes, one posting after repeated notifications, midnight reporting, delayed charges after cancellation and same-identity continuation after a lost grant response. Logs explain processing; the ledger supplies monetary authority. The design’s verification requirements are not completed measurements.