Models and applications
YaoDel
Model gateway and final usage delivery
YaoDel lets applications share model-provider access while retaining their own customers, catalogs and pricing rules. The controller fixes a request’s authorized model target and execution account. An edge makes one provider attempt and separately delivers the response stream and final usage. Later configuration changes do not rewrite an already dispatched request’s binding.
Share provider accounts while preserving each application’s rules Each application authorizes inference using its own catalog and access policy. YaoDel selects a provider account and forwards the stream. Final usage returns to the original application, which applies its own pricing and ledger rules.
Share model access while applications retain their own rules
A membership product and a developer API can use the same provider accounts while deciding independently who may call, which models appear and how usage is priced. YaoDel uses the ingress domain to identify the application, asks it to authorize the request, and executes the approved target.
Stateless edges accept requests. The controller maintains routes, accounts and durable results. Operators manage providers, applications and accounts, and inspect credential status, original results and pending notifications. Applications supply the public catalog; a listed model does not establish that an eligible execution account is currently available.
| Participant | Owned result |
|---|---|
| Application | Customer authentication, model catalog, access policy, pricing and accounting |
| Controller | Authorized binding, account selection, saved results and notification |
| Edge | Request admission, one provider attempt and incremental event forwarding |
| Model provider | Inference and the terminal response with usage |
The application owns business decisions; the gateway executes the model request
An application integration needs a stable application ID, an application-server endpoint, a separate service credential and the public domains to bind. The application server supplies identity checks, model discovery, inference authorization and final-result processing. Authorization and accounting use the original request record so repeated resolution cannot create another reservation or charge.
Creation, reactivation or a change of receiver URL or credential requires a Check of the application ID returned by the candidate endpoint. Provider accounts are maintained separately. Only an enabled account that declares the target model and has usable credentials can be selected. An application catalog and executable provider capacity are separate facts.
Prepare the application receiver
Select its stable ID, endpoint and credential, and implement model listing, original-request authorization and deduplicated result processing.
Register complete routes and accounts
Check the application receiver before binding public domains, and prepare provider targets, model declarations and usable credentials.
Inspect a complete invocation
Observe the actual upstream request, client terminal event, saved final result and application accounting effect separately.
Fix the target before dispatch and preserve its binding
Each request retains its application ID, request ID, original domain, public model and authorized provider target. The controller selects an active account that declares the exact model and has usable credentials. Later domain, account or routing changes affect new selections without redirecting an existing result to another application.
Accounts support API keys and OAuth credentials. Credential maintenance proceeds independently: an access token that remains usable can still serve requests during rotation. An uncertain refresh requires attention to the retained credential authority. Credential errors, provider rejection and lost replies do not trigger an automatic model retry through a different account.
Define supported inputs and preserve their original content
The gateway exposes model discovery and streaming Responses requests. Its selected profile accepts text, PNG/JPEG images and inline PDF, TXT, Markdown, CSV, XLSX, DOCX and PPTX files, together with selected function and custom-tool declarations. Audio, video, hosted tools and complete Responses API compatibility are outside this profile.
Each request supplies its required complete history. Both the received JSON and the normalized provider JSON have a 64 MiB limit, including Base64 attachments. Admission performs bounded format and byte checks; it does not extract, OCR or convert files. The limit establishes neither model context capacity nor a cap on the total generated response.
Deliver the response stream and final usage separately
An edge forwards events in order and accepts the first complete, matching completed, failed or incomplete terminal response. It can send that terminal event to the client while independently submitting the result. Only the complete valid group of input, cached input, output and reasoning-output counters from that terminal response is retained.
A preterminal disconnect or cancellation produces an error with zero counters. An incomplete terminal usage group also becomes all zeros; intermediate events do not fill gaps. Those values describe the gateway observation, not whether the provider executed. A saved result may be delivered repeatedly. The application checks its original authorization, deduplicates atomically and acknowledges durable processing.
| Observation | What it establishes | What it does not establish |
|---|---|---|
| Result saved | An immutable result and four counters exist | The client received the response |
| Delivery confirmed | The original application acknowledged durable processing | Only one network send occurred |
| Delivery expired | Processing was not confirmed before the deadline | No posting or zero cost |
| Result missing | This read found no retained result | The provider never executed |
Investigate the original result without generating another answer
Start with the application ID and request ID. Find the saved original binding and final counts, then inspect whether notification was acknowledged or expired. Later domain or endpoint changes do not change the application that owns the result. Administrators can also inspect retained results after the application record is deleted.
A missing final result may mean the edge has not saved it, or was lost before saving. It cannot establish that the provider never executed. If the application committed its accounting but the ACK was lost, redeliver the same result and return the retained processing outcome. Generating another answer creates another execution and charge.
Supported conclusion: the application acknowledged the original binding
Successful acknowledgement requires matching the application, request, domain, model and provider target, with durable processing and request deduplication.
Unsupported conclusion: zero counts or no result means no execution
Zero counts can follow an incomplete terminal group; a result can be lost before persistence. Neither establishes that the provider produced no effects.
Check next: notification expired without acknowledgement
Retain the saved result and expired state, distinct from application acknowledgement. Notification status does not change the original model execution.
Investigate the original request without rerunning inference
Commit and notification retries retain the same binding and candidate. Losing an edge process can leave no saved result; the controller does not synthesize an execution from elapsed time. A failed query remains unavailable rather than missing. A notification page describes its observed scope and cannot automatically stand for the whole backlog.
The design calls for checks of routing changes, terminal output preceding confirmed storage, a lost acknowledgement after application accounting, and preterminal interruption. Independently observing provider attempts, durable results and accounting effects distinguishes execution, delivery and deduplication. These are verification requirements, not measured production results.