Product guides

DeepSpace workspace

DeepSpace is AverQel’s conversation-led workspace for research, writing, analysis, and continuing work. It brings the conversation and DeepSpace-owned working files together, while using optional providers and tools only when the deployment and user permissions allow them.

Conversations

Open and continue saved conversations. Responses may stream, and work that uses background execution can show queued or running state.

Research & tools

Configured web research, approved MCP tools, and other enabled capabilities can extend a conversation. Provider choice, policy, approvals, and service availability determine which actions can run.

Working Library & notes

DeepSpace has a Library and editor for files and deliverables associated with DeepSpace work. This is distinct from the source-file Documents Hub.

Optional capabilities

Sandbox execution, schedules, voice, and some integrations require additional services or credentials. See each guide for its limits and setup needs.

Choose the right area

  • Documents Hub: upload, inspect, organize, and manage source documents.
  • Query: ask focused questions over accessible source documents and inspect cited evidence.
  • DeepSpace: conduct broader conversational work and use supported tools, notes, or DeepSpace Library files when available.
  • Qel Connect: collaborate with invited members around explicitly shared content.

Context and token diagnostics

The composer keeps two scopes visible: the latest serialized context sent to the provider and the cumulative serialized input/output estimate for the whole DeepSpace turn. Tool calls and recovery rounds can make the turn total larger than the latest request. These local estimates use a provider-neutral serialization because each model family has its own tokenizer.

When an adapter returns usage, the panel shows the provider's exact input, output, cache-read, and cache-write fields and labels them as the latest reported model round. When every round reports a field, DeepSpace also shows the exact provider turn total; otherwise it marks that field incomplete. Codex, hosted OpenAI-compatible providers, Anthropic, Gemini, LM Studio, and Ollama are normalized into the same view. Local providers that do not return usage remain marked as unreported; DeepSpace does not invent a token count for them. Cache eligibility is also kept separate from a confirmed provider cache read.

Choose a model in DeepSpace

The model picker searches across available models from your connected chat providers. It groups results under each provider's display name, sorts provider groups and model names alphabetically, and lets you search by provider, model name, model ID, or quantization. The first provider group opens by default; opening another group closes the previous one. The selected model is marked within its provider group.

The Think menu follows the selected model's advertised reasoning levels. For a local Codex CLI account, DeepSpace reads the per-model catalog, including Codex's minimal and ultra levels, and sends the selected model's native value. Other safe levels advertised by a model are shown with readable labels. The browser ChatGPT model catalog may omit per-model effort metadata; when it does, DeepSpace uses the existing OpenAI reasoning profile and does not present it as an exact account-specific list.

Other providers use the selected model's verified capability profile or the effort levels advertised by its model catalog. LM Studio's model catalog can provide native reasoning options, and Ollama's model detail endpoint provides each installed model's named thinking values or On/Off support. Models without reliable metadata keep their provider default. If the selected model's metadata is missing or stale, DeepSpace refreshes that provider's catalog in the background and updates the menu when it completes. The configured default and current chat assignment are included even before their first model-catalog cache entry exists. For example, NVIDIA NIM Nemotron 3 Ultra offers Off, Medium, and High; Nemotron 3 Super offers Off, Low, and High. DeepSpace sends the provider's native request values for those choices. When a model's capabilities remain unknown, the menu shows the provider default instead of suggesting unsupported levels. If a model always reasons and cannot disable that behavior, DeepSpace shows its available levels or On without offering a misleading Off choice.

Provider health and conversation details

The compact provider-health summary is based on your recent DeepSpace usage, not a live connection check. Expand it to see recent usage by provider and model, including sample count, failure rate, and p50/p95 latency. P50 is the median; p95 shows the slower end of recent requests. If there are no samples yet, DeepSpace says No recent usage yet.

The expanded details also show the selected conversation's existing Conversation ID, which you can copy for support. It is the same ID used by the chat system; there is no separate Chat ID or DeepSpace ID.

Response speed and first-token time

While a reply is streaming, the composer shows a live output-token estimate and an estimated tokens-per-second rate. The live estimate includes answer, reasoning, and streamed function-argument chunks and refreshes as chunks arrive; it is intentionally marked as an estimate because the provider tokenizer and final usage are not available yet. Completed DeepSpace replies show output speed, end-to-end TTFT, and provider first-output time beside the response actions. End-to-end TTFT runs from the server starting the DeepSpace request to the first visible answer text. It includes routing, context preparation, provider waiting, and any reasoning or tool work before the answer. Provider first-output time starts when the first provider request begins and ends when the server receives its first output event. It includes network and connector overhead; Codex also includes the local desktop relay, so it is not the model vendor's internal compute time.

