Name and Version
aidial-client 0.12.0
What is the problem this feature will solve?
The typed listing models in the client have drifted behind the DIAL Core API. Several fields that Core now returns in model and deployment/application listings are only accepted via extra="allow" passthrough — they are not exposed as typed attributes, so users get no autocomplete, validation, or documentation for them.
Missing response fields:
- Model listing —
embedding_dimensions (vector size for embedding models).
- Features object (shared by models/applications/toolsets) —
chat_completion and responses_api endpoint flags, and reasoning_efforts (a string array that supersedes the old reasoning_efforts_supported boolean).
- Features object (pre-existing drift) —
max_tokens_supported, max_completion_tokens_supported, custom_temperature_supported.
What is the feature you are proposing to solve the problem?
Add the missing fields as first-class typed fields on ModelInfo (types/model.py) and Features (types/deployment.py), with defaults that stay compatible with older Core versions, and document them in the README sample responses.
What alternatives have you considered?
Relying on extra="allow" passthrough (current behavior) — works at runtime but leaves the fields untyped, undocumented, and undiscoverable.
Name and Version
aidial-client 0.12.0
What is the problem this feature will solve?
The typed listing models in the client have drifted behind the DIAL Core API. Several fields that Core now returns in model and deployment/application listings are only accepted via
extra="allow"passthrough — they are not exposed as typed attributes, so users get no autocomplete, validation, or documentation for them.Missing response fields:
embedding_dimensions(vector size for embedding models).chat_completionandresponses_apiendpoint flags, andreasoning_efforts(a string array that supersedes the oldreasoning_efforts_supportedboolean).max_tokens_supported,max_completion_tokens_supported,custom_temperature_supported.What is the feature you are proposing to solve the problem?
Add the missing fields as first-class typed fields on
ModelInfo(types/model.py) andFeatures(types/deployment.py), with defaults that stay compatible with older Core versions, and document them in the README sample responses.What alternatives have you considered?
Relying on
extra="allow"passthrough (current behavior) — works at runtime but leaves the fields untyped, undocumented, and undiscoverable.