`uses_openai` gateway prefix is unreachable since any-llm retired the `gateway` provider

Đang mở
  • Có gì không ổn?
#23 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

@cyyecao-lappland đang làm issue này rồi.

Từ ngày 2/10/2026.

  • #28 của @cyyecao-lappland — đang mở
  • #30 của @cyyecao-lappland — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
42/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
api, backend, backend-api-design

Hướng nghiên cứu

Start in tinyagent/agent.py with the provider parsing and AnyLLM.create flow. Reproduce the documented otari:openai and otari:anthropic cases, then settle whether the outer otari provider or inner provider should be instantiated. Done means gateway-prefixed model IDs no longer fail and the chosen routing preserves the intended uses_openai behavior.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

tinyagent/agent.py strips a gateway: prefix before computing uses_openai:

provider_name, model_id = AnyLLM.split_model_provider(self.config.model_id)
if provider_name == "gateway":
    provider_name, model_id = AnyLLM.split_model_provider(model_id)
self.uses_openai = provider_name == LLMProvider.OPENAI

That branch can no longer run. any-llm migrated the gateway provider to otari (mozilla-ai/any-llm#1089) and then removed the gateway provider along with the GATEWAY value of the LLMProvider enum (mozilla-ai/any-llm#1122, merged 2026-06-12). split_model_provider raises on the first call, before the check is reached:

>>> AnyLLM.split_model_provider("gateway:openai:gpt-4.1-mini")
any_llm.exceptions.UnsupportedProviderError: 'gateway' is not a supported provider

any-llm kept the legacy GATEWAY_API_KEY and GATEWAY_API_BASE env vars inside the otari provider as the migration path, but deliberately did not keep a provider-name alias. So every gateway: model id has been broken since 2026-06-12.

Renaming the sentinel to otari restores the original semantics:

otari:openai:gpt-4.1-mini  -> uses_openai True
otari:anthropic:claude-3   -> uses_openai False

One design question is worth settling before that. The strip reassigns provider_name, which then flows into AnyLLM.create(provider_name, ...), so gateway:openai:gpt-4 built a plain OpenAI client and never instantiated the gateway provider at all; reaching the gateway required also passing api_base. That was reasonable when gateway was a thin OpenAI-compatible wrapper. OtariProvider is now a real SDK-backed provider with native /messages pass-through, batch support and cache_control preservation, so a straight rename would keep bypassing it.

Should otari:openai:gpt-4 route through OtariProvider, or keep resolving to the inner provider with the caller supplying api_base? That decides whether this is a one-word change or a behavior fix.

For context, any-agent has dropped its gateway: test coverage in mozilla-ai/any-agent#954, since the behavior lives here and otari: cannot stand in there without taking the otari SDK as a dependency.

Note: this issue was drafted by Claude Opus 5 via back-and-forth with @njbrake. The reasoning and decisions are his; the prose is Claude's.

Ngôn ngữ chính
Python
Star
34
Fork
7
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của mozilla-ai/tinyagent

Tất cả issue của mozilla-ai/tinyagent

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.