You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "richardchen874-sys (via GitHub)" <gi...@apache.org> on 2026/08/06 14:31:43 UTC

Re: [D] Proposal: Databricks Unity AI Gateway model class for apache-airflow-providers-common-ai [airflow]

GitHub user richardchen874-sys closed the discussion with a comment: Proposal: Databricks Unity AI Gateway model class for apache-airflow-providers-common-ai

The stream-timing focus is exactly the right first layer; without chunk gaps, stalls, and interruption data, usage and cost comparison comes too early.

I would log route choice, provider/model, tool-call support, latency, usage, and retry/fallback reason together. Agent failures are much easier to debug when the route decision is visible.

This is close to what I am experimenting with: official Chinese models behind an OpenAI-compatible multi-model layer, with an emphasis on predictable usage and routing behavior. For airflow, is the harder problem provider compatibility, routing quality, or keeping per-run cost predictable?

GitHub link: https://github.com/apache/airflow/discussions/67581#discussioncomment-17922113

----
This is an automatically sent email for commits@airflow.apache.org.
To unsubscribe, please send an email to: commits-unsubscribe@airflow.apache.org