Output speed divides exact provider-reported completion tokens by the measured interval between the first and last output events in each generation round. Provider counts may include hidden reasoning or tool-call tokens, but DeepSpace never displays reasoning text in this metric. If exact usage is missing, the provider sends only one output event, or a response uses a buffered fallback, speed is shown as unavailable instead of being guessed from text. The tooltip explains why. These measurements are saved with the reply and remain visible when you reopen its conversation.

Use files and images in a chat

Attach files to a message when you want DeepSpace to use them as context. The selected model can use the file-reading tools that fit your request, including reading extracted text, searching a longer document, comparing files, or analyzing tabular data. DeepSpace checks that attached files belong to your account and conversation before using them.

Images are sent directly to the model only when that model supports image input. If it does not, DeepSpace uses the text saved by upload-time extraction or OCR when available. If a model explicitly rejects an image, DeepSpace retries once without the image and uses saved OCR text. If visual input is unavailable and extraction found no readable text, the attachment shows that status and the assistant is told not to guess. Very large image sets may be limited.

An attachment becomes ready as soon as its private file is stored. Text extraction and OCR then continue in the background; the composer shows “Uploaded · reading text” while that work is pending. Supported images can be sent to a model with visual input before OCR finishes. For other files, DeepSpace reports pending extraction instead of treating missing text as proof that the file is empty. When processing finishes, the attachment shows whether text was extracted, OCR was used, no readable text was found, or extraction was unavailable. Short whole-file reads use saved text directly; targeted questions and large documents can use document search.

Rich answers, charts, and diagrams

DeepSpace keeps normal Markdown as the source format and promotes supported fenced blocks into interactive surfaces. A chart fence accepts JSON with a title, a chart type (line, bar, area, scatter, orpie), and a series of labeled values. Bar charts center each category in its own slot and draw positive and negative values from zero. Completed charts support hover details, value editing, named multi-series data, left/right axes, annotations, interactive legends, a payload view, JSON download, and revisioned save back to the conversation. Add an equation field when a chart needs its formula shown beside the visual. Recalculating refreshes the chart JSON source from the same values and returns to the visual view. If the revision cannot be saved, the editor stays open so you can retry. Optionalx_label and y_label fields appear as axis titles.

Use Mermaid for flowcharts, sequence diagrams, UML, architecture, business models, and schedules such as Gantt charts. Gantt source can use a gantt fence or amermaid fence beginning with gantt; make the dateFormatmatch task dates (for example, YYYY-MM-DD for 2026-01-05). Mermaid diagrams include copy, Save artifact, JSON and Mermaid-source downloads, plus SVG/PNG/PDF exports. SVG stays vector-based; PNG and PDF use the SVG viewBox and render at up to 2× resolution within browser canvas limits. Labels use native SVG text so raster exports remain self-contained. UML class diagrams and Gantt schedules also expose structured controls that regenerate the Mermaid source. Use a card fence for a finding, recommendation, source, or media summary; cards can contain safe Markdown, metrics, an approved image URL, a source link, copy/download controls, and explicit actions. External URLs must come from an authorized search or read result. Card tones are info, success, warning, error, or neutral; common model labels such as positive and caution are normalized automatically. Raw HTML and scripts are not rendered.

A graph fence opens the portable canvas editor: nodes can be moved and resized, connected, grouped, aligned, zoomed, or annotated with freehand paths, then copied or downloaded as DeepSpace .draw.json; that portable JSON is not an Excalidraw file. You can import the same format directly into the chat canvas. Mermaid source can be downloaded as .mmd or edited in place, which makes UML, business-model, and Gantt diagrams practical inside the chat and notes. A gallery fence creates a safe image sequence with captions, next/previous controls, source links, and downloads. DeepSpace copies usable raster images into private conversation storage so previews and exports do not rely on third-party CORS. These temporary copies expire after 30 days; choose Save image to Library to keep a photo. Temporary copies stay out of the regular Library list and are removed by scheduled storage cleanup. Visual revisions update the authenticated message and active note. If a visual is saved as a Library artifact, later chat, note, or artifact edits advance its version and synchronize the revision to the linked views. Delayed note refreshes preserve the latest saved visual revision; conflicting edits from another session are reported so the note can be reloaded. Providers may use a genericjson fence for these same payloads; DeepSpace recognizes unambiguous card, chart, graph, and gallery JSON automatically. Invalid visual JSON is kept as plain code instead of being executed. A missing image or non-image URL shows a recoverable fallback and does not terminate the answer. JSON, SVG, PNG, and PDF exports are available for visual blocks; gallery SVG/PNG exports embed owned images when available and show a placeholder for a missing image. PNG/PDF export strips external SVG resources before rasterization; if a browser still blocks rasterization, the error is shown inline instead of escaping as an exception. Saved rich blocks in notes are restored as rendered visuals when the note is reopened, so the note preview does not fall back to raw visual-fence code.

