Problem
Desktop provider names do not reliably tell users where requests are sent. For example, Alibaba, Alibaba Coding Plan, and Alibaba Token Plan represent different access paths and regions, but the naming difference alone does not make the effective API endpoint obvious. A user can easily choose the wrong connection or apply a credential intended for a different Alibaba Cloud / Model Studio endpoint.
Today provider-connection-detail.tsx renders the Service URL row only when the endpoint is user-editable. Fixed built-in provider endpoints are therefore hidden after setup, so users cannot verify the scheme, hostname, or path that a connection will use.
Desired outcome
Show the effective inference base endpoint on every Desktop provider connection detail page whenever Maka knows one.
- Display the complete URL, including scheme, hostname, and path, for example
https://example.com/compatible-mode/v1.
- Show the connection override when one is configured; otherwise show the resolved provider default.
- Show a resolved derived/template endpoint rather than a generic “provider default” label when the concrete value is available.
- Keep fixed built-in endpoints read-only. Preserve the existing edit affordance only for endpoints that are genuinely user-owned, such as custom relays and local runtimes.
- If an OAuth or internally managed provider has no concrete endpoint that can be exposed, show an explicit managed/unavailable state instead of silently omitting the row.
- Keep the full value readable in both Chinese and English layouts, including long URLs.
- Do not expose credentials or secret-bearing query parameters.
The Alibaba provider family should be covered explicitly so a user can distinguish API, Coding Plan, Token Plan, China, and global connections by their actual endpoint rather than by display-name interpretation. Focused tests should cover default, overridden, derived, fixed/read-only, and unavailable endpoint states.
Alternatives or workarounds
Users can currently infer the endpoint from provider names, documentation, or source configuration, but that is error-prone and not available at the point of use. Renaming providers or adding more region text would help individual cases, but it would continue to encode routing details indirectly and would not cover custom overrides. Making every endpoint editable is also unnecessary and could let users accidentally break fixed provider connections; visibility is the primary requirement.
Problem
Desktop provider names do not reliably tell users where requests are sent. For example,
Alibaba,Alibaba Coding Plan, andAlibaba Token Planrepresent different access paths and regions, but the naming difference alone does not make the effective API endpoint obvious. A user can easily choose the wrong connection or apply a credential intended for a different Alibaba Cloud / Model Studio endpoint.Today
provider-connection-detail.tsxrenders the Service URL row only when the endpoint is user-editable. Fixed built-in provider endpoints are therefore hidden after setup, so users cannot verify the scheme, hostname, or path that a connection will use.Desired outcome
Show the effective inference base endpoint on every Desktop provider connection detail page whenever Maka knows one.
https://example.com/compatible-mode/v1.The Alibaba provider family should be covered explicitly so a user can distinguish API, Coding Plan, Token Plan, China, and global connections by their actual endpoint rather than by display-name interpretation. Focused tests should cover default, overridden, derived, fixed/read-only, and unavailable endpoint states.
Alternatives or workarounds
Users can currently infer the endpoint from provider names, documentation, or source configuration, but that is error-prone and not available at the point of use. Renaming providers or adding more region text would help individual cases, but it would continue to encode routing details indirectly and would not cover custom overrides. Making every endpoint editable is also unnecessary and could let users accidentally break fixed provider connections; visibility is the primary requirement.