Summary
gears/model-registry has docs/ and a model-registry-sdk crate (trait ModelRegistryClientV1 with model/provider CRUD in model-registry-sdk/src/api.rs), but:
- No gear implementation crate — there is no running model-registry service that registers
ModelRegistryClientV1 in ClientHub, so a co-located gear cannot resolve it at runtime.
- SDK lacks a per-model capability accessor — it exposes
get_tenant_model / list_tenant_models but no model_capabilities(model_id). Chat Engine's ModelRegistryClient::model_capabilities would have to fetch ModelV1 and map info.capabilities → ModelCapabilitySchema by hand.
Why this blocks usage
Chat Engine's first-party LLM plugin resolves session capabilities on on_session_created via list_models + model_capabilities. With no running gear and no capability accessor, there is no production source for capability resolution on the first-party path.
Acceptance criteria
- A
model-registry implementation crate exists and registers ModelRegistryClientV1 in ClientHub.
- The SDK offers a per-model capabilities accessor (or a documented, stable mapping) that Chat Engine's
ModelRegistryClient adapter can consume directly.
Summary
gears/model-registryhasdocs/and amodel-registry-sdkcrate (traitModelRegistryClientV1with model/provider CRUD inmodel-registry-sdk/src/api.rs), but:ModelRegistryClientV1inClientHub, so a co-located gear cannot resolve it at runtime.get_tenant_model/list_tenant_modelsbut nomodel_capabilities(model_id). Chat Engine'sModelRegistryClient::model_capabilitieswould have to fetchModelV1and mapinfo.capabilities→ModelCapabilitySchemaby hand.Why this blocks usage
Chat Engine's first-party LLM plugin resolves session capabilities on
on_session_createdvialist_models+model_capabilities. With no running gear and no capability accessor, there is no production source for capability resolution on the first-party path.Acceptance criteria
model-registryimplementation crate exists and registersModelRegistryClientV1inClientHub.ModelRegistryClientadapter can consume directly.