Tables include copy and CSV/XLSX export controls. In DeepSpace, with a conversation open, choose Save to Library to store a table as a private, versioned visual artifact that can be reopened from the Library. If clipboard access is blocked, DeepSpace tries a browser fallback and shows an error if copying still cannot complete. Export and Library-save failures are also reported beside the table controls.

```chart
{"title":"Quarterly revenue","chart_type":"line","equation":"y = mx + b","series":[{"label":"Q1","value":12},{"label":"Q2","value":19}]}
```

```card
{"title":"Decision brief","tone":"success","content":"**Ship** the verified workflow.","metrics":[{"label":"Confidence","value":"92%"}]}
```

Prompt and queue status

Replies with saved versions have previous and next controls. Choosing a version shows it immediately and saves it as the active reply; all saved versions remain available. If saving the selection fails, DeepSpace reloads the saved reply. When you switch conversations, the old thread is temporarily read-only until the selected history loads. A background run continues on the server and can reconnect when you return to its chat. If history cannot be loaded, use Try again to retry without replacing the thread you were viewing.

Use Regenerate on a saved reply to start a fresh generation for that response. DeepSpace keeps the previous reply as a version, uses the saved prompt and its Library attachments, and queues the work with the rest of the conversation. You can regenerate while another reply is running; the current reply remains visible until the regeneration starts. Regenerating an older reply uses only the conversation context that came before that reply. If the browser reconnects or the app is reopened, the response continues from its saved event stream. A queued regeneration can be canceled, but its source prompt cannot be edited.

The message field grows with multiline text up to five visible rows; longer drafts scroll inside the field.

For a saved conversation, DeepSpace stores each turn in its durable queue before a background worker starts it. While your current turn is waiting in that queue, its activity panel says Queued. After a worker claims it, the panel changes to Thinking & activity. The composer queue is for other pending turns, so the current prompt is not listed there a second time.

If a prompt remains queued, the worker has not claimed it yet. Workspace administrators should check DeepSpace worker availability; users can keep other pending prompts in the composer queue while they wait. A queued prompt is shown as active only after a worker claims it, and the chat reconnects after that state change. If a worker claims a prompt just before you choose Steer, the queue refresh explains that it has already started; a running prompt cannot be reordered.

A queue submission that meets a temporary service interruption is retried once; if it still cannot be saved, the draft stays in the composer and the error explains what happened. An initial stream HTTP error also gets one retry, then automatic reconnect stops so the activity panel does not stay live through a retry loop. This reports a connection failure; it does not confirm that an already-started server worker stopped. Reopen the conversation after service recovers to attach to its saved run. When you stop a running response, the activity panel waits briefly for the server confirmation. If that terminal event is unavailable, it stops the local timer and reloads saved history so an interrupted worker cannot remain displayed as running.

Use Edit beside a queued prompt to bring it back into the composer. Saving updates that same queue entry and keeps its place in line; canceling restores the text you had in the composer before editing. Existing Library attachments remain on the queued prompt. A prompt cannot be edited after a worker starts it, or after it fails; in those cases the edited text stays in the composer and a failed prompt can be retried as a separate attempt.

If a turn fails, DeepSpace keeps its error and advances to the next queued prompt. Use Retry on the red error card or Retry prompt in the queue to create a new attempt from the exact saved prompt and its original Library attachments. It resumes from a saved checkpoint when one is available; if that checkpoint has expired, DeepSpace restarts the saved prompt and completed external actions could run again. Continue queued prompts resumes a manually paused queue without retrying the failed turn.

If a background worker stops unexpectedly, DeepSpace closes the old live stream, keeps any partial text, and marks the turn as retryable instead of leaving it labeled as running. Use Retry or Regenerate to start a new attempt.

When DeepSpace resumes a clarification, approval, or failed run, it restores the original saved task even if it is older than the normal chat context window. Some providers also require private continuation data after a tool call; DeepSpace stores that data encrypted for resuming and does not return it in chat history.

When a response creates a saved task plan, a collapsible task drawer appears immediately above the composer. It opens as the plan is created, shows each task's live status, and can be collapsed to a one-row progress summary that keeps the active task and its running indicator visible. The task drawer is the single place that shows plan progress;Thinking & activity continues to show only the tool activity. DeepSpace checks the saved task ledger before it reports the final answer.

Error headings describe the failure type. Request rejected means the provider received but refused the request, while Provider unavailablemeans a provider timeout or server outage. A request rejection usually needs the provider message or selected model settings to be checked; waiting alone may not fix it.

DeepSpace guides

Availability and limits

DeepSpace behavior depends on a configured model provider. Tool use is constrained by connection ownership, provider and tool policy, approval settings, and backend authorization. A model response is not itself proof that an external action completed; review the tool result or generated artifact status shown in the app.

Durability and feature availability depend on the running API, database, workers, and any optional services used by a particular action. This guide does not claim a deployment is production-ready solely because the feature exists in the repository.