I don’t think there is an established convention to call a qube that is a client of some Qubes OS admin API methods an “admin qube”. E.g. people usually don’t call an “audio VM/qube” or a “GUI domain/VM/qube” an admin qube, even though they make admin API calls.
When the term admin qube is occasionally used in the issue tracker, it tends to be a synonym for AdminVM, with both referring to dom0. dom0 is of course unusual in that it’s both an admin API client and an admin API server (including policy evaluation) - it talks to itself when e.g. one of the qvm-something tools is run in dom0. I’d say this server side is what makes it an (or rather the) admin qube.
BTW this is also consistent with the Qubes Air blog post. It distinguishes an admin qube from a GUI qube, and only uses “admin qubes” in plural for the meta-system spanning multiple “zones”, with one admin qube per zone and that admin qube being dom0 if the zone is based on Xen.