Context

PR #74 added VLLMClient.get_served_model_name() and wired it into _setup_external in proxy/proxy.py. To apply the discovered name, the setup code mutates both attributes directly:

client.model_path = served
client.model = served

This works correctly today because served is always a bare string (vLLM's --served-model-name alias), which is the else branch of the constructor's derivation logic — so the post-construction assignment produces the same result the constructor would have.

The fragility

VLLMClient.__init__ derives self.model from self.model_path via a 3-branch conditional (filesystem path → path.name, HF-style "/" in string → trailing segment, otherwise → full string). If someone later adds a 4th branch (e.g., handling a new identity form), the post-construction mutation in _setup_external won't pick up the new behavior — model and model_path would silently diverge from what a fresh constructor would produce.

Proposed fix

Extract the derivation into a classmethod or staticmethod helper, e.g.:

@staticmethod
def _derive_model_field(model_path: str) -> str:
 path_obj = Path(model_path)
 if path_obj.is_absolute() or path_obj.exists():
 return path_obj.name
 if "/" in model_path:
 return model_path.split("/")[-1]
 return model_path

Then __init__ calls self.model = self._derive_model_field(self.model_path), and _setup_external does:

client.model_path = served
client.model = VLLMClient._derive_model_field(served)

Both call sites stay in sync with future derivation changes.

Priority

Low. Current behavior is correct for all known served-name shapes. This is a hardening pass to prevent future drift, not a bug fix.