AbstractRuntime 0.6.0__tar.gz → 0.7.1__tar.gz

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/.github/workflows/ci.yml

@@ -29,7 +29,7 @@ jobs:
       - name: Install
         run: |
           python -m pip install -U pip
-          python -m pip install -e ".[abstractcore,mcp-worker,test]"
+          python -m pip install -e ".[test]"
       - name: Pytest basic suite
         run: python -m pytest -q -m basic
       - name: Pytest focused runtime suite
@@ -47,7 +47,16 @@ jobs:
             tests/test_visual_multi_entry_loop_overrides.py \
             tests/test_control_adapter_while.py \
             tests/test_jsonl_ledger_recovery.py \
-            tests/test_llm_client_media_artifacts.py
+            tests/test_llm_client_media_artifacts.py \
+            tests/test_session_history.py \
+            tests/test_entity_history_window.py \
+            tests/test_automation_discussion_isolation.py \
+            tests/test_automation_growing_context.py \
+            tests/test_automation_session_turns.py \
+            tests/test_budget_law_no_unrequested_caps.py \
+            tests/test_discovery_voice_openai_api_key.py \
+            tests/test_voice_openai_api_key_path.py \
+            tests/test_discovery_tts_unavailable_reason.py
 
   build:
     name: Build distributions

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/.github/workflows/release.yml

@@ -44,7 +44,7 @@ jobs:
       - name: Install
         run: |
           python -m pip install -U pip
-          python -m pip install -e ".[abstractcore,mcp-worker,test]"
+          python -m pip install -e ".[test]"
       - name: Pytest basic suite
         run: python -m pytest -q -m basic
       - name: Pytest focused runtime suite
@@ -62,7 +62,16 @@ jobs:
             tests/test_visual_multi_entry_loop_overrides.py \
             tests/test_control_adapter_while.py \
             tests/test_jsonl_ledger_recovery.py \
-            tests/test_llm_client_media_artifacts.py
+            tests/test_llm_client_media_artifacts.py \
+            tests/test_session_history.py \
+            tests/test_entity_history_window.py \
+            tests/test_automation_discussion_isolation.py \
+            tests/test_automation_growing_context.py \
+            tests/test_automation_session_turns.py \
+            tests/test_budget_law_no_unrequested_caps.py \
+            tests/test_discovery_voice_openai_api_key.py \
+            tests/test_voice_openai_api_key_path.py \
+            tests/test_discovery_tts_unavailable_reason.py
 
   docs:
     name: Build docs

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/CHANGELOG.md

