建议：usage 类命令支持 API key 鉴权（现需 Console 浏览器登录，票据寿命1~4天，无法无人值守） #202

Activity

1. dej4vu commented on Sep 19, 2026

   

   dej4vu

   on Sep 19, 2026

   More actions

   同样的问题，我的有效期只有一天，基本每天都要登录一次，查询用量也不是什么敏感操作
2. Josephur commented on Oct 17, 2026

   

   Josephur

   on Oct 17, 2026

   More actions

   Adding another data point from an international Token Plan (personal) user.

   We use the Bailian CLI (bl 2.3.1, Linux) indirectly through CodexBar, which runs bl console call against the Token Plan personal usage API on every refresh. When the console ticket expires, every call fails with "Console session is not logged in or has expired." CodexBar's browser-cookie fallback dies at the same time (BailianGateway.Login.NotLogined), so the provider just goes dark until a human runs bl auth login --console --console-site international again.

   From bl's own telemetry on this machine: 929 failed console call attempts between the ticket expiring and the next manual login. bl auth status still reports a configured console gateway during that window, so nothing distinguishes "expired ticket" from a healthy setup without actually making a call.

   This makes it really hard to use tools like CodexBar for accurate, always-on usage reads: the Token Plan card silently stops updating every few days, and the only fix is an interactive browser login that cannot be scripted or scheduled.

   The requests in this issue would solve it for us — an API-key-authenticated read-only usage/subscription query, a way to check remaining ticket lifetime, and a distinct "ticket expired" error. Until one of those exists, unattended usage monitoring on Token Plan is effectively impossible. Happy to provide logs or test a build if that helps.

   👍React with 👍1Reacted by Naayi
3. XXPermanentXX commented on Oct 28, 2026

   

   XXPermanentXX

   on Oct 28, 2026

   Collaborator

   More actions

   Thanks for the feedback! The CLI now supports persistent authentication using Alibaba Cloud AccessKey credentials (AK/SK), with automatic Access Token refresh for unattended tasks such as scheduled usage monitoring.

   1. If you use a RAM user's AK/SK, grant that user the modelstudio:GenerateCLIAccessToken permission. This is required to generate a CLI Access Token; usage queries still require the relevant service permissions.

   2. Configure authentication with:

      bl auth login --open-api \
        --access-key-id "<AccessKey ID>" \
        --access-key-secret "<AccessKey Secret>"

      This automatically generates and saves an Access Token along with your AK/SK. When the token expires, the CLI uses the stored AK/SK to refresh it and retry the request. No manual token configuration or repeated browser login is needed.

   3. Once configured, you can query Token Plan usage:

      bl usage token-plan --output json

      See the usage and quota documentation for more commands.

   This provides automatic token renewal through AK/SK. Direct API-key authentication for usage queries, clearer error messages, and token lifetime visibility remain separate requests. Thanks for raising them!

   ❤️React with ❤️2Reacted by Josephur and Naayi
4. Naayi commented on Oct 31, 2026

   

   Naayi

   on Oct 31, 2026

   More actions

   Thanks for the AK/SK persistent-auth support. Unfortunately it does not solve this issue for a domestic-site Token Plan (personal, Pro) account, so I'm adding a negative data point from a clean reproduction of the documented flow.

   Environment

   • bl 2.7.2, Windows x64
   • Domestic site (cn-beijing), Token Plan personal (Pro)
   • Model gateway: https://token-plan.cn-beijing.maas.aliyuncs.com

   Steps (exactly as recommended in the maintainer reply)

   1. Created a dedicated RAM user with a permanent AccessKey (no console access).

   2. Granted:

      • custom policy CLIBailianTokenOnly containing modelstudio:GenerateCLIAccessToken
      • AliyunTokenPlanReadOnlyAccess
      • AliyunBSSReadOnlyAccess

   3. Ran:

      bl auth login --open-api --access-key-id "LTAI..." --access-key-secret "..."

   4. bl auth status --output json confirms all three credentials coexist:

      {
        "console": { "source": "config", "masked": "2680...54bf", "region": "cn-beijing", "site": "domestic" },
        "openapi": { "source": "config", "access_key_id": "LTAI...xxxx", "access_key_secret": "****...****" }
      }

   Result

   With the console ticket present, everything works — but that ticket is the one obtained from the interactive bl auth login --console, not anything derived from AK/SK.

   To prove AK/SK alone is sufficient, I removed the access_token values from both the top level and the token-plan profile of ~/.bailian/config.json and re-ran the commands:

   Command	Result
   bl usage token-plan --output json	{"error":{"code":3,"message":"No console access token found."}}
   bl usage coding-plan --output json	same error, code 3
   bl token-plan harness-quota	same error, code 3
   bl token-plan list-seats --page-size 20	No seats found. — no auth error at all

   So list-seats clearly resolves through the OpenAPI path using the stored AK/SK, while every usage * command and harness-quota still hard-require a Console ticket (No console access token found.), even though AK/SK is configured and GenerateCLIAccessToken is granted.

   Follow-up: natural expiry, not a manual reset

   To rule out the possibility that the manual config edit above caused this rather than AK/SK being unsupported on that path: I restored the config, ran bl auth login --console once to obtain a fresh ticket, and left everything untouched. Just a few hours later, the ticket expired on its own and bl usage token-plan --output json went straight back to:

   {"error":{"code":3,"message":"No console access token found."}}

   Throughout this window the AK/SK configuration was never modified, and bl auth status kept reporting the openapi credential as present. So the failure happens with AK/SK intact — the stored AK/SK is simply not consulted for the usage * commands.

   Two questions

   1. Is AK/SK auto-refresh intended to cover the usage * commands at all? From this test it looks like only the OpenAPI-backed commands are covered, and step 3 of the maintainer reply ("you can query Token Plan usage with bl usage token-plan") doesn't hold for a personal account.
   2. Was this fix validated against Token Plan personal accounts specifically? The previous reporter (Josephur) is also on personal (international site). If both domestic and international personal accounts are affected, a note in the reply or the docs would save others the same debugging effort.

   The original asks still remain open from my side: an API-key- or AK/SK-authenticated read-only usage/subscription query, a distinct AuthExpired error instead of No console access token found. / bare NoPermission, and a way to check remaining ticket lifetime (bl auth currently only offers login, status, logout, generate-access-token).

   Happy to test a build or provide --verbose logs if that helps.