proposal: the provider choice lives in /model, is called "provider", and is discoverable from the model row #1023

Why

After #1019 simple is the default: aforge names no provider unless a person pins one, and the pin is now the ONE routing decision a person can make. The owner asked whether "lane" is obvious and whether the choice belongs in /model. Assessment, then a proposal.

What is true today

• The same choice is reachable from three places: Settings → Providers → lane row (opens the picker), /model → → on a model (the fold), and it is shown on the status chip as model@morph · via <served>.
• The word a person meets is lane (settings row, the manual's page title, the fold's hints), while the wire, OpenRouter's own error text (provider.only), and the owner all say provider.
• The fold is only discoverable if you already know → does something on a model row (Picker: → walks into a model's lanes, a fold always opens, and the pin is written on the model's name #785 made → walk in, but the row does not say so).
• Under simple the fold's numbers (1.0s · 31 t/s · $15/M · 100%) are OpenRouter's published endpoint figures; aforge does not choose by them any more, and nothing on the fold says whose figures they are.
• Clearing a pin is a long walk to auto, and the filter cannot reach a provider name (lane pin from the settings sheet: three turns served by another machine while the chip read @morph (seen once, dev 649392ad7) #1022 fixes both).

Proposal

1. Call it provider everywhere a person reads. Settings row label lane → provider; the manual page keeps its file name but its # title and the ## headings people search by say provider ("which provider answers", "pin a provider"); fold hints and sentences use provider. Internal identifiers (lane.talk, internal/lane, LanePin) stay — this is vocabulary, not architecture. The config key lane.talk keeps reading and writing as today.
2. /model is the home of the choice; Settings only points at it. Keep → on a model opening its providers, enter pinning, enter on the pinned one clearing (lane pin from the settings sheet: three turns served by another machine while the chip read @morph (seen once, dev 649392ad7) #1022). The Settings → Providers row shows only the value (auto or Morph) and a one-line explanation — "which provider answers this model; auto is OpenRouter's own routing" — and enter opens the same fold. No second list, no separate page, no /provider command.
3. The model row says the door is there. On the current model's row in /model, a dim trailing → providers (or → 11 providers) when the fold is closed, drawn through the tokens door. A key that only acts after you have learned what it is for is invisible (the discoverability-before-purity ruling).
4. The fold says whose figures it shows. Its foot hint gains the source in the house's dim telemetry — figures: openrouter · enter pin · ← back · esc — so under simple nobody reads them as aforge's own choosing. Under latency/price the auto row already says aforge chooses.
5. One teach at the moment it matters. The first time a pinned provider is refused, the retirement sentence already tells the person; add nothing. The first time a person opens /model and the fold has never been opened, nothing either — item 3 is the teach.

Not proposed

A per-model pin (the row is per slot on purpose, laneSlotFor), a provider page of its own, sorting the fold by anything but its current order, or renaming any config key.

Acceptance

End to end first: a fresh profile, /model, the current model's row shows the provider affordance; →, enter on a provider, the chip reads @<provider> and the request body carries {"only":[...],"allow_fallbacks":false}; Settings → Providers shows provider Morph. Then the manual probe gate answers "how do I pick the provider" and "what is a lane" to the same page, and internal/e2e/tuiwords_test.go needles follow the respelled sentences.

Related: #1019 (simple routing default), #1022 (pin chip, live routing, fold gestures), #785 (→ walks into lanes).

🤖 Generated with Claude Code

https://claude.ai/code/session_0182eyxXP8Xe7ADNKpYDe4wv

Drafted with CodeAF · reviewed and owned by the author