@@ -5,6 +5,122 @@ All notable changes to AbstractRuntime will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+## [0.7.1] - 2026-09-28
+
+### Fixed
+
+- **Images in replayed history stay images.** When the history window drops older turns, it writes a
+  `[#TRUNCATION: ...]` notice at the start of the oldest kept message. If that message held a list of content parts
+  (text plus an image, `[{"type": "text", ...}, {"type": "image_url", ...}]`), the notice turned the whole list into
+  one string, so the model received the image's base64 as text. The notice is now added as one text part and every
+  other part is left exactly as it was. A message that starts with its `<runtime_metadata>` envelope keeps it first.
+  This affects `announce_dropped` and `window_transcript`, and so the gateway's `/runs/start` client-context window and
+  any replay that keeps images. Content of any other type is left untouched and a warning is logged.
+- **An image no longer counts as tens of thousands of tokens in the window.** `estimate_message_tokens` turned a
+  content-part list into a string, so a 150 KB inline image counted about 50,000 tokens and pushed every older turn out
+  of the history window. Text parts now count their text, and each media part (image, audio, file) counts a flat 512
+  tokens (`MEDIA_PART_TOKEN_ESTIMATE`, AbstractCore's per-image fallback). The input-budget trim
+  (`trim_messages_to_max_input_tokens`) uses the same estimate.
+
+## [0.7.0] - 2026-09-28
+
+Replayed session history is one window: the most recent 50,000 tokens of whole turns, recorded in the run.
+Library callers of `session_chat_messages` and `automation_timeline_messages` should read the **Breaking** note.
+
+### Changed
+
+- The base install and the `apple` / `gpu` profiles require AbstractCore 2.18.0 or newer. Its voice extra brings
+  AbstractVoice 0.13.0, the first release that honours the `voice_openai_api_key` setting described below.
+
+- **Session history replay is one window: the most recent 50,000 tokens.** `session_chat_messages` keeps the newest
+  turns that fit `HISTORY_REPLAY_MAX_TOKENS` (50,000) estimated tokens, as whole messages, newest first. The window has
+  no gaps, and a total of exactly 50,000 tokens fits. The 40-message cap, the 24,000-character total budget and the
+  8,000-character cut per message are removed, so no replayed message is ever cut. When the newest turn alone is larger
+  than the window, it is kept whole and the report says so (`oversize_turn_kept`). Tokens are counted with the existing
+  estimator, `memory.token_budget.estimate_message_tokens`. This window applies to automation growing mode (it
+  replaces the 40-message / 24,000-character limit of contract D), to discussion seeds (`automation_timeline_messages`)
+  and to host session seeding. The window is the only limit on replayed history; the model can use the rest of its
+  context window (operator ruling 2026-09-28, ADR-0026 §3: budgets are met by choosing whole turns, never by cutting
+  content).
+- **Library API:** `session_chat_messages` still accepts `max_messages`, `max_chars_per_message` and
+  `max_total_chars` (keyword-only, default `None`) but IGNORES them: they no longer limit anything. Hosts built against
+  0.6 (AbstractGateway 0.6.0 passes `max_messages=40, max_total_chars=24000` and treats any error as "no history") keep
+  replaying their sessions under the window. Passing any of them logs one warning and names them in
+  `report["ignored_inputs"]`. Pass `max_tokens` (a positive int) to use a different window.
+- **Breaking (library API):** `automation_timeline_messages` takes `max_tokens` instead of `max_messages` /
+  `max_chars_per_message` / `max_total_chars`. `GROWING_MAX_MESSAGES` and `GROWING_MAX_TOTAL_CHARS` are removed from
+  `abstractruntime.automations.models`.
+- **The entity chat driver and the entity visit workflow use the same window.** They used to keep only the last 10
+  turns in the prompt, without saying so. Now every turn is kept, and each prompt carries the most recent 50,000 tokens
+  of whole turns, with the `[#TRUNCATION: ...]` line when older turns were dropped. The visit records the window's
+  report in `vars._runtime.session_history`; `ChatSession` puts it on `TurnReport.history_window` (and
+  `ChatSession.history_window`).
+- **The react visit arm (the one AbstractGateway uses) sends the window too.** Its transcript is the durable
+  `context.messages`, sent by the AbstractAgent react loop on every call; before, nothing bounded it (after 12 turns of
+  ~10k tokens a request was ~117k tokens, and a poisoned tool result rode every later turn). BRIDGE now sets
+  `_runtime.history_window_tokens` (50,000); the adapter sends `window_transcript(context.messages)` on every call —
+  a tool result stays with its turn, so a 495k-character tool result drops out of the request once a newer turn
+  exists — and records the report in `vars._runtime.session_history`. The stored transcript stays whole. BRIDGE also
+  records `_runtime.history_window_turn_start` (the visitor's message), and the window keeps the turn in progress whole
+  from there (`window_transcript(..., current_turn_start=)`): an `ask_user` answer or operator guidance inside the turn
+  no longer splits off the turn's own question and tool results; a turn larger than the window is kept whole and
+  reported as `oversize_turn_kept`. HARVEST
+  keeps a turn whose adapter recorded no window (AbstractAgent older than 0.3.17 sends the whole transcript) but
+  logs a warning ("abstractagent < 0.3.17 does not apply the history window; upgrade abstractagent") and records
+  `{"window_applied": false, "reason": "agent_too_old", ...}` in `vars._runtime.session_history` (counting the messages
+  the last request carried, not the reply stored after it); a windowed turn
+  records `window_applied: true`. **The window on the react arm needs AbstractAgent 0.3.17 or newer.**
+- The `[#TRUNCATION: ...]` line is written after a stamped message's own `<runtime_metadata>` envelope, which stays at
+  the head (written in front, it made the payload boundary stack a second envelope).
+- **Breaking (library API):** the `history_turns` parameter of `build_visit_workflow` and `ChatSession` is removed,
+  with `DEFAULT_HISTORY_TURNS` (no caller in the framework passed it). The entity visit no longer sets the
+  per-message character limits `_limits.max_tool_message_chars` (32,000) and `_limits.max_message_chars` (80,000) on
+  re-sent history, and `VISIT_HISTORY_TOOL_RESULT_CAP_CHARS` / `VISIT_HISTORY_MESSAGE_CAP_CHARS` are removed. A
+  single oversized tool result is still limited by AbstractAgent's own guard for oversized messages (200,000 characters).
+- `trim_messages_to_max_input_tokens` (used only when a caller sets a positive `max_input_tokens`) keeps each tool
+  result together with the assistant tool call before it. It used to drop the call and keep the result, which
+  OpenAI-style APIs reject.
+
+- **The context mode decides whether an automation's target reads history.** At admission the runtime sets
+  `use_context` (and `include_context` when present) to `true` for growing occurrences and `false` for independent
+  ones, and to `true` for discussion forks. A `use_context: false` frozen in an older definition no longer makes a
+  growing automation or a discussion replay nothing (basic-agent's `use_context` pin defaults to `false`). The run
+  records `_runtime.automation_context = {mode, use_context, target_use_context}`. Occurrences that were already
+  admitted before the upgrade keep their frozen inputs.
+
+### Added
+
+- Voice discovery (`local_get_voice_catalog`, `local_list_tts_models`, `local_list_stt_models`) accepts a
+  host-supplied `voice_openai_api_key` and passes it to AbstractVoice as the plugin setting of the same name (the
+  OpenAI credential for its `openai` engines; AbstractVoice reads no environment variable for it). The discovery
+  facade and the local clients accept and forward it (`AbstractCoreDiscoveryFacade.get_voice_catalog` /
+  `list_tts_models` / `list_stt_models(voice_openai_api_key=...)`); the remote client accepts it and never sends it.
+  In `llm_kwargs` it reaches the voice plugin through the provider's `config` and changes no text request; tests
+  prove this on real OpenAI, LM Studio, Ollama and MLX provider classes, with the network refused.
+- **The window is recorded.** `session_chat_messages` and `automation_timeline_messages` return a `ReplayedHistory`
+  (a list of messages) with a `.report`: `policy`, `max_tokens`, `token_estimator`, `replayed_messages`,
+  `replayed_tokens`, `dropped_messages`, `dropped_tokens`, `dropped_counts_complete`, `oversize_turn_kept`. A growing
+  occurrence records it in `vars._runtime.session_history`, so the `automation.admitted` record's frozen inputs carry
+  it too. A discussion root records its seed window the same way. When older turns are dropped, the oldest replayed
+  message starts with a `[#TRUNCATION: ...]` line that gives the number of dropped messages and tokens and the window.
+  New exports at the package root: `HISTORY_REPLAY_MAX_TOKENS`, `ReplayedHistory`, `fold_history_window`,
+  `announce_dropped` (writes that `[#TRUNCATION: ...]` line after a host's own `fold_history_window` call, for example
+  on client-sent history; `session_history._announce_dropped` stays as an alias) and `window_transcript` (the window
+  over a transcript the caller already holds).
+- `local_list_tts_models` reports why a provider cannot be listed: when the listing is unavailable, `error` carries
+  AbstractVoice's `unavailable_reason` (for example "no OpenAI API key is configured ..." or an unknown provider id).
+  It used to return `available: false, error: null`.
+- Replay reads turns newest-first in batches that double in size, and stops once the window is full. A long session
+  therefore costs about as much as its window holds.
+
+### Tests and CI
+
+- CI installs the extras that exist (`.[test]`) and runs the history-window, entity window, automation timeline,
+  input-trim and voice-key tests. The five tests that need the sibling `abstractflow/` checkout or the
+  `abstractagent` package skip when those are absent (a standalone checkout or an sdist).
+
 ## [0.6.0] - 2026-09-27
 
 Automations v1: run a workflow on a schedule or on request as a durable, crash-safe controller run. Hosts that

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.6.0
+Version: 0.7.1
 Summary: AbstractRuntime: a durable graph runner designed to pair with AbstractCore.
 Project-URL: AbstractCore (website), https://www.abstractcore.ai/
 Project-URL: AbstractRuntime (GitHub), https://github.com/lpalbou/abstractruntime
@@ -20,7 +20,7 @@ Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Requires-Python: >=3.10
-Requires-Dist: abstractcore[audio,music,remote,tools,vision,voice]>=2.16.0
+Requires-Dist: abstractcore[audio,music,remote,tools,vision,voice]>=2.18.0
 Requires-Dist: abstractmemory>=0.3.0
 Requires-Dist: abstractsemantics>=0.0.5
 Requires-Dist: anyio<5.0.0,>=4.12.1
@@ -35,14 +35,14 @@ Requires-Dist: reportlab<5.0.0,>=4.0.0
 Requires-Dist: restrictedpython>=7.0
 Requires-Dist: unstructured[docx,odt,pptx,rtf,xlsx]<0.19.0,>=0.18.32
 Provides-Extra: apple
-Requires-Dist: abstractcore[all-apple]>=2.16.0; extra == 'apple'
+Requires-Dist: abstractcore[all-apple]>=2.18.0; extra == 'apple'
 Requires-Dist: setuptools<82.0.0,>=80.10.2; extra == 'apple'
 Provides-Extra: docs
 Requires-Dist: mkdocs-material>=9.0.0; extra == 'docs'
 Requires-Dist: mkdocs>=1.6.0; extra == 'docs'
 Requires-Dist: pymdown-extensions>=10.0; extra == 'docs'
 Provides-Extra: gpu
-Requires-Dist: abstractcore[all-gpu]>=2.16.0; extra == 'gpu'
+Requires-Dist: abstractcore[all-gpu]>=2.18.0; extra == 'gpu'
 Requires-Dist: setuptools<82.0.0,>=77.0.3; extra == 'gpu'
 Provides-Extra: test
 Requires-Dist: pytest>=7.0.0; extra == 'test'
@@ -54,7 +54,7 @@ Description-Content-Type: text/markdown
 
 It is designed for long-running workflows that must survive restarts and explicitly model blocking (human input, timers, external events, subworkflows) without keeping Python stacks alive.
 
-**Version:** 0.6.0 • **Python:** 3.10+
+**Version:** 0.7.1 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -82,7 +82,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-The base install includes AbstractCore 2.16.0 or newer with remote provider,
+The base install includes AbstractCore 2.18.0 or newer with remote provider,
 tool, vision, voice, audio, and music integration, plus the
 `abstractruntime-mcp-worker` entry point. It keeps inference remote/light by
 default: local engines such as MLX, vLLM, HuggingFace/Torch, Diffusers, and
@@ -146,7 +146,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.6.0)
+## What’s included (v0.7.1)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/README.md

@@ -4,7 +4,7 @@
 
 It is designed for long-running workflows that must survive restarts and explicitly model blocking (human input, timers, external events, subworkflows) without keeping Python stacks alive.
 
-**Version:** 0.6.0 • **Python:** 3.10+
+**Version:** 0.7.1 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -32,7 +32,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-The base install includes AbstractCore 2.16.0 or newer with remote provider,
+The base install includes AbstractCore 2.18.0 or newer with remote provider,
 tool, vision, voice, audio, and music integration, plus the
 `abstractruntime-mcp-worker` entry point. It keeps inference remote/light by
 default: local engines such as MLX, vLLM, HuggingFace/Torch, Diffusers, and
@@ -96,7 +96,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.6.0)
+## What’s included (v0.7.1)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/docs/README.md

@@ -30,6 +30,7 @@ In this repo, the AbstractCore wiring lives under `src/abstractruntime/integrati
 - `tools-comms.md` — enabling the optional comms toolset (email/WhatsApp/Telegram)
 - `tool-approval.md` — tool risk tiers, the run-policy rank ceiling, and per-call refiners (the `send_email` self-recipient rule)
 - `api.md#workflowbundles-flow-and-visualflow-distribution` — VisualFlow compiler APIs, media nodes, and document nodes (`read_pdf` / `write_pdf` / `write_docx`)
+- `api.md#sessions-and-history` — session history replay: one window, the most recent 50,000 tokens of whole turns (`HISTORY_REPLAY_MAX_TOKENS`), returned as a `ReplayedHistory` whose `.report` records what was replayed and dropped
 - `api.md#run-history-bundle-export-portable-replay-artifact` — run history bundles, including `resolved_actions` summaries for cross-client capability replay
 
 ## Features (reference)

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/docs/api.md

@@ -251,7 +251,12 @@ from abstractruntime.triggers import get_trigger_adapter, trigger_sources
 Implementation: `src/abstractruntime/session_turns.py`, `src/abstractruntime/session_history.py`, `src/abstractruntime/core/run_attribution.py`.
 
 - `select_session_turns(run_store, session_id, *, include_occurrences=True, until_ms=None, automation_id=None, through_occurrence=None, include_drafts=False, limit=50)` (package root): a session's turns, oldest first. Turns are parent-less runs except automation controllers, plus automation occurrences (a retried occurrence counts once, as its newest attempt); child runs, runtime-internal runs, legacy scheduled wrappers and draft-test runs are left out
-- `session_chat_messages(run_store=, ledger_store=, artifact_store=, session_id=, max_messages=40, max_total_chars=24000, ..., automation_id=None, through_occurrence=None, strict=False)` (package root): the session's completed turns as user/assistant message pairs, newest kept under the budget; in a discussion session the discussion's seed comes first. `strict=True` raises `SessionHistoryError` (`reason_code = "history_unavailable"`) instead of returning a partial history
+- `session_chat_messages(run_store=, ledger_store=, artifact_store=, session_id=, max_tokens=HISTORY_REPLAY_MAX_TOKENS, until_ms=None, exclude_run_ids=None, automation_id=None, through_occurrence=None, strict=False)` (package root): the session's completed turns as user/assistant message pairs; in a discussion session the discussion's seed comes first. Returns a `ReplayedHistory` (a list of messages) whose `.report` says what was replayed and dropped. `strict=True` raises `SessionHistoryError` (`reason_code = "history_unavailable"`) instead of returning a partial history. `max_messages`, `max_total_chars` and `max_chars_per_message` (keyword-only, default `None`) are the caps retired in 0.7.0: they are accepted so hosts built against 0.6 (AbstractGateway 0.6.0) still get their history, and ignored. Passing any of them logs one warning and names them in `report["ignored_inputs"]`
+- The history window: `HISTORY_REPLAY_MAX_TOKENS = 50_000` (package root). Replay keeps the most recent turns that fit 50,000 estimated tokens, newest first, as whole messages. There is no message-count cap and no character cap, and no message is ever cut. The fold stops at the first older turn that does not fit, so the window has no gaps. A total of exactly 50,000 tokens fits. One exception: when the newest turn alone is larger than the window, it is kept whole (`oversize_turn_kept: true`), because cutting it would lose content and dropping it would replay nothing. The model can use the rest of its context window; if a turn is too large for the model, the provider reports the error. Tokens are counted with `abstractruntime.memory.token_budget.estimate_message_tokens`: for a content-part list it counts the text parts' text plus `MEDIA_PART_TOKEN_ESTIMATE` (512) for each media part (`MEDIA_PART_TYPES`: image, audio, file), never the part's base64; any other part (a tool result, a thinking block) counts by its text (0.7.1). `max_tokens` must be a positive int
+- `ReplayedHistory.report`: `{policy: "most_recent_whole_turns", max_tokens, token_estimator, replayed_messages, replayed_tokens, dropped_messages, dropped_tokens, dropped_counts_complete, oversize_turn_kept}`. Replay stops reading once the window is full, so in a long session `dropped_counts_complete` is `false` and the dropped counts cover only the turns it read. When turns were dropped, the oldest replayed message starts with a `[#TRUNCATION: N earlier message(s) ... were dropped from replay by the history window ...]` line (ADR-0026). Hosts record the report in the run as `vars._runtime.session_history`
+- `fold_history_window(pairs, *, max_tokens=HISTORY_REPLAY_MAX_TOKENS)` (package root): the window itself, applied to chronological turns (lists of whole messages); returns `(kept, report)`
+- `announce_dropped(messages, report, *, stamp_metadata=True)` (package root): writes the window's `[#TRUNCATION: ...]` notice at the start of the oldest kept message, in place, when `report` says turns were dropped. Use it after your own `fold_history_window` call (for example on client-sent history) so the notice matches session replay. `stamp_metadata=True` also adds `metadata.replay_truncated` and `metadata.history_window` to that message; pass `False` for plain role/content messages. When the message's content is a content-part list (`[{"type": "text", ...}, {"type": "image_url", ...}]`), the notice is added as one `{"type": "text"}` part and every other part is left as it is, so images stay images (0.7.1); a stamped head keeps its `<runtime_metadata>` envelope first. Content of any other type is left untouched and a warning is logged. `_announce_dropped` is kept as an alias of the pre-0.7.0 private name
+- `window_transcript(messages, *, max_tokens=HISTORY_REPLAY_MAX_TOKENS, current_turn_start=None)` (package root): the same window over a transcript you already hold (a turn is a user message and the messages after it). `current_turn_start` is the index of the message that opened the turn in progress: from there on everything is one turn, the newest, always kept whole (`oversize_turn_kept` when it alone exceeds the window), whatever user-role messages a loop adds inside it; an index out of range raises `ValueError`. Returns a `ReplayedHistory` of copies with the notice written by `announce_dropped(..., stamp_metadata=False)`. The entity chat driver and the entity visit workflow use it for their prompts. The visit records the report in `vars._runtime.session_history`; the chat driver puts it on `TurnReport.history_window`. On the react visit arm, BRIDGE sets `_runtime.history_window_tokens` (50,000) and `_runtime.history_window_turn_start` (the visitor's message) and the AbstractAgent react loop (0.3.17 or newer) sends `window_transcript(context.messages)` on each call and records the report; the stored transcript stays whole. The report carries `window_applied: true`; with an older AbstractAgent that records no window the turn still completes, a warning is logged and the report is `{"window_applied": false, "reason": "agent_too_old", ...}` (the whole transcript was sent). When the oldest kept message carries a `<runtime_metadata>` envelope, the notice is written after it
 - `session_attribution(run_store, session_id)` (`abstractruntime.core.run_attribution`): `None` or `{"kind": "chat" | "automation" | "occurrence" | "discussion", ...}`; a discussion adds its validated root, automation, occurrence and workspace. Raises `SessionAttributionError` when the lookup cannot be completed
 - `is_draft_lifecycle(run_lifecycle)` (package root): whether a run's lifecycle value marks a draft test run
 
@@ -272,7 +277,7 @@ from Core route resolution and persisted from `LLM_CALL` results.
 
 ### AbstractCore (LLM + tools)
 
-Requires: `pip install abstractruntime` (AbstractCore 2.16.0 or newer is part of the base install).
+Requires: `pip install abstractruntime` (AbstractCore 2.18.0 or newer is part of the base install).
 
 Implementation: `src/abstractruntime/integrations/abstractcore/*`.
 
@@ -286,6 +291,7 @@ Entry points:
 - effect handler wiring: `build_effect_handlers(...)` (`src/abstractruntime/integrations/abstractcore/effect_handlers.py`)
 - tool executors: `MappingToolExecutor`, `AbstractCoreToolExecutor`, `PassthroughToolExecutor`, `ApprovalToolExecutor`, `ToolApprovalPolicy` (`src/abstractruntime/integrations/abstractcore/tool_executor.py`)
 - discovery-facade delegation is implemented by the configured AbstractCore LLM clients in `src/abstractruntime/integrations/abstractcore/llm_client.py` (`list_providers`, `list_provider_models`, `get_voice_catalog`, `list_tts_models`, `list_stt_models`, `list_music_providers`, `list_music_models`, `list_vision_provider_models`, `list_cached_vision_models`, `list_vision_adapters`)
+- the host's OpenAI credential for AbstractVoice's `openai` engines, `voice_openai_api_key`, travels two ways. For discovery, pass it to `get_voice_catalog`, `list_tts_models` or `list_stt_models`; the local clients hand it to the voice plugin's config, and a remote client never sends it (a remote AbstractCore server uses its own voice configuration). For execution, put it in `create_local_runtime(llm_kwargs={"voice_openai_api_key": ...})`. Constructor kwargs become the provider's `config`, which is also the capability-plugin config. Providers read only the keys they name, so a `voice_*` key changes no text request (tests `tests/test_voice_openai_api_key_path.py`)
 - host-facade client delegation is implemented by the configured AbstractCore LLM clients in `src/abstractruntime/integrations/abstractcore/llm_client.py` (`get_prompt_cache_capabilities`, `get_prompt_cache_stats`, `prompt_cache_set`, `prompt_cache_update`, `prompt_cache_fork`, `prompt_cache_clear`, `prompt_cache_prepare_modules`, `upsert_text_bloc`, `get_bloc_record`, `list_blocs`, `get_bloc_kv_manifest`, `ensure_bloc_kv_artifact`, `load_bloc_kv_artifact`, `list_bloc_kv_artifacts`, `delete_bloc_kv_artifact`, `prune_bloc_kv_artifacts`, `delete_bloc`, `get_model_residency_capabilities`, `list_model_residency`, `load_model_residency`, `unload_model_residency`, `get_memory_snapshot`, `list_session_prompt_caches`, `clear_session_prompt_caches`, `lock_model_residency`, `unlock_model_residency`, `get_context_estimate`); the last six are optional in the client contract, and the facade returns `{"ok": false, "supported": false, ...}` when the configured client does not implement one
 - switching the default model (`set_default_provider_model` on the pooled client) unloads the previous in-process model unless an owner in the process still uses it; `list_model_residency` diagnostics report `pending_ejects` and `last_switch_ejects`, and `unload_model_residency(runtime_id=...)` accepts any listed `local:<task>:<provider>:<model>` id, including `local:embedding:<provider>:<model>` rows (see `integrations/abstractcore.md#unloading-and-switching-models`)
 - `lock_model_residency`, `unlock_model_residency`, and `get_context_estimate` accept an optional payload mapping and/or keyword arguments (keyword arguments win on conflicts); a lock requires provider-verified residency — locking a non-resident pair refuses with a structured `model_not_resident` payload (load with `lock: true` instead; remotely the Core server's HTTP 409 refusal is converted to the same payload), while unlock never requires residency so a locked-but-evicted pair is always releasable; a locked model refuses `unload_model_residency` with a structured `model_locked` payload — locally as a client-side per-`(provider, model)` lock, remotely by converting the Core server's HTTP 409 refusal — and unloads only with `force=true`, releasing the lock only after the unload succeeds

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/docs/architecture.md

@@ -1,7 +1,7 @@
 # AbstractRuntime — Architecture
 
-> Updated: 2026-09-27
-> Version: 0.6.0
+> Updated: 2026-09-28
+> Version: 0.7.1
 > Scope: this describes **what is implemented in this repository**.
 
 AbstractRuntime is a **durable workflow runtime**: it executes workflow graphs as a persisted state machine with explicit waits (user, time, events, jobs, subworkflows). A run can pause for hours/days and resume **without** keeping Python stacks/coroutines alive.

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/docs/automations.md

@@ -293,13 +293,23 @@ controller is woken with `max_steps=0`; the host (or `drive_automation`) then ti
 | | Independent (default) | Growing |
 |---|---|---|
 | Session | a new session per occurrence, named after its attempt-1 run id | the automation's session, `automation:<automation_id>` |
-| History given to the occurrence | none | the automation's previous turns as `input_data.context.messages`, at most 40 messages and 24,000 characters |
+| History given to the occurrence | none | the automation's previous turns as `input_data.context.messages`: the most recent 50,000 tokens of whole turns (the session history window) |
+| `use_context` given to the target | `false` | `true` |
 | `_meta.occurrence.session_kind` | `occurrence` | `automation` |
 
+The context mode alone decides whether the target reads history: at admission the runtime sets the target's
+`use_context` input (and `include_context` when the target has it) to `true` for growing and `false` for
+independent, whatever the definition's `target.input_data` says. A discussion always gets `use_context: true`.
+The run records the decision as `_runtime.automation_context = {mode, use_context, target_use_context}`, where
+`target_use_context` is the value the definition carried. Automations created before this rule, with
+`use_context: false` in their target, now replay their history without being revised.
+
 Growing history is read at admission and frozen with the occurrence's inputs, so every retry sees the same history.
 It is read strictly: when it cannot be read (a store without a run index, for example), the admission fails instead
 of running the occurrence without its context. History keeps whole turns, newest first, and says so in the oldest
-kept message when older turns were dropped.
+kept message when older turns were dropped. The occurrence run records what was replayed in
+`vars._runtime.session_history` (`replayed_messages`, `replayed_tokens`, `dropped_messages`, `dropped_tokens`,
+`max_tokens`, ...), and the `automation.admitted` record carries the same values in its frozen inputs.
 
 Only completed turns with both a prompt and an answer are replayed. A retried occurrence counts once, as its last
 attempt.
@@ -318,8 +328,8 @@ actor_id=None)` starts a separate conversation about the automation as it stood
 - It is seeded **once** with the automation's whole conversation through occurrence N, whatever the context mode:
   one user/assistant pair per finished occurrence 1..N (its last attempt), the occurrence's trigger/task turn and its
   answer, oldest first (`automation_timeline_messages(...)`). A failed or stopped occurrence stays in the timeline,
-  its answer saying so. The pairs fit the history budget (40 messages, 24 000 characters, 8 000 per message); the
-  oldest are dropped first. The first user message starts with a summary line: `[Automation "<title>": <n>
+  its answer saying so. The pairs go through the session history window (the most recent 50,000 tokens of whole
+  turns, no message ever cut); the oldest are dropped first. The first user message starts with a summary line: `[Automation "<title>": <n>
   occurrence(s) through occurrence N, showing the last K. The automation's files are mounted READ-ONLY at <path>;
   your own workspace <path> is writable.]`. The seed is stored in `_meta.discussion.seed_messages` of the root run.
 - It works in its **own writable workspace**, `workspace_root`, which the host allocates (it must differ from the
@@ -349,7 +359,7 @@ the same root, and that root must be a parent-less run of this session that carr
 discussion provenance too.
 
 In a discussion session, `session_chat_messages` replays the seed first, as the oldest history, and drops it first
-under the budget.
+under the history window.
 
 ### Read-only mounts
 
@@ -547,7 +557,8 @@ its newest attempt. `automation_id` keeps only that automation's occurrences (ot
 index to look it up in.
 
 `session_chat_messages(..., automation_id=None, through_occurrence=None, strict=False)` replays those turns as
-user/assistant message pairs under a message and character budget. With `strict=True` it raises
+user/assistant message pairs under the session history window (the most recent `HISTORY_REPLAY_MAX_TOKENS` = 50,000
+tokens of whole turns; see [API](api.md#sessions-and-history)). With `strict=True` it raises
 `SessionHistoryError` (`reason_code = "history_unavailable"`) instead of returning a partial history: a store without
 a run index, a missing occurrence, or a discussion whose seed is missing or cannot be read. Automation admission and
 discussion seeding always read strictly.
@@ -606,7 +617,8 @@ receives its result directly.
   controller does not wait on `event` sources.
 - Occurrences run one at a time (`serial`), missed ticks coalesce, and a failed occurrence never stops the
   automation (`failure: "continue"`). These policies cannot be changed.
-- Growing history is bounded (40 messages, 24,000 characters, whole turns) and is not summarized automatically.
+- Growing history is the most recent 50,000 tokens of whole turns and is not summarized automatically; older turns
+  drop out of the replay (they stay in the store).
 - Tools outside `TOOL_EFFECT_CLASSES`, such as third-party MCP tools, still ask for approval under `auto`.
 - Retries repeat external effects.
 - One writer process per store; the mutation lock does not coordinate separate processes.

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/docs/backlog/planned/runtime_systemic_reliability/0053_bounded_run_vars_growth.md

@@ -24,8 +24,11 @@ Unbounded or weakly-bounded growth surfaces:
   unbounded in bytes.
 - `evidence_warnings` unbounded (1948-1953).
 - `_runtime.inbox` unbounded if the workflow never drains.
-- `context.messages` / visit sheets have no stated ceiling (visit history
-  is trimmed to 2×history_turns — verified OK; the sheet is not).
+- `context.messages` / visit sheets have no stated ceiling. Visit history
+  (`_visit.history`) is no longer trimmed to 2×history_turns: since 0.7.0
+  (ADR-0026, operator ruling 2026-09-28) the whole visit is kept and each
+  prompt reads it through the 50k-token history window, so it grows with the
+  visit like `context.messages` (bounded by the idle close, not by a count).
 - events_inbox is capped at 500 envelopes (gateway-side today) but envelope
   SIZE is unbounded... bridge clamps bodies at 32KB (gateway F7) — runtime
   gets the cap with 0051.

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/docs/troubleshooting.md

@@ -20,7 +20,7 @@ Fix:
 - Install or upgrade the base Runtime package. LLM/tools integration, common
   remote-light multimodal dependencies, and the MCP worker entry point are part
   of the base install.
-- The current AbstractCore integration expects `abstractcore>=2.16.0`.
+- The current AbstractCore integration expects `abstractcore>=2.18.0`.
 
 Verify:
 

{abstractruntime-0.6.0 → abstractruntime-0.7.1}/llms-full.txt

@@ -52,7 +52,7 @@ See llms.txt for the linked index.
 
 It is designed for long-running workflows that must survive restarts and explicitly model blocking (human input, timers, external events, subworkflows) without keeping Python stacks alive.
 
-**Version:** 0.6.0 • **Python:** 3.10+
+**Version:** 0.7.1 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -80,7 +80,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-The base install includes AbstractCore 2.16.0 or newer with remote provider,
+The base install includes AbstractCore 2.18.0 or newer with remote provider,
 tool, vision, voice, audio, and music integration, plus the
 `abstractruntime-mcp-worker` entry point. It keeps inference remote/light by
 default: local engines such as MLX, vLLM, HuggingFace/Torch, Diffusers, and
@@ -144,7 +144,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.6.0)
+## What’s included (v0.7.1)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)
@@ -429,8 +429,8 @@ rt = create_local_runtime(provider="ollama", model="qwen3:4b")
 
 # AbstractRuntime — Architecture
 
-> Updated: 2026-09-27
-> Version: 0.6.0
+> Updated: 2026-09-28
+> Version: 0.7.1
 > Scope: this describes **what is implemented in this repository**.
 
 AbstractRuntime is a **durable workflow runtime**: it executes workflow graphs as a persisted state machine with explicit waits (user, time, events, jobs, subworkflows). A run can pause for hours/days and resume **without** keeping Python stacks/coroutines alive.
@@ -1106,7 +1106,12 @@ from abstractruntime.triggers import get_trigger_adapter, trigger_sources
 Implementation: `src/abstractruntime/session_turns.py`, `src/abstractruntime/session_history.py`, `src/abstractruntime/core/run_attribution.py`.
 
 - `select_session_turns(run_store, session_id, *, include_occurrences=True, until_ms=None, automation_id=None, through_occurrence=None, include_drafts=False, limit=50)` (package root): a session's turns, oldest first. Turns are parent-less runs except automation controllers, plus automation occurrences (a retried occurrence counts once, as its newest attempt); child runs, runtime-internal runs, legacy scheduled wrappers and draft-test runs are left out
-- `session_chat_messages(run_store=, ledger_store=, artifact_store=, session_id=, max_messages=40, max_total_chars=24000, ..., automation_id=None, through_occurrence=None, strict=False)` (package root): the session's completed turns as user/assistant message pairs, newest kept under the budget; in a discussion session the discussion's seed comes first. `strict=True` raises `SessionHistoryError` (`reason_code = "history_unavailable"`) instead of returning a partial history
+- `session_chat_messages(run_store=, ledger_store=, artifact_store=, session_id=, max_tokens=HISTORY_REPLAY_MAX_TOKENS, until_ms=None, exclude_run_ids=None, automation_id=None, through_occurrence=None, strict=False)` (package root): the session's completed turns as user/assistant message pairs; in a discussion session the discussion's seed comes first. Returns a `ReplayedHistory` (a list of messages) whose `.report` says what was replayed and dropped. `strict=True` raises `SessionHistoryError` (`reason_code = "history_unavailable"`) instead of returning a partial history. `max_messages`, `max_total_chars` and `max_chars_per_message` (keyword-only, default `None`) are the caps retired in 0.7.0: they are accepted so hosts built against 0.6 (AbstractGateway 0.6.0) still get their history, and ignored. Passing any of them logs one warning and names them in `report["ignored_inputs"]`
+- The history window: `HISTORY_REPLAY_MAX_TOKENS = 50_000` (package root). Replay keeps the most recent turns that fit 50,000 estimated tokens, newest first, as whole messages. There is no message-count cap and no character cap, and no message is ever cut. The fold stops at the first older turn that does not fit, so the window has no gaps. A total of exactly 50,000 tokens fits. One exception: when the newest turn alone is larger than the window, it is kept whole (`oversize_turn_kept: true`), because cutting it would lose content and dropping it would replay nothing. The model can use the rest of its context window; if a turn is too large for the model, the provider reports the error. Tokens are counted with `abstractruntime.memory.token_budget.estimate_message_tokens`: for a content-part list it counts the text parts' text plus `MEDIA_PART_TOKEN_ESTIMATE` (512) for each media part (`MEDIA_PART_TYPES`: image, audio, file), never the part's base64; any other part (a tool result, a thinking block) counts by its text (0.7.1). `max_tokens` must be a positive int
+- `ReplayedHistory.report`: `{policy: "most_recent_whole_turns", max_tokens, token_estimator, replayed_messages, replayed_tokens, dropped_messages, dropped_tokens, dropped_counts_complete, oversize_turn_kept}`. Replay stops reading once the window is full, so in a long session `dropped_counts_complete` is `false` and the dropped counts cover only the turns it read. When turns were dropped, the oldest replayed message starts with a `[#TRUNCATION: N earlier message(s) ... were dropped from replay by the history window ...]` line (ADR-0026). Hosts record the report in the run as `vars._runtime.session_history`
+- `fold_history_window(pairs, *, max_tokens=HISTORY_REPLAY_MAX_TOKENS)` (package root): the window itself, applied to chronological turns (lists of whole messages); returns `(kept, report)`
+- `announce_dropped(messages, report, *, stamp_metadata=True)` (package root): writes the window's `[#TRUNCATION: ...]` notice at the start of the oldest kept message, in place, when `report` says turns were dropped. Use it after your own `fold_history_window` call (for example on client-sent history) so the notice matches session replay. `stamp_metadata=True` also adds `metadata.replay_truncated` and `metadata.history_window` to that message; pass `False` for plain role/content messages. When the message's content is a content-part list (`[{"type": "text", ...}, {"type": "image_url", ...}]`), the notice is added as one `{"type": "text"}` part and every other part is left as it is, so images stay images (0.7.1); a stamped head keeps its `<runtime_metadata>` envelope first. Content of any other type is left untouched and a warning is logged. `_announce_dropped` is kept as an alias of the pre-0.7.0 private name
+- `window_transcript(messages, *, max_tokens=HISTORY_REPLAY_MAX_TOKENS, current_turn_start=None)` (package root): the same window over a transcript you already hold (a turn is a user message and the messages after it). `current_turn_start` is the index of the message that opened the turn in progress: from there on everything is one turn, the newest, always kept whole (`oversize_turn_kept` when it alone exceeds the window), whatever user-role messages a loop adds inside it; an index out of range raises `ValueError`. Returns a `ReplayedHistory` of copies with the notice written by `announce_dropped(..., stamp_metadata=False)`. The entity chat driver and the entity visit workflow use it for their prompts. The visit records the report in `vars._runtime.session_history`; the chat driver puts it on `TurnReport.history_window`. On the react visit arm, BRIDGE sets `_runtime.history_window_tokens` (50,000) and `_runtime.history_window_turn_start` (the visitor's message) and the AbstractAgent react loop (0.3.17 or newer) sends `window_transcript(context.messages)` on each call and records the report; the stored transcript stays whole. The report carries `window_applied: true`; with an older AbstractAgent that records no window the turn still completes, a warning is logged and the report is `{"window_applied": false, "reason": "agent_too_old", ...}` (the whole transcript was sent). When the oldest kept message carries a `<runtime_metadata>` envelope, the notice is written after it
 - `session_attribution(run_store, session_id)` (`abstractruntime.core.run_attribution`): `None` or `{"kind": "chat" | "automation" | "occurrence" | "discussion", ...}`; a discussion adds its validated root, automation, occurrence and workspace. Raises `SessionAttributionError` when the lookup cannot be completed
 - `is_draft_lifecycle(run_lifecycle)` (package root): whether a run's lifecycle value marks a draft test run
 
@@ -1127,7 +1132,7 @@ from Core route resolution and persisted from `LLM_CALL` results.
 
 ### AbstractCore (LLM + tools)
 
-Requires: `pip install abstractruntime` (AbstractCore 2.16.0 or newer is part of the base install).
+Requires: `pip install abstractruntime` (AbstractCore 2.18.0 or newer is part of the base install).
 
 Implementation: `src/abstractruntime/integrations/abstractcore/*`.
 
@@ -1141,6 +1146,7 @@ Entry points:
 - effect handler wiring: `build_effect_handlers(...)` (`src/abstractruntime/integrations/abstractcore/effect_handlers.py`)
 - tool executors: `MappingToolExecutor`, `AbstractCoreToolExecutor`, `PassthroughToolExecutor`, `ApprovalToolExecutor`, `ToolApprovalPolicy` (`src/abstractruntime/integrations/abstractcore/tool_executor.py`)
 - discovery-facade delegation is implemented by the configured AbstractCore LLM clients in `src/abstractruntime/integrations/abstractcore/llm_client.py` (`list_providers`, `list_provider_models`, `get_voice_catalog`, `list_tts_models`, `list_stt_models`, `list_music_providers`, `list_music_models`, `list_vision_provider_models`, `list_cached_vision_models`, `list_vision_adapters`)
+- the host's OpenAI credential for AbstractVoice's `openai` engines, `voice_openai_api_key`, travels two ways. For discovery, pass it to `get_voice_catalog`, `list_tts_models` or `list_stt_models`; the local clients hand it to the voice plugin's config, and a remote client never sends it (a remote AbstractCore server uses its own voice configuration). For execution, put it in `create_local_runtime(llm_kwargs={"voice_openai_api_key": ...})`. Constructor kwargs become the provider's `config`, which is also the capability-plugin config. Providers read only the keys they name, so a `voice_*` key changes no text request (tests `tests/test_voice_openai_api_key_path.py`)
 - host-facade client delegation is implemented by the configured AbstractCore LLM clients in `src/abstractruntime/integrations/abstractcore/llm_client.py` (`get_prompt_cache_capabilities`, `get_prompt_cache_stats`, `prompt_cache_set`, `prompt_cache_update`, `prompt_cache_fork`, `prompt_cache_clear`, `prompt_cache_prepare_modules`, `upsert_text_bloc`, `get_bloc_record`, `list_blocs`, `get_bloc_kv_manifest`, `ensure_bloc_kv_artifact`, `load_bloc_kv_artifact`, `list_bloc_kv_artifacts`, `delete_bloc_kv_artifact`, `prune_bloc_kv_artifacts`, `delete_bloc`, `get_model_residency_capabilities`, `list_model_residency`, `load_model_residency`, `unload_model_residency`, `get_memory_snapshot`, `list_session_prompt_caches`, `clear_session_prompt_caches`, `lock_model_residency`, `unlock_model_residency`, `get_context_estimate`); the last six are optional in the client contract, and the facade returns `{"ok": false, "supported": false, ...}` when the configured client does not implement one
 - switching the default model (`set_default_provider_model` on the pooled client) unloads the previous in-process model unless an owner in the process still uses it; `list_model_residency` diagnostics report `pending_ejects` and `last_switch_ejects`, and `unload_model_residency(runtime_id=...)` accepts any listed `local:<task>:<provider>:<model>` id, including `local:embedding:<provider>:<model>` rows (see `integrations/abstractcore.md#unloading-and-switching-models`)
 - `lock_model_residency`, `unlock_model_residency`, and `get_context_estimate` accept an optional payload mapping and/or keyword arguments (keyword arguments win on conflicts); a lock requires provider-verified residency — locking a non-resident pair refuses with a structured `model_not_resident` payload (load with `lock: true` instead; remotely the Core server's HTTP 409 refusal is converted to the same payload), while unlock never requires residency so a locked-but-evicted pair is always releasable; a locked model refuses `unload_model_residency` with a structured `model_locked` payload — locally as a client-side per-`(provider, model)` lock, remotely by converting the Core server's HTTP 409 refusal — and unloads only with `force=true`, releasing the lock only after the unload succeeds
@@ -1627,7 +1633,7 @@ Fix:
 - Install or upgrade the base Runtime package. LLM/tools integration, common
   remote-light multimodal dependencies, and the MCP worker entry point are part
   of the base install.
-- The current AbstractCore integration expects `abstractcore>=2.16.0`.
+- The current AbstractCore integration expects `abstractcore>=2.18.0`.
 
 Verify:
 
@@ -3756,13 +3762,23 @@ controller is woken with `max_steps=0`; the host (or `drive_automation`) then ti
 | | Independent (default) | Growing |
 |---|---|---|
 | Session | a new session per occurrence, named after its attempt-1 run id | the automation's session, `automation:<automation_id>` |
-| History given to the occurrence | none | the automation's previous turns as `input_data.context.messages`, at most 40 messages and 24,000 characters |
+| History given to the occurrence | none | the automation's previous turns as `input_data.context.messages`: the most recent 50,000 tokens of whole turns (the session history window) |
+| `use_context` given to the target | `false` | `true` |
 | `_meta.occurrence.session_kind` | `occurrence` | `automation` |
 
+The context mode alone decides whether the target reads history: at admission the runtime sets the target's
+`use_context` input (and `include_context` when the target has it) to `true` for growing and `false` for
+independent, whatever the definition's `target.input_data` says. A discussion always gets `use_context: true`.
+The run records the decision as `_runtime.automation_context = {mode, use_context, target_use_context}`, where
+`target_use_context` is the value the definition carried. Automations created before this rule, with
+`use_context: false` in their target, now replay their history without being revised.
+
 Growing history is read at admission and frozen with the occurrence's inputs, so every retry sees the same history.
 It is read strictly: when it cannot be read (a store without a run index, for example), the admission fails instead
 of running the occurrence without its context. History keeps whole turns, newest first, and says so in the oldest
-kept message when older turns were dropped.
+kept message when older turns were dropped. The occurrence run records what was replayed in
+`vars._runtime.session_history` (`replayed_messages`, `replayed_tokens`, `dropped_messages`, `dropped_tokens`,
+`max_tokens`, ...), and the `automation.admitted` record carries the same values in its frozen inputs.
 
 Only completed turns with both a prompt and an answer are replayed. A retried occurrence counts once, as its last
 attempt.
@@ -3781,8 +3797,8 @@ actor_id=None)` starts a separate conversation about the automation as it stood
 - It is seeded **once** with the automation's whole conversation through occurrence N, whatever the context mode:
   one user/assistant pair per finished occurrence 1..N (its last attempt), the occurrence's trigger/task turn and its
   answer, oldest first (`automation_timeline_messages(...)`). A failed or stopped occurrence stays in the timeline,
-  its answer saying so. The pairs fit the history budget (40 messages, 24 000 characters, 8 000 per message); the
-  oldest are dropped first. The first user message starts with a summary line: `[Automation "<title>": <n>
+  its answer saying so. The pairs go through the session history window (the most recent 50,000 tokens of whole
+  turns, no message ever cut); the oldest are dropped first. The first user message starts with a summary line: `[Automation "<title>": <n>
   occurrence(s) through occurrence N, showing the last K. The automation's files are mounted READ-ONLY at <path>;
   your own workspace <path> is writable.]`. The seed is stored in `_meta.discussion.seed_messages` of the root run.
 - It works in its **own writable workspace**, `workspace_root`, which the host allocates (it must differ from the
@@ -3812,7 +3828,7 @@ the same root, and that root must be a parent-less run of this session that carr
 discussion provenance too.
 
 In a discussion session, `session_chat_messages` replays the seed first, as the oldest history, and drops it first
-under the budget.
+under the history window.
 
 ### Read-only mounts
 
@@ -4010,7 +4026,8 @@ its newest attempt. `automation_id` keeps only that automation's occurrences (ot
 index to look it up in.
 
 `session_chat_messages(..., automation_id=None, through_occurrence=None, strict=False)` replays those turns as
-user/assistant message pairs under a message and character budget. With `strict=True` it raises
+user/assistant message pairs under the session history window (the most recent `HISTORY_REPLAY_MAX_TOKENS` = 50,000
+tokens of whole turns; see [API](api.md#sessions-and-history)). With `strict=True` it raises
 `SessionHistoryError` (`reason_code = "history_unavailable"`) instead of returning a partial history: a store without
 a run index, a missing occurrence, or a discussion whose seed is missing or cannot be read. Automation admission and
 discussion seeding always read strictly.
@@ -4069,7 +4086,8 @@ receives its result directly.
   controller does not wait on `event` sources.
 - Occurrences run one at a time (`serial`), missed ticks coalesce, and a failed occurrence never stops the
   automation (`failure: "continue"`). These policies cannot be changed.
-- Growing history is bounded (40 messages, 24,000 characters, whole turns) and is not summarized automatically.
+- Growing history is the most recent 50,000 tokens of whole turns and is not summarized automatically; older turns
+  drop out of the replay (they stay in the store).
 - Tools outside `TOOL_EFFECT_CLASSES`, such as third-party MCP tools, still ask for approval under `auto`.
 - Retries repeat external effects.
 - One writer process per store; the mutation lock does not coordinate separate processes.
@@ -5328,6 +5346,7 @@ In this repo, the AbstractCore wiring lives under `src/abstractruntime/integrati
 - `tools-comms.md` — enabling the optional comms toolset (email/WhatsApp/Telegram)
 - `tool-approval.md` — tool risk tiers, the run-policy rank ceiling, and per-call refiners (the `send_email` self-recipient rule)
 - `api.md#workflowbundles-flow-and-visualflow-distribution` — VisualFlow compiler APIs, media nodes, and document nodes (`read_pdf` / `write_pdf` / `write_docx`)
+- `api.md#sessions-and-history` — session history replay: one window, the most recent 50,000 tokens of whole turns (`HISTORY_REPLAY_MAX_TOKENS`), returned as a `ReplayedHistory` whose `.report` records what was replayed and dropped
 - `api.md#run-history-bundle-export-portable-replay-artifact` — run history bundles, including `resolved_actions` summaries for cross-client capability replay
 
 ## Features (reference)