Skip to content

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

Description

@santoshkumarradha

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

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:chatThe v3 surface a person sits in front of (internal/tui3)featureWork that adds a capability; developers break it into tasks

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions