Plan v0.3.2 fast mode

ROADMAP.md

@@ -1,6 +1,47 @@
 # Cassady (Cass) Roadmap
 
-## v0.3.0 — ChatGPT Codex Provider
+## v0.3.2 — Provider Fast Mode
+
+This release focuses on adding a `/fast` command that lets users prefer faster inference when the active provider/model supports it. The first supported provider is `ChatGPT Codex`; other providers can add their own fast-mode request behavior later without changing the user-facing command. See `plans/V0_3_2_FAST_MODE_PLAN.md`.
+
+### Fast Mode Command
+
+- [ ] **Add a persisted `/fast` preference.** Let users toggle fast mode from an idle chat and keep that preference across sessions.
+  - Store the preference in `config.json` without disturbing provider/model configuration.
+  - Keep the preference separate from whether the current provider/model can honor it.
+
+- [ ] **Show capability-aware fast-mode status.** Display fast mode as enabled only when the active provider/model supports it.
+  - If the user switches to an unsupported provider/model, hide the enabled state and report fast mode as unavailable when relevant.
+  - If the user switches back to a supported provider/model, apply the existing preference again.
+
+### Provider Support
+
+- [ ] **Implement ChatGPT Codex fast-mode requests.** Add the provider-specific request option for Codex when fast mode is active.
+  - Verify and test the exact Codex responses request shape during implementation.
+  - Do not send Codex-specific fast-mode fields to OpenAI-compatible providers.
+
+- [ ] **Add extensible provider/model capability metadata.** Model fast-mode support as provider/model metadata so future providers can opt in case by case.
+  - Default unknown and custom providers to unsupported.
+  - Mark built-in ChatGPT Codex model metadata as supported when Cassady can send the fast-mode request.
+
+### Documentation and Validation
+
+- [ ] **Document fast mode behavior and limits.** Update README and bundled docs for `/fast`, `default_fast_mode`, model capability metadata, and Codex-only initial support.
+  - Explain the difference between a saved fast-mode preference and active fast-mode support.
+
+- [ ] **Test fast-mode preference, switching, and provider requests.** Cover command parsing, persistence, status rendering, model/provider switching, and Codex request body behavior.
+  - Verify `cargo fmt` and `cargo test --locked --all-targets` pass before handoff.
+
+## v0.3.1 — Transcript Scroll Stability
+
+This release focuses on keeping the live transcript anchored correctly above the input and footer during long sessions with blank reasoning or tool-output lines.
+
+### TUI Reliability
+
+- [x] **Fix bottom-scroll row counting for whitespace-only lines.** Count indented blank transcript rows the same way Ratatui renders them so accumulated blank rows no longer hide recent transcript content above the footer.
+  - Add regression coverage for whitespace-only wrapped row counting.
+
+## v0.3.0 — ChatGPT Codex Provider ✅ Completed
 
 This release focuses on letting users who are already signed in to Codex with a ChatGPT subscription use that account from Cassady. `ChatGPT Codex` becomes a provider preset that calls the Codex responses endpoint and reads its bearer token from local Codex auth instead of an API-key environment variable. See `plans/V0_3_0_CHATGPT_CODEX_PROVIDER_PLAN.md`.
 
@@ -34,7 +75,7 @@ This release focuses on letting users who are already signed in to Codex with a
 - [x] **Test Codex auth and provider behavior.** Cover Codex auth fixtures, config validation, setup catalog behavior, provider dispatch, streaming response parsing, tool calls, and secret redaction.
   - Verify `cargo fmt` and `cargo test --locked --all-targets` pass before handoff.
 
-## v0.2.9 — Provider Login Management
+## v0.2.9 — Provider Login Management ✅ Completed
 
 This release focuses on making provider configuration available from both the shell and an active Cassady chat. Users can add or update OpenAI-compatible provider/model settings with `cass login` or `/login`, and remove saved providers and their associated models with `cass logout` or `/logout`. See `plans/V0_2_9_PROVIDER_LOGIN_MANAGEMENT_PLAN.md`.
 
@@ -66,7 +107,7 @@ This release focuses on making provider configuration available from both the sh
 - [x] **Test provider management behavior.** Cover provider/model removal, active default repair, local command parsing, and autocomplete.
   - Verify `cargo fmt` and `cargo test --locked --all-targets` pass before handoff.
 
