diff options
| -rw-r--r-- | PLAN-OPENROUTER.md | 85 | ||||
| -rw-r--r-- | PLAN.md | 25 | ||||
| -rw-r--r-- | PLAN2.md | 28 | ||||
| -rw-r--r-- | PLAN3.md | 24 |
4 files changed, 0 insertions, 162 deletions
diff --git a/PLAN-OPENROUTER.md b/PLAN-OPENROUTER.md deleted file mode 100644 index 5534b29..0000000 --- a/PLAN-OPENROUTER.md +++ /dev/null @@ -1,85 +0,0 @@ -# Plan to Implement OpenRouter.ai Support - -This document outlines the steps to integrate OpenRouter.ai as a new LLM provider within Hexai. The implementation will follow the existing provider pattern, using `internal/llm/openai.go` as a template due to API similarities. - -## 1. Update Configuration (`internal/appconfig/config.go`) - -Status: Completed - configuration structs, env overrides, and sample config updated. - -The application needs to be aware of the new provider and its specific configuration settings. - -- **Add OpenRouter section to `fileConfig`:** - - Create a new `sectionOpenRouter` struct in `internal/appconfig/config.go` to handle settings from `config.toml`. - - It will contain `Model`, `BaseURL`, and `Temperature` fields. - - Add `OpenRouter sectionOpenRouter` to the `fileConfig` struct. - -- **Add fields to `App` struct:** - - Add `OpenRouterBaseURL`, `OpenRouterModel`, and `OpenRouterTemperature` to the main `App` struct. - -- **Update `loadFromEnv`:** - - Modify the `loadFromEnv` function in `internal/appconfig/config.go` to read `HEXAI_OPENROUTER_MODEL`, `HEXAI_OPENROUTER_BASE_URL`, and `HEXAI_OPENROUTER_TEMPERATURE` from environment variables. - -- **Update `toApp()` and `mergeProviderFields`:** - - Add logic to `fileConfig.toApp()` to convert the `sectionOpenRouter` into the `App` struct. - - Add logic to `App.mergeProviderFields()` to merge the OpenRouter configuration from different sources. - -- **Update `config.toml.example`:** - - Add a new `[openrouter]` section to the `config.toml.example` file to demonstrate configuration for users. - -## 2. Create OpenRouter Provider (`internal/llm/openrouter.go`) - -Status: Completed - provider implemented with required headers and logging. - -This will be the core implementation of the OpenRouter client. - -- **Create new file `internal/llm/openrouter.go`:** - - This file will be a copy of `internal/llm/openai.go` initially, and then modified for OpenRouter. - -- **Define `openRouterProvider` struct:** - - It will implement the `llm.Client` and `llm.Streamer` interfaces. - - It will hold the `httpClient`, `apiKey`, `baseURL`, `defaultModel`, etc. - -- **Implement `Chat` and `ChatStream` methods:** - - The request logic will be adapted from the OpenAI implementation. - - The base URL will default to `https://openrouter.ai/api/v1` if not provided in the config. - - **Add the required OpenRouter headers to every request:** - - `Authorization: Bearer $OPENROUTER_API_KEY` - - `HTTP-Referer: "https://github.com/snonux/hexai"` (or another suitable value) - - `X-Title: "Hexai"` - -- **Model Handling:** - - The `model` from the `Options` will be passed directly in the JSON request body, allowing users to leverage any model available on OpenRouter. - - Default model now uses `openrouter/auto` so requests succeed without additional configuration. - -## 3. Integrate into Provider Factory (`internal/llm/provider.go`) - -Status: Completed - provider factory wiring and API key plumbing added. - -The application needs to be able to select and instantiate the new provider. - -- **Update `Config` struct:** - - Add `OpenRouterBaseURL`, `OpenRouterModel`, and `OpenRouterTemperature` fields to the `llm.Config` struct. - -- **Update `NewFromConfig` function:** - - Add a new `case "openrouter":` to the `switch` statement. - - This case will be responsible for: - 1. Accepting an `openRouterAPIKey` string, which will be read from the `OPENROUTER_API_KEY` environment variable by the caller. - 2. Returning an error if the key is missing. - 3. Instantiating the new `openRouterProvider` with the correct configuration (API key, model, base URL, temperature). - -## 4. Add Tests (`internal/llm/openrouter_test.go`) - -Status: Completed - streaming and header unit tests added. - -- **Create `internal/llm/openrouter_test.go`:** - - Add unit tests for the `openRouterProvider`. - - Use an HTTP mock (similar to `openai_http_test.go`) to test the `Chat` and `ChatStream` implementations without making real API calls. - - Verify that the correct headers (`Authorization`, `HTTP-Referer`, `X-Title`) are being sent in the mock requests. - - Verify that the request body is correctly formatted. - -## 5. Update Documentation - -Status: Completed - README and configuration docs now mention OpenRouter setup. - -- Update `docs/configuration.md` and `README.md` to include instructions on how to configure and use the OpenRouter.ai provider. -- Explicitly mention the `OPENROUTER_API_KEY` environment variable and the new settings available in `config.toml`. diff --git a/PLAN.md b/PLAN.md deleted file mode 100644 index 5f61c43..0000000 --- a/PLAN.md +++ /dev/null @@ -1,25 +0,0 @@ -# Runtime Model Configuration Plan - -Implement a /reload> endpoint that reloads all the configuration from hexai.toml and updates the running application's state without requiring a restart. - -## Progress -- [x] Phase 1 – Design approach for making settings dynamically changeable -- [x] Phase 2 – Implement dynamic configuration plumbing -- [x] Phase 3 – Expose `/reload>` command and emit change summary (file values override env on reload) - -## Phase 1 Notes (in progress) -- Current config flow: each entry point calls `appconfig.Load(logger)` which merges defaults + `config.toml` + env overrides, then copies fields into long-lived structs (e.g. `lsp.Server`). -- LSP server captures many scalar copies (`maxTokens`, prompts, triggers, stats window), so runtime changes require a reapply step that updates these cached fields plus the `llm.Client` instance and stats window. -- Proposed shape: introduce a central runtime config manager wrapping `appconfig.App` with an `RWMutex`, diff helpers, and subscription callbacks. All components pull the latest snapshot or subscribe to updates instead of keeping independent copies. -- Reload path should reuse shared loader logic that can optionally skip env overrides so `/reload>` can make file values authoritative. -- Applying updates must be atomic per component (e.g. server lock + swap) and should emit a structured list of changed settings for user feedback. -- Manager responsibilities: (1) hold current snapshot, (2) surface `Subscribe(func(old, new appconfig.App))` for live update hooks, (3) expose `Reload(ctx)` that re-parses `config.toml`, produces diff keys, updates snapshot, and returns the changes for logging/UX. -- LSP integration: pass manager into `RunWithFactory`, add `Server.applyAppConfig(cfg appconfig.App)` guarded by lock, rebuild `llm.Client` when provider/model change, refresh prompts/triggers/debounce/temps, and re-run `initializeModelConfig`/stats window. -- Logging/stats: ensure updates propagate (e.g., call `stats.SetWindow` within manager or server update when `StatsWindowMinutes` changes) so runtime metrics align with new config. -- `/reload>` command: hook into existing chat command detection (extend `chatCommandResponse`) to invoke manager `Reload`, then write the diff summary back to the buffer as a synthetic assistant response. - -## Phase 2 Notes (progress) -- Added `appconfig.LoadWithOptions` to support skipping env overrides and introduced a `runtimeconfig.Store` (subscribe + diff) as the runtime configuration backbone. -- `hexailsp.RunWithFactory` now builds a shared store, subscribes the LSP server to config updates, and rebuilds the LLM client + stats/log settings when config changes. -- Implemented CLI-style slash commands in the LSP (`/reload>` currently) so runtime reloads can be triggered without restarting; reload skips env overrides and reports diffed keys. -- Remaining work: surface change summaries inside the server logs, ensure other entry points (CLI/action) share the same store, and add verification around env override precedence. diff --git a/PLAN2.md b/PLAN2.md deleted file mode 100644 index ff518e9..0000000 --- a/PLAN2.md +++ /dev/null @@ -1,28 +0,0 @@ -# Per-Surface LLM Model Configuration Plan - -Goal: allow users to configure distinct LLM models for (1) code completion, (2) code actions, (3) in-editor chat, and (4) the `hexai` CLI while keeping defaults sensible and maintaining backward compatibility. The new options must remain hot-reloadable via the existing runtime config store. - -## Phase 1 – Configuration Design -- [x] Audit current config structures (`internal/appconfig`) and identify the model/temperature fields each surface consumes. -- [x] Propose TOML schema extensions (e.g., `[models] completion = "..."`) plus environment variable overrides. -- [x] Define precedence rules and fallback behavior when only a global model is provided. -- [x] Sketch migration approach (default legacy fields map to all surfaces). - -## Phase 2 – Loader & Runtime Store Updates -- [x] Extend `appconfig` to parse per-surface model settings (and optional temperature overrides) with validation. -- [x] Update `runtimeconfig.Store` diff/flatten logic to include the new fields and guarantee reload propagation works without restart. -- [x] Ensure reload summaries list per-surface changes cleanly. -- [x] Add unit tests covering config parsing, env overrides, and diff output, plus runtime reload coverage. - -## Phase 3 – Surface Wiring -- [x] Completion: adjust LSP completion code to pick the configured completion model, falling back to provider defaults. -- [x] Code actions: ensure code-action prompts and CLI action runner request the configured model. -- [x] In-editor chat: pass chat-specific model to chat requests and CLI chat command handling. -- [x] Hexai CLI: respect the CLI model when building `llm.Config` or request options. -- [x] Provide logging to confirm which model each surface uses for easier debugging. - -## Phase 4 – Validation & Docs -- [x] Add integration/unit tests covering each surface model selection path. -- [x] Verify runtime reload switches models without restart (including diff output). -- [x] Update docs (`docs/configuration.md`, examples) with new keys and environment variables. -- [x] Announce in scratchpad or release notes placeholder for future update. diff --git a/PLAN3.md b/PLAN3.md deleted file mode 100644 index 9a00111..0000000 --- a/PLAN3.md +++ /dev/null @@ -1,24 +0,0 @@ -# Parallel Provider/Model Comparison Plan - -Goal: allow configuring multiple provider:model pairs per surface so users can run a local and cloud LLM side-by-side for manual comparison. Completions should fan out and show one suggestion per configured entry; Hexai CLI should emit one response per entry; code actions remain single-provider. - -## Phase 1 – Configuration & Schema -- [x] Audit existing per-surface config to support arrays of provider:model entries (preserving current single-entry behavior by default). -- [x] Design updated TOML and env schema (e.g., `[[models.completion]] provider="openai" model="gpt-4o"`). -- [x] Define merge, validation, and backward-compatibility rules (single entry auto-wraps into list). - -## Phase 2 – Runtime Plumbing -- [x] Extend appconfig/runtime store to emit ordered slices for multi-entry surfaces, including diff output. -- [x] Update request-spec helpers to iterate across configured entries, building dedicated request specs (and caching clients per provider/model combo). -- [x] Ensure logging/stats capture provider/model context per entry. - -## Phase 3 – Surface Implementations -- [x] Completion: fan out requests concurrently, gather one suggestion per entry, and surface them distinctly to the editor (labelled with provider/model). -- [x] CLI: run all configured providers in parallel and print separate responses per entry with stats. -- [x] Code actions: keep single-provider flow and warn/ignore additional `[[models.code_action]]` entries. -- [x] Add concurrency safeguards (debounce/throttle gate still respected before fan-out). - -## Phase 4 – UX & Validation -- [x] Tests covering multi-entry parsing, diffing, and surface behavior (expanded CLI/LSP/appconfig suites). -- [x] Update docs and example TOML with array syntax and dual-provider guidance. -- [x] Capture lessons/issues in scratchpad for follow-up polishing. |