[Docs] Align public docs with recent product changes

apps/docs/brain.mdx

@@ -117,30 +117,26 @@ become canonical memory.
 **Settings → Brain** is the deployment-wide view of the memory, for admins. It
 answers three questions in order.
 
-**Is it working?** Summary tiles carry the corpus size, the task memories
-recorded, and the sources connected; the status section reports the Brain's
-endpoint, whether recall is semantic or keyword-only, and which provider is
-serving its embeddings and synthesis. A Brain that is running but has no
-provider key is called out as needing attention rather than shown as healthy:
-without one it can only match keywords, so recall would look real while
-missing everything semantic. A configuration section shows the models the
-Brain runs: the synthesis model (changeable through `R_BRAIN_MODEL`, applied
-immediately) and the embedding model, which is fixed when the Brain is created
-because it sizes the vector store.
+**Is it working?** Summary tiles carry the corpus size and the task memories
+recorded; the status section reports whether recall is semantic or keyword-only
+and which provider is serving its embeddings and synthesis. A Brain that is
+running but has no provider key is called out as needing attention rather than
+shown as healthy: without one it can only match keywords, so recall would look
+real while missing everything semantic. A configuration section shows the
+models the Brain runs: the synthesis model (changeable through `R_BRAIN_MODEL`,
+applied immediately) and the embedding model, which is fixed when the Brain is
+created because it sizes the vector store.
 
 **What has it learned?** A composition bar breaks the corpus down by what
 each page came from, such as task memories, pull requests, Slack, meetings,
 and people, followed by a chart of the pages written over the last 30 days
 and the pages written most recently. **Browse memory** opens the corpus page
-by page, searchable and filterable by source, so an admin can read exactly
-what the Brain stored. The Brain lists its newest pages first and answers
-with a bounded window, so on a large deployment this is labelled as a recent
-sample rather than presented as a total.
-
-**Where does it learn from?** Each source shows whether its integration is
-connected, when it was last read, and how far its one-time history sweep has
-got. A source with nothing connected upstream says so, which distinguishes
-"nothing collected yet" from "nothing to collect from".
+by page, searchable and filterable by source. Large corpora load in pages, so
+admins can search and inspect older memory as well as the newest pages.
+
+**Where does it learn from?** Connected sources are listed with their current
+collection state, when they were last read, and how far their one-time history
+sweep has got. Sources without a connected upstream integration are omitted.
 
 The page ends with the task-memory queue: how many completed tasks have been
 recorded, how many are waiting, and how many failed. Two actions live there.

apps/docs/cost-analytics.mdx

@@ -5,9 +5,9 @@ description: Review Roomote inference spend by task type, environment, provider,
 ---
 
 Cost Analytics helps deployment teams understand how Roomote uses inference
-across tasks and automations. It reports the cost of recorded model usage in
-US dollars, so you can spot the environments, models, and work types that
-drive spend.
+across tasks, Fast-mode conversations, and automations. It reports the cost of
+recorded model usage in US dollars, so you can spot the environments, models,
+and work types that drive spend.
 
 Any signed-in deployment user can open **Analytics** from the dashboard, then
 select **Costs**.
@@ -18,13 +18,16 @@ The Costs view includes summary cards, a chart, and a detailed breakdown of
 recorded inference usage. Use it to answer questions such as:
 
 - which task types account for the most spend
+- how much non-task inference, including Fast mode, contributes to spend
 - whether a particular environment or model is driving costs
 - how usage differs between people and automations
 - how a provider's cost changes over time
 
 The view starts grouped by **Task Type**. You can instead group or filter the
 data by user, environment, provider, or model. Choose a time range before
 comparing periods so the chart and breakdown use the same window.
+Fast-mode inference that runs outside a launched task appears as **Non-task
+inference** in the task-type breakdown.
 
 ## Exporting data
 

apps/docs/models.mdx

@@ -157,6 +157,8 @@ ANTHROPIC_API_KEY=...
 You can also split model roles with env vars:
 
 ```sh
+R_ORCHESTRATION_MODEL=openrouter/google/gemini-3.7-flash
+R_ORCHESTRATION_MODEL_REASONING_EFFORT=low
 R_SMALL_MODEL=openrouter/openai/gpt-4.1-mini
 R_VISION_MODEL=openrouter/openai/gpt-5.6-sol
 R_CODE_REVIEW_MODEL=openrouter/openai/gpt-5.6-sol
@@ -229,9 +231,10 @@ where you want more speed, quality, or cost control.
 | Explore model        | Repository search and focused codebase exploration                                      | Fast tool use, low latency, and reliable source-grounded investigation                    |
 | Advisor model        | Planning turns and advisor consultations inside longer coding tasks                      | Deliberate reasoning, decomposition, and ability to keep constraints in mind              |
 
-You do not need a separate model for every role. Many teams start with one
-strong default model, then add a cheaper helper model or a stronger review
-model after they can see real task usage.
+You do not need a separate model for every role. Set a specialized role to
+**Same as coding model** to inherit the default. Many teams start with one
+strong default model, then split out a faster orchestration or helper model, or
+a stronger review model, after they can see real usage.
 
 ## Reasoning settings