Follow-up to #61 (Databricks native APIs), which documents this limitation in memory-bank/aiConfig.md.
Problem
Protocol-stamping providers (LiteLLM, and now Databricks) infer a model's capabilities for the protocol they stamp. A natively-routed Databricks Claude model advertises thinkingEffortLevels and PDF input because the anthropic-messages route supports them; the same endpoint forced onto openai-chat (via a user protocol override or a connection-level protocol) does not support those capabilities — but it keeps the stamped ones.
The generic fix ("mask capabilities when final protocol ≠ stamp") was considered and withdrawn during planning: resolveModels merges user capability overrides into the flat model object before attachRouting, so a pipeline mask cannot distinguish user-supplied capability values from inferred ones, and no safe protocol-keyed mask exists post-merge.
Proposed direction
Introduce a provenance/profile seam in the resolution pipeline: carry inferred capabilities as a per-protocol profile (or tag capability values with their provenance — inferred vs user override) so that when the final resolved protocol differs from the discovery stamp, inferred capabilities can be re-derived for the actual route while user overrides still win.
Scope notes
- Pre-existing limitation for LiteLLM; Databricks native routing widens the surface.
- Related: a profile-key transport through chat params (separate issue) could share the same seam.
Follow-up to #61 (Databricks native APIs), which documents this limitation in
memory-bank/aiConfig.md.Problem
Protocol-stamping providers (LiteLLM, and now Databricks) infer a model's capabilities for the protocol they stamp. A natively-routed Databricks Claude model advertises
thinkingEffortLevelsand PDF input because theanthropic-messagesroute supports them; the same endpoint forced ontoopenai-chat(via a user protocol override or a connection-levelprotocol) does not support those capabilities — but it keeps the stamped ones.The generic fix ("mask capabilities when final protocol ≠ stamp") was considered and withdrawn during planning:
resolveModelsmerges user capability overrides into the flat model object beforeattachRouting, so a pipeline mask cannot distinguish user-supplied capability values from inferred ones, and no safe protocol-keyed mask exists post-merge.Proposed direction
Introduce a provenance/profile seam in the resolution pipeline: carry inferred capabilities as a per-protocol profile (or tag capability values with their provenance — inferred vs user override) so that when the final resolved protocol differs from the discovery stamp, inferred capabilities can be re-derived for the actual route while user overrides still win.
Scope notes