Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tuturuuu.com/llms.txt

Use this file to discover all available pages before exploring further.

Mobile live mode

The mobile assistant now has two distinct interaction modes:
  • Standard chat is the default assistant surface. Typed turns continue to use the normal text-model selection in the mobile shell.
  • Live mode is a dedicated fullscreen Gemini Live experience. It is entered from the assistant mic control or the assistant chrome action and binds the session to gemini-3.1-flash-live-preview.

Mobile cache warmup

The mobile assistant shell restores core metadata from AssistantRepository cache helpers before revalidating: personal workspace resolution, Mira soul, task and calendar insight, workspace credits, model catalog, recent chat history, and restored chat detail. The assistant_metadata warmup task should remain the entry point for preloading this data after boot, home resume, or workspace changes.

What fullscreen live mode does

  • Immediately switches the assistant route into a live-first surface instead of silently preparing a background session.
  • Auto-starts the microphone when the user enters live mode, so the transition feels responsive.
  • Shows large voice-activity blobs for both the user and the assistant, plus a live transcript lane for drafts and synced turns.
  • Shows the current live-session status detail inline in the fullscreen header, plus a contextual status panel with recovery actions for reconnecting and failure states.
  • Keeps voice, camera, and typed turns inside the same assistant thread, so persisted live turns still appear in the standard chat history after leaving fullscreen live mode.

Model split

  • Mobile typed chat keeps the normal text-model path managed by AssistantChatCubit and the workspace-selected shell model.
  • Mobile live mode always uses Gemini 3.1 Flash Live. Restoring a live-backed chat must not overwrite the normal text-model selection.

Backend dependencies

The mobile app still uses the existing internal APIs for Live sessions:
  • /api/v1/assistant/live/token
  • /api/v1/live/session
  • /api/v1/live/tools/execute
  • /api/v1/assistant/live/turns
These routes mint constrained ephemeral Gemini Live tokens, persist resumable session handles, execute synchronous tool calls, and sync completed live turns back into the chat thread. The token route now returns the latest resumable session handle together with the ephemeral token. Mobile uses that bundled handle to skip a follow-up read before opening the socket, and only falls back to loading seed chat history when there is no resumable handle or the user explicitly starts a fresh live conversation. Gemini 3.1 Flash Live should stay on a single AUDIO response modality for the live session config. The mobile UI relies on input/output audio transcription streams for inline text instead of requesting simultaneous TEXT and AUDIO outputs. The ephemeral token request should match Google’s current v1alpha auth-token shape: send httpOptions.apiVersion = 'v1alpha' on the token request itself, keep uses aligned with the default single-session flow, and prefer lockAdditionalFields: [] so only the explicitly constrained setup fields are locked while client-side setup details like history/session resumption can still merge at connect time. When bootstrapping a fresh live assistant chat, omit ai_chats.id entirely unless a specific chat id is being resumed so Postgres can apply the default UUID.

Verification

For mobile-only live-mode changes, the required verification path is:
  1. Update both ARB files when live-mode copy changes.
  2. Run flutter gen-l10n.
  3. Run bun check:mobile.