LocalModelRoleResolver

Satisfies a chat role with a model a local runner is serving RIGHT NOW.

The local counterpart of the credential path, seam for seam: configuration names the model per provider, the resolver is asked per call, and what it returns is a service built on the spot. The difference is only where the endpoint comes from - a key for the credential path, a runner on this machine for this one - and the asymmetry the platform had was that only one of them was asked again after startup.

Reads the same configuration ConfigurableRoleResolver does, through that class's own read side, so the two cannot drift on what a role means:

embabel:
  models:
    roles:
      cheapest:
        docker: { model: ai/qwen3, temperature: 0.0 }

NAME THE MODEL UNDER THE PROVIDER COLUMN, not in the flat embabel.models.llms map, if it may arrive after boot. The flat map is validated at startup and a name nothing has registered is fatal there - correctly, since in a keyed deployment it is a typo. The nested map is not checked, for the reason that makes it right here too: its entries name models this process may have no way to serve yet.

Declines rather than competing, in three cases. A role configuration says nothing about this provider; a model the runner is not serving, so an absent runner simply answers nothing; and any call with a user credential for some OTHER provider, because a user who brought a key asked for their provider and serving them a model off this machine would answer with the wrong one.