Hi Morty,
Thanks for taking the time to share your observations. I want to clarify the technical mechanism behind this to put your mind at ease—there is no bug causing background auth handshakes to drain your quota.
The core of the misunderstanding stems from our current naming convention in the “Name” column.
Here is what is actually happening:
The entries labeled “Login Device” are not keep-alive pings or authentication handshakes. They are your actual, real Model Inference calls (your coding work).
The “Name” column simply indicates the authentication method used for the request:
- When you authenticate KimiCLI directly via OAuth (logging into the device), the backend hardcodes the source as
Login Device. - If you were to generate a standard API Key and use that instead, the column would display the specific name you gave to that API key.
Because third-party tools currently rely on API keys and lack direct OAuth login capabilities, Login Device is used as the static identifier for native OAuth sessions. We completely understand how this nomenclature is misleading and makes it look like an auth-related event. If we support third-party login flows in the future, this identifier will be updated to reflect the specific third-party origin or landing page.
Regarding the Dashboard and Quota:
Your feedback on the dashboard synchronization lag and the transparency of the dual-pool quota system is completely valid. I am passing this feedback directly to the product team so we can improve the real-time accuracy of the usage dashboard and make the plan limits more explicit in the documentation.
Your quota is being consumed by actual inference work, not a rogue keep-alive loop. I hope this clears up the mystery!