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


Drafted with CodeAF · reviewed and owned by the author

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