feat: auto-refresh model list when stale

[pi-claw-agent]

Summary

Added pi-on-code.modelListRefreshMinutes (number, default 30, minimum 0 = disabled). Opening the model list now checks staleness through a pure helper and refreshes the provider registry (modelRegistry.refresh) before building the picker items when the cached list is older than the window; concurrent opens share a single in-flight refresh and a failure is logged without breaking the picker.

Validation

• bun install --frozen-lockfile
• bun run check-types
• bun run lint
• bun run compile-tests
• bun esbuild.js
• bun esbuild.webview.js
• xvfb-run -a bun x vscode-test (239 passing)
• git diff --check

Closes #90

[pi-claw-agent]

Independent Agent review: changes requested

Review round 1/2 for 91866a5f9eb4.

The staleness helper, setting (default 30, minimum 0 = disabled), in-flight sharing, and failure tolerance are sound, but the auto refresh only runs for one of the model-list surfaces. The native VS Code model picker paths still present an unrefreshed registry list, so the issue requirement (refresh when the model list is opened after N minutes) is only partially met.

Findings

• blocking: Stale-list refresh applies only to the custom status-bar picker, not the other model lists — src/pi-service.ts:2817
  • Evidence: ensureModelListFresh() is awaited only inside buildStatusPickerOptions (the new webview picker). Other user-reachable model lists still call getAvailableModels() without the staleness check: piService.pickModel() itself (src/pi-service.ts:2649) is invoked by the pi-on-code.pickModel command (src/extension.ts:1562-1572), the pi-on-code.pickSessionModel command (src/extension.ts:1535-1541), and the webview pickModel message (/model slash and legacy path, src/webview-panel.ts:618 -> triggerModelPicker -> pickModel()). Opening any of those after the refresh window shows the cached list, so the requirement "打开模型列表时如果检测到距离上一次刷新过去了N分钟应该自动刷新" is not satisfied for them. Additionally, the cycle list (cycleModels, built at initialize) is never refreshed.
  • Recommended fix: Route every model-list surface through the same guard — call await this.ensureModelListFresh() at the start of pickModel() (which covers pickModel, pickSessionModel, and the webview pickModel message) in addition to buildStatusPickerOptions, and rebuild cycleModels after a successful refresh so cycling also sees the fresh registry.
• minor: Staleness clock is per session, so each new session refreshes the registry again — src/pi-service.ts:411
  • Evidence: modelListRefreshedAt is an instance field of PiService and each session window owns its own PiService, while the registry/modelRuntime they refresh is effectively shared runtime data. Because a null timestamp is always considered stale, the first model-list open in every newly created session triggers another modelRegistry.refresh() even when a sibling session refreshed moments earlier.
  • Recommended fix: Track the last successful refresh process-wide (module-level timestamp or a shared holder) so the N-minute window is honored across sessions, while keeping the per-instance in-flight promise de-duplication.

Reviewer checks

• Inspected git diff main...91866a5 and traced every model-list entry point (buildStatusPickerOptions, pickModel, pickSessionModel, webview pickModel, cycleModel) plus the setting read and refresh lifecycle.
• bun run compile-tests
• ./node_modules/.bin/mocha --ui tdd out/test/model-refresh.test.js (4 passing)
• ./node_modules/.bin/eslint src/test/model-refresh.test.ts src/model-refresh.ts
• bun run check-types
• git diff --check main...91866a5

Generated by the independent sandboxed Reviewer Agent. The PR still requires human review and merge.

[pi-claw-agent]

Agent review repair 1

Addressed both findings. (1) The staleness guard now covers every model-list entry point: pickModel() awaits ensureModelListFresh() (which also covers pickSessionModel, the /model slash command, and the legacy webview pickModel message) in addition to buildStatusPickerOptions(), and a successful refresh rebuilds cycleModels from the fresh registry so model cycling sees current data. (2) The refresh timestamp is now process-wide (shared module state with get/mark/reset helpers) instead of per-PiService, so sibling sessions honor the same N-minute window while the per-instance in-flight promise still de-duplicates concurrent opens. Tests cover the shared clock and the expanded wiring.

Independent Agent review will run on the updated commit. The PR still requires human review and merge.

[pi-claw-agent]

Independent Agent review: approved

Review round 2/2 for 17d087ca2aaa.

Both round-1 findings are resolved. The staleness guard now runs on every model-list surface: pickModel() awaits ensureModelListFresh() (covering the Pi: Switch Model / pickSessionModel commands and the webview pickModel / /model path) alongside buildStatusPickerOptions(), and a successful refresh rebuilds cycleModels from the fresh registry so cycling sees current data. The refresh timestamp moved to a shared module-level clock (get/mark/reset helpers) while the per-instance in-flight promise still de-duplicates concurrent opens, so sibling sessions honor one N-minute window. Pure staleness/max-age rules and the shared clock are unit tested, wiring assertions cover both guards and the cycle rebuild, and all validation passes.

Reviewer checks

• Inspected git diff main...17d087c and the round-2 delta, tracing both ensureModelListFresh guard call sites, the shared clock helpers, cycleModels rebuild, and every model-list entry point.
• bun run compile-tests
• ./node_modules/.bin/mocha --ui tdd out/test/model-refresh.test.js (6 passing)
• ./node_modules/.bin/eslint src/test/model-refresh.test.ts src/model-refresh.ts
• bun run check-types
• bun esbuild.js
• git diff --check main...17d087c

Generated by the independent sandboxed Reviewer Agent. The PR still requires human review and merge.