Models and applications
Yaoledge Chat
Durable conversations, attachments and history
Yaoledge Chat turns a live response into a conversation that can be read again. After a user sends text, images or documents, it publishes the input before calling the model and then publishes response checkpoints. Chat owns content, conversations and capacity; Yaoledge owns membership and charges. Display, saved history and posted fees are confirmed separately.
Understand the same conversation after a connection drops While generated text is displayed, the service publishes recoverable checkpoints. Reopening shows the committed prefix and actual ending state. Continuing the conversation requires a new explicit send; the previous turn is not replayed automatically.
Save the complete input before the first model call
A customer selects a model and explicitly sends a turn. The server checks current identity, membership and history capacity, then assembles the request from committed server history and the new message. Supported content includes text, PNG/JPEG images and original inline PDF, TXT, Markdown, CSV, XLSX, DOCX and PPTX files, without extraction or conversion.
The first send binds a new conversation, turn and input together. Only after the content is written and published in the current history can a model request begin. An accepted input therefore has a defined durable home. A first send that fails before publication leaves no empty conversation. Each explicit send has its own turn identity, and a conversation allows one unfinished turn at a time.
| Task | Result |
|---|---|
| Send or continue | Save this input and call the model using committed history |
| Reopen or page through history | Read content and turn states within a captured committed cutoff |
| Export | Download committed JSONL history with original attachments |
| Stop, delete selections or clear | End generation, withdraw selected conversations or clear current history |
Establish which account an action is for
The interface reads current identity and history capacity before an explicit Send. First send, history listing, selected deletion and clear-history actions carry the account identity the interface actually observed. The service independently verifies the real session and compares the two. This is a target-consistency check, not authentication.
If another tab changes the login cookie, an old page therefore cannot silently execute an action intended for account A against account B. An admitted turn also retains its original account and destination. An identity read failure remains unavailable; it must not be presented as signed-out or empty history.
Read current identity and entitlement
Distinguish signed-out, unavailable and signed-in without new-generation entitlement. Existing history operations still follow the verified identity.
Explicitly send the current input
Bind the model, message and attachments to one new turn. Save and publish the complete input before dispatching the model request.
Show generation and saving separately
The browser may display unpublished increments. Reopening history restores only content known to have committed.
Displayed progress can precede saved progress
Text deltas can reach the browser immediately while the server groups output into checkpoints of at most 1 MiB. Checkpoint content is written to private object storage and an ordered reference is then published transactionally. Only published content belongs to recoverable history. The last character on screen is not a persistence acknowledgement.
The database retains capacity, conversation order and publication records; larger bodies live in immutable objects. Each publication checks used plus reserved capacity so concurrent conversations share one account budget. A turn also reserves 512 bytes for its terminal record, leaving room to record an interruption when response content exhausts capacity.
Read the definite prefix after an interruption
An explicit Stop ends upstream consumption and attempts to save the retained remainder within the original deadline and capacity. A browser disconnect preserves the definitely committed prefix without an additional tail save. Reopening reads local history; it neither resumes the provider stream nor automatically sends the original request again.
A provider terminal, content persistence and financial settlement are separate records. Chat presents completed, failed or incomplete only after the required content and terminal record are definitely published. Stopping, deleting or clearing cannot undo remote work that has already occurred. Charges remain governed by the original request’s financial ledger.
| State | Meaning | Next action |
|---|---|---|
| Completed / failed / incomplete | The model terminal and required content are saved | Read the corresponding outcome and history |
| Interrupted | A connection, capacity, storage or deadline condition ended the turn | Read its retained prefix and reason |
| Unknown | The original call or terminal publication is not yet established | Observe the original turn without automatic replay |
Use one history allowance and a clear export ending
History capacity counts the canonical stored content: text, original Base64 attachments and turn metadata. A model request separately has a 64 MiB complete-JSON limit. Free history capacity does not guarantee that the next assembled request fits. Expired or reduced membership leaves existing history readable, exportable and deletable; each new turn checks current entitlement.
An export captures the committed cutoff and streams messages and turn states in order. It does not load the entire history into memory or apply the model-request total-size limit. Completion requires its final integrity record. If required content becomes unavailable or is withdrawn during the transfer, the download remains incomplete rather than becoming a successful partial backup.
Reading, exporting and clearing have distinct completion conditions
An export captures a fixed committed cutoff. Later additions are outside that download. Its final JSONL complete record checks the cutoff, source-record count and actual output count. A truncated file without that record is not a complete backup. Export only reads retained conversation history; it does not invoke a model or create another charge.
Selected deletion confirms that those IDs are inaccessible in the current account. Unconfirmed remaining IDs do not prove continued existence, and unfinished batches are not complete. Clearing is a new whole-account decision. After a lost reply, observe current state first; another clear requires fresh explicit confirmation of the current account’s entire history.
Supported conclusion: the export has its complete terminal record
The export result is complete only after every captured source record and resulting output has been successfully read and written.
Unsupported conclusion: displayed text must exist after reopening
Display increments can precede checkpoint publication. Saved content is established by committed history, not the last character visible in the browser.
Check next: content arrives after history was cleared
A turn in the withdrawn generation cannot restore old content or change new-generation counters. Original owners still complete physical object cleanup.
Withdraw visibility while retaining cleanup responsibility
Selected deletion withdraws conversations within the account and releases their logical capacity. Clear switches the account’s history generation and resets used and reserved capacity in one transaction, without first traversing every message. New turns can proceed. Late writes from the retired generation cannot restore old content or change the new counters.
Background cleanup follows retained object records. Unconfirmed writes or deletes retain their original responsibility. Logical deletion promises no fixed physical-erasure deadline. Verification focuses on unpublished first-input failure, disconnect after provisional display, missing export content and late publication after clearing. Each case needs independent observations of readable history, capacity and upstream calls.