The workspace
A chat-first interface that keeps infrastructure complexity out of the buyer's way.
In this chapter
Five primary areas#
| Area | Purpose | What it replaces |
|---|---|---|
| Chat | Compose a request, select a model, and eventually receive an answer with usage details. | The trading ticket as the default action. |
| Models | Browse verified capabilities, pricing, and data-handling information. | Stock-like tickers and unverified market comparisons. |
| Usage & balance | Understand account access, service balance, and eventual usage receipts. | Trading P&L, positions, and pretend savings. |
| Developers | Manage API credentials and integration details. | Repeated provider-specific account setup. |
| Supply | Apply to provide inference and eventually manage serving capacity. | A buyer interface mixed with supplier operations. |
Chat behavior#
Ask & explore, Write & edit, and Code & debug are text-task starters. They prefill a draft; they do not select fictional specialist models or trigger a request automatically. Image and video generation are not offered simply because they appear in another product's navigation.
- A draft is retained when switching between workspace areas in the same page session.
- New chat resets the local conversation and draft.
- Account changes clear conversation state; signing out or switching from an existing account clears its draft.
- The current input limit is 8,000 characters. The proposed request payload is bounded to 24,000 conversation characters and 512 output tokens; these are not a substitute for server-side token and spending limits.
- The UI does not automatically retry inference requests.
- Ctrl/Command + Enter submits through the same availability checks as the button.
History and receipts are different#
Conversations are stored on your account so they follow you between browsers and devices. They are yours: download a full JSON copy any time from Profile, or delete every one — deletion is immediate and permanent. Sent content necessarily reaches the serving provider; account history does not change that.
A usage receipt is intended to record service metadata: request identity, model, supplier, token usage, price, charge, and status. It should not need to contain the prompt or response. Financial receipts and conversation history must have separate storage and retention decisions.