chore(docs): drop the 1k-token session batching narrative

Reasoning no longer waits on a per-session token threshold, so product
docs should not tell people to size sessions around that gate.

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/v3/contributing/troubleshooting.mdx

@@ -109,7 +109,6 @@ Messages are stored but no observations, summaries, or representations are being
    ```bash
    DERIVER_WORKERS=4
    ```
-5. **Representation Batching** — By default the deriver buffers representation work until a work unit has accumulated enough tokens, set via `DERIVER_REPRESENTATION_BATCH_WORK_UNIT_TARGET_TOKENS` (`0` disables the accumulation gate). A separate setting, `DERIVER_REPRESENTATION_BATCH_TARGET_INPUT_TOKENS`, caps the conversation window fed to each deriver LLM call when draining a claimed work unit. Sub-threshold tails become eligible after `DERIVER_REPRESENTATION_BATCH_MAX_AGE_SECONDS` (default 1800 seconds), so quiet sessions eventually flush without disabling batching globally. Set the age to `0` for legacy behavior where sub-threshold tails wait indefinitely. See [token batching](/v3/documentation/core-concepts/reasoning#token-batching) for more details
 
 ## Alternative Provider Issues
 

docs/v3/documentation/core-concepts/architecture.mdx

@@ -86,7 +86,7 @@ Honcho runs as two cooperating processes: an **API server** that handles request
 
 **Write path (synchronous).** A message is stored and a reasoning task is enqueued in the same request; the API returns immediately. Nothing about the reasoning that follows blocks the caller.
 
-**Deriver + Summarizer (async, per-message).** The worker picks up queued tasks in small batches. The Deriver reads new messages and extracts conclusions about the peer--explicit statements and direct deductions. In parallel, the Summarizer periodically rolls up recent messages into short- and long-form session summaries. Both run per-message (well, per-batch) rather than on a schedule.
+**Deriver + Summarizer (async, per-message).** The worker picks up queued tasks. The Deriver reads new messages and extracts conclusions about the peer--explicit statements and direct deductions. In parallel, the Summarizer periodically rolls up recent messages into short- and long-form session summaries. Both run per-message rather than on a schedule.
 
 **Dreamer (periodic).** On a schedule (or triggered on demand), the Dreamer revisits existing conclusions to consolidate and deepen them: removing redundant or stale ones, drawing inductive conclusions across patterns that span multiple messages, and updating peer cards--compact biographical summaries of a peer. This is where memory gets richer over time, not just larger.
 

docs/v3/documentation/core-concepts/design-patterns.mdx

@@ -52,7 +52,7 @@ For unified context across Honcho plugins, set the same user peer ID (`peerName`
 
 ## Session Design
 
-Sessions define the temporal boundaries of an interaction. Where you draw those boundaries affects how summaries are generated, how context is retrieved, and when reasoning fires.
+Sessions define the temporal boundaries of an interaction. Where you draw those boundaries affects how summaries are generated and how context is retrieved.
 
 **Common session patterns**
 
@@ -66,10 +66,6 @@ Sessions define the temporal boundaries of an interaction. Where you draw those
 
 Create a **new** session when context resets (new conversation, new day, new topic); **reuse** one when context should keep accumulating (ongoing channel, persistent thread).
 
-<Warning>
-**Don't slice sessions too thin.** Honcho batches reasoning until a peer accumulates ~1,000 tokens *within a single session*, with a default age-based flush for quiet tails ([token batching](/v3/documentation/core-concepts/reasoning#token-batching)). Low-volume or trickle inputs should still append to one ongoing session rather than fragment across many, so reasoning runs with useful context instead of many small delayed batches.
-</Warning>
-
 **How cross-session reasoning works**
 
 - **Session memory** is local to an interaction — summaries and recent-message context describe only what happened there.
@@ -99,7 +95,7 @@ Two things scopes are **not**:
 ## Common Mistakes
 
 - **Splitting one identity across peer IDs** -- If the same user is `alice`, `alice-discord`, and `alice-cursor`, Honcho builds separate representations. Use one stable peer ID when you want unified memory.
-- **Too many tiny sessions** -- Summaries and recent messages are local to one session, and reasoning only fires past ~1,000 tokens per session. Splitting a continuous conversation across many sessions fragments local context and can stall reasoning. Reuse a session when context should flow continuously.
+- **Too many tiny sessions** -- Summaries and recent messages are local to one session. Splitting a continuous conversation across many sessions fragments that local context. Reuse a session when context should flow continuously.
 - **Separating agents that should collaborate** -- If agents need shared product, customer, or team context, put them in the same workspace. Separate workspaces are hard isolation boundaries.
 - **Leaving `observe_me` on for assistants** -- Wastes reasoning compute on a peer you control. Deterministic behavior doesn't need to be modeled.
 - **Turning on `observe_others` everywhere** -- Directional representations are powerful, but they add complexity. Use them when peers need distinct perspectives, not just because a session has multiple peers.

docs/v3/documentation/core-concepts/reasoning.mdx

@@ -66,21 +66,11 @@ The reasoning outputs--conclusions, summaries, peer cards--are stored as part of
 
 The diagram above shows how agents write messages to Honcho, which triggers reasoning that updates peer representations. Agents can then query representations to get additional context for their next response.
 
-### Token Batching
-
-Rather than running inference on every individual message, Honcho accumulates messages in the queue and processes them as a batch once the total token count of pending messages for a given peer representation crosses a threshold--roughly **1,000 tokens** at the current batch size. This keeps ingestion costs down, since Honcho charges based on reasoning passes, and ensures each pass has a meaningful amount of context to work with. At ~1,000 tokens the batch comfortably fits in the context window of any modern LLM, so no content is lost.
-
-If a user sends several short messages in a row (e.g., "yes", "ok", "sounds good"), those messages sit in the queue until enough content has accumulated. Once the threshold is met, the full batch is processed together in a single reasoning call.
-
-<Note>
-This batching only applies to **representation** tasks (conclusion extraction). Summary and dream tasks have their own scheduling logic and are not subject to the token threshold.
-</Note>
-
 ## Balances & Design Choices
 
 Off-the-shelf LLMs can perform formal logical reasoning, but they aren't optimized for it. Honcho uses custom models trained specifically for logical rigor (following formal reasoning rules rather than plausible-sounding text), structured output (consistent JSON schema with premises and conclusions), and efficiency (smaller, faster models tuned for this specific task). This allows Honcho to reason more reliably and at lower cost than general-purpose frontier LLMs.
 
-The approach balances quality with practical constraints. Custom models are smaller and cheaper to run, scaffolded conclusions are more token-efficient than raw conversation history, and we batch where appropriate to optimize update frequency.
+The approach balances quality with practical constraints. Custom models are smaller and cheaper to run, and scaffolded conclusions are more token-efficient than raw conversation history.
 
 Honcho's reasoning capabilities are actively being improved. Current areas of development include enhanced inductive and abductive reasoning, multi-hop  and temporal reasoning, and expanded file types and modalities. The system is designed to be extensible--new reasoning capabilities can be added without breaking existing functionality.
 

docs/v3/documentation/features/advanced/queue-status.mdx

@@ -8,9 +8,9 @@ Whenever messages are stored in Honcho, background processes kick off to [reason
 
 Reasoning is an asynchronous process and will not immediately
 generate insights for the latest message you've sent. This is
-by design: we want to reason efficiently over batches of messages
-rather than assessing each message in a vacuum. Honcho provides
-several utilities to check the status of the queue.
+by design: Honcho reasons in the background rather than on the
+write path. Honcho provides several utilities to check the status
+of the queue.
 
 <CodeGroup>
 ```python Python

docs/v3/guides/recipes/unified-memory-setup.mdx

@@ -6,7 +6,7 @@ description: "Wire one shared Honcho workspace across a chat companion, a coding
 ---
 <Info>
 This is a how-to, not an intro. It assumes you know what workspaces, peers, and
-sessions are. If you don't, start with [Core Concepts](/v3/documentation/core-concepts/architecture).
+sessions are. If you don't, start with [Core Concepts](/v3/documentation/core-concepts/).
 </Info>
 
 This guide wires four integration points into a single Honcho setup: a
@@ -109,8 +109,9 @@ and `aiPeer` there. See the [Hermes guide](/v3/guides/integrations/hermes) for t
 
 A scheduled job feeds external data (emails, meeting notes, CRM records) into Honcho.
 Attribute the messages to the peer the data is *about* — not to an agent — and group
-them into a session. **How you bound that session is the main decision here**, because
-it controls when Honcho reasons over the data (more on that below).
+them into a session. Match the session to how you want that import's local context
+to accumulate: a per-run session like `email-import-{date}`, or one ongoing
+per-source session like `email-import-gmail`.
 
 ```python
 from datetime import datetime, timezone
@@ -131,18 +132,6 @@ for i in range(0, len(messages), 100):
     session.add_messages(messages[i:i + 100])
 ```
 
-Honcho batches reasoning until a peer accumulates ~1,000 tokens *within a single session*,
-with a default age-based flush for quiet tails
-([token batching](/v3/documentation/core-concepts/reasoning#token-batching)). Match the
-session to the volume you ingest:
-
-- **High-volume runs** (a day of emails, a CRM export) clear the threshold easily — a
-  per-run session like `email-import-{date}` is fine.
-- **Low-volume or trickle imports** (a few short records at a time) should append to
-  one **ongoing per-source session** (e.g. `email-import-gmail`), so content
-  accumulates across runs instead of fragmenting into thin sessions that each flush
-  later with little context.
-
 The [Gmail](/v3/guides/gmail) and [Granola](/v3/guides/granola) guides are related
 import examples.