puter/paseo
1
0
Fork 0
mirror of https://github.com/getpaseo/paseo.git synced 2026-11-02 22:52:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(client): a legacy create routes its options from the controls of its own config

Browse Source 
Which options a legacy daemon exposes as features depends on the model, mode
and thinking level, not only the provider: a Haiku snapshot with no features
says nothing about Opus. The provider-keyed memory of control keys sent an
Opus create's fast_mode as providerOptions, which that daemon does not read.

A create that carries options now lists the controls for its own draft
config and splits on that answer. The memory, and the snapshot and listing
hooks that fed it, are gone.
This commit is contained in:
Mohamed Boudra
2026-11-01 23:10:18 +01:00
parent ea8c9e7dc4
commit e4876ed09d
4 changed files with 131 additions and 99 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/providers.md
+3 -2
View File
@@ -82,8 +82,9 @@ or without a control.
profile saves its stored options plus the form's edits, so options no control draws survive an
edit. A daemon without `server_info.features.providerOptionControls` sends `features` and
`featureValues`; `packages/client/src/compat/legacy-provider-options.ts` is the one place that
turns those into `controls` and `options` and back, so nothing in the app branches on it. Its
first create for a provider lists that provider's features to learn which options go out as
turns those into `controls` and `options` and back, so nothing in the app branches on it. A
create that carries options first lists the controls for its own provider, model, mode and
thinking level, since which options are controls differs by model, and sends those as
`featureValues`; callers do not prime anything.
- **Provider-initiated changes.** A setting the provider changes on its own is an
`options_changed` event. The daemon stores and forwards it and does not push the old value back.