Question: current contribution route for a third-party hosted LiteLLM model #96

I am investigating whether a Tsubasa configuration is appropriate for the current AutoCodeRover repository. The endpoint is OpenAI-compatible and uses tsubasa-fast / tsubasa-pro aliases.

At the pinned source below, OpenaiLiteLLMModel can reuse an OpenAI-compatible API base, but register_all_models() exposes an explicit set of model classes. The Tsubasa aliases are not registered. The older merged Bedrock contribution #40 is relevant architecture precedent; the closed, unmerged custom-model PR #94 does not establish a current acceptance policy.

Would maintainers prefer an explicit registered model configuration, a generic custom-model facility, or external documentation? Before proposing code, could you also clarify the intended contribution terms for an external hosted-provider entry under the repository's current Sonar Source-Available License v1.0? I am not assuming the former MIT terms apply or offering a legal interpretation.

If this route is maintained, the smallest candidate would reuse the existing LiteLLM transport and supply explicit context/output/pricing metadata, followed by serialization and budget checks. No repair benchmark, live inference, license approval or upstream acceptance is claimed by this inquiry.

Source: app/model/gptlitellm.py, app/model/register.py, LICENSE.

Tsubasa-affiliated, AI-assisted investigation.