-## v0.2.8 — Conversation Branch and Restore
+## v0.2.8 — Conversation Branch and Restore ✅ Completed
 
 This release focuses on making conversation recovery safe and explorable. Pressing `Esc` twice while idle opens a branch/restore menu where users can browse prior user messages, assistant messages, and tool calls, create a new branch from a selected checkpoint, and optionally restore Cassady-tracked file edits without destroying the original conversation. See `plans/V0_2_8_CONVERSATION_BRANCH_RESTORE_PLAN.md`.
 
@@ -410,6 +451,13 @@ This release focuses on making Cass easier to interrupt, easier to audit, and sa
 
 These sections describe work Cassady intends to complete before or as part of the next major release, but which has not yet been assigned to a specific version. Scope, order, and version numbers may change.
 
+### Tool Output Context Reliability
+
+- [ ] **Reduce tool-output compaction stalls.** Make large file reads and command output easier to recover from when output is compacted or truncated, so the assistant can quickly switch to targeted inspection instead of getting stuck.
+  - Prefer smaller, focused file ranges and search-first workflows when large outputs are likely.
+  - Surface clearer guidance when tool results are compacted, including suggested narrower follow-up reads.
+  - Add regression coverage or dogfood checks for workflows where broad reads previously obscured the context needed for safe edits.
+
 ### Windows CLI Usability
 
 This work focuses on making Cassady feel reliable and native when the CLI is run on Windows. It covers runtime usability after `cass` or `cassady` is already available on the machine; installers, package managers, PATH setup, code signing, and update delivery are intentionally out of scope.

plans/V0_3_2_FAST_MODE_PLAN.md

