You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tsubasa users currently need to enter an OpenAI-compatible endpoint and model manually. Would a named Tsubasa preset fit Zero's provider catalog?
At 99721c7, openAICompat already supplies the transport and Chat Completions format. The proposed change would add a descriptor using that helper, with:
Name and ID: Tsubasa / tsubasa
Base URL: https://api.tsubasa.sh/v1
Credential: TSUBASA_API_KEY, sent as bearer authentication
Models: tsubasa-fast and tsubasa-pro; both have 32,768-token context windows
Maximum output: 8,192 for Fast and 16,384 for Pro; an initial smaller request budget must leave room for Zero's prompt and tools
The existing custom-provider path is the alternative. No new transport, OAuth flow, default-provider change, or special routing is proposed. If the preset is welcome, the implementation would include catalog/factory regression checks and an actual configured-client check for request budgets, streaming, credential isolation, and HTTP errors. Tools would need explicit qualification rather than an inferred capability flag.
This is a Tsubasa-affiliated proposal prepared with OpenAI Codex. Source inspection is complete, but Zero-specific runtime and live Tsubasa inference have not been tested. The September 28 public model-list probe returned HTTP 404. I will wait for the required approved parent issue before implementation, as your contribution policy requests.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Tsubasa users currently need to enter an OpenAI-compatible endpoint and model manually. Would a named Tsubasa preset fit Zero's provider catalog?
At 99721c7,
openAICompatalready supplies the transport and Chat Completions format. The proposed change would add a descriptor using that helper, with:Tsubasa/tsubasahttps://api.tsubasa.sh/v1TSUBASA_API_KEY, sent as bearer authenticationtsubasa-fastandtsubasa-pro; both have 32,768-token context windowsThe existing custom-provider path is the alternative. No new transport, OAuth flow, default-provider change, or special routing is proposed. If the preset is welcome, the implementation would include catalog/factory regression checks and an actual configured-client check for request budgets, streaming, credential isolation, and HTTP errors. Tools would need explicit qualification rather than an inferred capability flag.
This is a Tsubasa-affiliated proposal prepared with OpenAI Codex. Source inspection is complete, but Zero-specific runtime and live Tsubasa inference have not been tested. The September 28 public model-list probe returned HTTP 404. I will wait for the required approved parent issue before implementation, as your contribution policy requests.
All reactions