@@ -0,0 +1,285 @@
+# v0.3.2 Fast Mode Implementation Plan
+
+## Goal
+
+v0.3.2 adds a `/fast` command that lets users opt into faster provider inference when the active provider/model supports it. The setting should feel like a user preference, but the runtime state should be capability-aware: fast mode is shown as enabled only when the current provider/model can actually honor it.
+
+Success statement:
+
+> A ChatGPT Codex user can type `/fast`, see fast mode enabled for Codex models that support it, switch to an unsupported provider/model and see fast mode become unavailable, then switch back and have the preference apply again.
+
+## Scope
+
+### In scope
+
+- Add an idle-only `/fast` local command that toggles the user's fast-mode preference.
+- Persist the preference in Cassady config so it survives new chats and restarts.
+- Add provider/model capability metadata that determines whether fast mode is currently active.
+- Implement fast-mode request support for `ChatGPT Codex` first.
+- Keep unsupported providers/models explicit: the preference can remain on, but the UI/status should say fast mode is unavailable rather than enabled.
+- Update `/status`, the bottom/status line, command autocomplete/help, README, and bundled docs.
+- Add focused tests for command parsing, persistence, capability gating, provider request shaping, and model switching.
+
+### Out of scope
+
+- Adding fast-mode support for OpenAI-compatible providers in v0.3.2.
+- Guessing provider-specific fast-mode request fields without verified behavior.
+- Adding latency benchmarking, automatic mode selection, or per-turn speed/quality controls beyond the `/fast` toggle.
+- Changing the default model selection flow except to record fast-mode capability for known built-in presets.
+- Treating fast mode as a quality guarantee; providers may still vary in latency and output behavior.
+
+## Context or Current State
+
+Cassady already has several runtime preferences and model/provider capability paths that should guide this work:
+
+- `src/app.rs` parses local slash commands such as `/model`, `/login`, `/logout`, and `/status`, and already restricts provider/model changes to idle state.
+- `src/config.rs` persists default model and reasoning effort in `config.json` and stores model metadata in `models.json`.
+- `ModelDefinition` already includes capability-like metadata such as `supports_tools`, `supports_streaming`, and `reasoning`.
+- `ProviderClient::from_config` in `src/providers/mod.rs` dispatches by provider kind to `OpenAiCompatibleProvider` or `ChatGptCodexProvider`.
+- `src/providers/chatgpt_codex.rs` is the first provider where fast mode should affect the outgoing request.
+- `/model` already reloads model metadata and resets reasoning effort based on the new model.
+- `/status` currently reports chat id, model, mode, cwd, records, and current status.
+
+The important product behavior is that "fast mode preference" and "fast mode active" are different states:
+
+- Preference: whether the user wants fast mode when possible.
+- Active: whether the current provider/model supports fast mode and the preference is enabled.
+
+## Design Principles
+
+1. **Preference stays stable, capability controls activation.** Switching to an unsupported provider/model should not erase the user's preference; it should only make fast mode inactive until support is available again.
+2. **Provider-specific request details stay behind provider clients.** The agent loop should pass a normalized fast-mode flag; each provider decides whether and how to encode it.
+3. **UI wording must distinguish enabled from unavailable.** Avoid showing "fast mode enabled" when Cassady cannot send a fast-mode request for the active provider/model.
+4. **Extend metadata, do not hardcode every check in the TUI.** Use provider/model capability helpers so future providers can add fast mode without rewriting command handling.
+5. **Keep unsupported behavior quiet and compatible.** Existing OpenAI-compatible providers should continue working unchanged and should not receive unknown request fields.
+
+## Design
+
+### User model
+
+Add a user preference to `config.json`:
+
+```json
+{
+  "default_fast_mode": true
+}
+```
+
+Suggested behavior:
+
+- Missing `default_fast_mode` defaults to `false`.
+- `/fast` toggles the preference while idle.
+- `/fast on` and `/fast off` may be supported if easy, but the minimum required command is the toggle form.
+- The preference is persisted immediately, similar to last-used model/reasoning persistence.
+- The active state is recomputed whenever config, provider, model, or model metadata changes.
+
+Status examples:
+
+```text
+fast mode: enabled
+fast mode: unavailable for provider fireworks
+fast mode: off
+```
+
+If the user toggles fast mode on while using an unsupported provider:
+
+```text
+fast mode preference on; unavailable for this provider/model
+```
+
+If the user later switches to a supported Codex model, the UI should show:
+
+```text
+fast mode enabled
+```
+
+### Capability model
+
+Add a small capability representation, preferably on model metadata with provider-kind fallback:
+
+```json
+{
+  "id": "gpt-5.5",
+  "provider": "chatgpt-codex",
+  "fast_mode": {
+    "supported": true
+  }
+}
+```
+
+Rules:
+
+- `fast_mode.supported` defaults to `false` unless a provider-specific built-in preset intentionally marks it true.
+- For the `ChatGPT Codex` built-in setup path, saved Codex model metadata should mark fast mode as supported when the implementation can send the fast-mode request for that provider.
+- Manual custom providers and discovered OpenAI-compatible models should default to unsupported.
+- If a provider supports fast mode for all models but model metadata is missing, provider-specific capability fallback may return supported. Keep that fallback in config/provider capability helpers, not in UI string matching.
+
+Add helper APIs along these lines:
+
+```rust
+pub struct FastModeState {
+    pub preferred: bool,
+    pub supported: bool,
+    pub active: bool,
+    pub unavailable_reason: Option<String>,
+}
+
+impl Config {
+    pub fn fast_mode_state(&self) -> FastModeState;
+}
+```
+
+`active` should be exactly `preferred && supported`.
+
+### Provider request behavior
+
+Thread the active fast-mode boolean through the provider settings:
+
+```rust
+ProviderClient::from_config(&config, reasoning_effort, fast_mode_active)
+```
+
+or include it in a runtime options struct if that is cleaner:
+
+```rust
+pub struct ProviderRuntimeOptions {
+    pub reasoning_effort: ReasoningEffort,
+    pub fast_mode: bool,
+}
+```
+
+`ChatGptCodexProvider` should encode fast mode using the verified Codex responses request shape. During implementation, verify the exact field against the current Codex behavior and capture the resulting request body in tests. The plan intentionally does not prescribe a speculative field name.
+
+OpenAI-compatible providers should ignore the setting until support is explicitly added. They must not receive experimental Codex-only fields.
+
+### UI and command behavior
+
+Add `LocalCommand::Fast(FastModeCommand)` in `src/app.rs`.
+
+Minimum command behavior:
+
+```text
+/fast
+```
+
+Recommended optional forms:
+
+```text
+/fast on
+/fast off
+/fast status
+```
+
+Command handling:
+
+- Only allow changes while idle.
+- Persist the preference to `config.json`.
+- Recompute active state from the current provider/model after toggling.
+- Append or show a concise status message.
+- Include `/fast` in autocomplete/local command help.
+
+Update `/status` to include both preference and active state, for example:
+
+```text
+fast: enabled
+```
+
+or:
+
+```text
+fast: preferred, unavailable for provider fireworks
+```
+
+The bottom/status line should include a compact signal only when useful:
+
+- `fast` when active.
+- No `fast` label when off.
+- Optional `fast unavailable` only immediately after toggling or in `/status`, to avoid clutter.
+
+### Model and provider switching
+
+When `/model` changes the active model:
+
+- Reload `config.model_metadata` as today.
+- Recompute reasoning effort as today.
+- Recompute fast-mode state.
+- Show the model status with fast-mode state when the preference is on.
+
+Expected examples:
+
+```text
+model: gpt-5.5 · fast enabled
+model: accounts/fireworks/models/qwen3p7-plus · fast unavailable
+```
+
+When `/login` or `/logout` updates provider config:
+
+- Reload config as today.
+- Preserve `default_fast_mode`.
+- Recompute fast-mode state for the new active provider/model.
+
+### Configuration and docs
+
+Update docs to describe:
+
+- `default_fast_mode` in `config.json`.
+- `fast_mode.supported` in `models.json`.
+- `/fast` command behavior.
+- Provider support status: v0.3.2 supports fast mode only for `ChatGPT Codex`.
+- The distinction between fast-mode preference and active fast-mode support.
+
+## Implementation Steps
+
+1. Extend config types in `src/config.rs`:
+   - Add `default_fast_mode: Option<bool>` to the config file representation.
+   - Add `fast_mode` metadata to model definitions.
+   - Add a `FastModeState` helper that computes preferred/supported/active.
+2. Add persistence helpers:
+   - Save fast-mode preference without disturbing unrelated config fields.
+   - Ensure existing `save_last_used` behavior preserves the new field.
+3. Mark built-in `ChatGPT Codex` model metadata as fast-mode capable during setup/login when the provider implementation supports it.
+4. Add provider runtime options and pass `fast_mode_state.active` into `ProviderClient` construction from `src/agent.rs`.
+5. Implement Codex request support in `src/providers/chatgpt_codex.rs` using the verified fast-mode request shape.
+6. Keep `OpenAiCompatibleProvider` behavior unchanged and add tests proving it does not receive fast-mode fields.
+7. Add `/fast` parsing and idle command handling in `src/app.rs`, including optional `on`, `off`, and `status` forms if the implementation remains small.
+8. Update `/status`, status-line rendering, autocomplete/help text, and model-switch status messages.
+9. Update `README.md`, `docs/commands.md`, `docs/configuration.md`, `docs/providers.md`, `docs/workflows.md`, and `docs/glossary.md`.
+10. Add focused tests and run `cargo fmt` plus `cargo test --locked --all-targets`.
+
+## Tests
+
+- `config.json` without `default_fast_mode` defaults to fast mode off.
+- `default_fast_mode: true` loads and persists without losing existing config fields.
+- `models.json` parses `fast_mode.supported`.
+- Unsupported or missing fast-mode metadata produces `FastModeState { preferred: true, supported: false, active: false }`.
+- A supported ChatGPT Codex model produces `active: true` when preference is on.
+- `/fast` parses as a local command and rejects unexpected arguments unless explicit `on`/`off`/`status` forms are implemented.
+- `/fast` cannot change preference during an active turn.
+- Toggling `/fast` while on an unsupported provider stores the preference but reports unavailable.
+- Switching from a supported Codex model to an unsupported model hides the active fast-mode signal without clearing the preference.
+- Switching back to a supported Codex model restores active fast mode.
+- `ChatGptCodexProvider` includes the verified fast-mode request field only when active.
+- `OpenAiCompatibleProvider` request bodies are unchanged when fast-mode preference is on but unsupported.
+- `/status` includes fast-mode state.
+- README and bundled docs mention `/fast` and provider-specific support.
+- `cargo fmt` passes.
+- `cargo test --locked --all-targets` passes when practical.
+
+## Documentation
+
+- README command list and provider setup notes.
+- `docs/commands.md` for `/fast` syntax and idle-only behavior.
+- `docs/configuration.md` for `default_fast_mode` and `models.json` fast-mode capability metadata.
+- `docs/providers.md` for the initial ChatGPT Codex-only support.
+- `docs/workflows.md` for switching models/providers with fast-mode preference preserved.
+- `docs/glossary.md` for "Fast mode" as a preference plus provider/model capability.
+
+## Acceptance Criteria
+
+- `/fast` toggles a persisted fast-mode preference.
+- Fast mode is shown as enabled only when the active provider/model supports it.
+- Unsupported providers/models do not show fast mode enabled and do not receive fast-mode request fields.
+- ChatGPT Codex requests include the verified fast-mode option when the preference is on and the active Codex model supports it.
+- Switching models/providers recomputes fast-mode active state without clearing the user's preference.
+- `/status`, autocomplete/help, README, and bundled docs describe the feature accurately.
+- `cargo fmt` and `cargo test --locked --all-targets` pass before implementation handoff.