Problem
kbagent kai currently covers chat/Q&A (ping, ask, chat, history,
chat-detail, preflight) but has no visibility into Kai's cost controls.
Keboola Connection exposes two Kai-specific settings that are UI-only
today (Settings → Kai Agent → Kai spend limits):
- Monthly project budget — hard cap on total Kai spend per project per
calendar month.
- Per-user limits — a default limit plus optional per-user overrides
(set to 0 to revoke a user's Kai access).
And a Project Consumption dashboard shows current Kai spend for the
month, broken out as its own usage category.
None of this is reachable from the API as far as I could tell:
- Digging through
help.keboola.com and the Management API reference,
GET /manage/projects/{projectId} returns limits/metrics, but
neither includes a Kai/AI-spend entry — confirmed empirically against a
live project (kbagent project info).
- I also checked kbagent's own
kbagent serve REST mirror
(http://127.0.0.1:8001/docs, OpenAPI spec, v0.94.0) in case a Kai
usage/limits surface already existed there and I'd simply missed it in
the CLI docs. It doesn't: the only kai-tagged routes are /kai/ping,
/kai/preflight, /kai/ask, /kai/chat, /kai/chat/{chat_id},
/kai/history — an exact 1:1 mirror of the current CLI subcommands, no
more. GET /projects/{alias}/info is the only limits-adjacent route and
it's the same limits/metrics payload above, with nothing Kai-related
in it.
That blocks two real workflows:
- Read: "what's our current Kai spend across N projects this month?"
-- today this means opening the Consumption dashboard once per project.
- Write / GitOps: teams that want Kai spend limits under version
control (PR-reviewed changes, applied on merge to main) currently have
no API to apply against — only the Settings UI.
Proposal
kbagent kai usage [--project ALIAS] — read current-month Kai
consumption per project (multi-project by default, per existing CLI
conventions).
kbagent kai limits [--project ALIAS] — read the configured monthly
project budget + per-user limits.
kbagent kai limits set --project ALIAS [--project-budget N] [--default-user-limit N] [--user-limit EMAIL=N] — write path, gated
the same way other write/admin operations are (permission engine,
--dry-run, confirmation).
Open question
I could not confirm from public docs or from kbagent's own REST surface
whether Keboola's Management/Billing API exposes Kai spend data or limit
mutation at all (only a generic POST /manage/projects/{projectId}/limits
with an undocumented catalogue of name values, e.g.
goodData.usersCount, and a PAYG-only GET /credits with no per-category
breakdown). Before implementation, this needs a check with Keboola on
whether:
- a Kai-specific limit
name exists for the generic limits endpoint, or
- a dedicated Kai billing/telemetry endpoint exists but isn't
publicly documented yet.
If neither exists yet, this issue is really a request to expose one,
filed here so it's tracked against the CLI that would consume it.
Why this matters
Kai spend is real money with no automated ceiling visibility today outside
clicking through the UI per project — for orgs running many Keboola
projects (e.g. one per data domain), that doesn't scale, and it blocks
treating spend-limit configuration as code (PR review, audit trail, CI
enforcement) the way the rest of this CLI already treats Keboola config.
Problem
kbagent kaicurrently covers chat/Q&A (ping,ask,chat,history,chat-detail,preflight) but has no visibility into Kai's cost controls.Keboola Connection exposes two Kai-specific settings that are UI-only
today (Settings → Kai Agent → Kai spend limits):
calendar month.
(set to 0 to revoke a user's Kai access).
And a Project Consumption dashboard shows current Kai spend for the
month, broken out as its own usage category.
None of this is reachable from the API as far as I could tell:
help.keboola.comand the Management API reference,GET /manage/projects/{projectId}returnslimits/metrics, butneither includes a Kai/AI-spend entry — confirmed empirically against a
live project (
kbagent project info).kbagent serveREST mirror(
http://127.0.0.1:8001/docs, OpenAPI spec, v0.94.0) in case a Kaiusage/limits surface already existed there and I'd simply missed it in
the CLI docs. It doesn't: the only
kai-tagged routes are/kai/ping,/kai/preflight,/kai/ask,/kai/chat,/kai/chat/{chat_id},/kai/history— an exact 1:1 mirror of the current CLI subcommands, nomore.
GET /projects/{alias}/infois the only limits-adjacent route andit's the same
limits/metricspayload above, with nothing Kai-relatedin it.
That blocks two real workflows:
-- today this means opening the Consumption dashboard once per project.
control (PR-reviewed changes, applied on merge to main) currently have
no API to apply against — only the Settings UI.
Proposal
kbagent kai usage [--project ALIAS]— read current-month Kaiconsumption per project (multi-project by default, per existing CLI
conventions).
kbagent kai limits [--project ALIAS]— read the configured monthlyproject budget + per-user limits.
kbagent kai limits set --project ALIAS [--project-budget N] [--default-user-limit N] [--user-limit EMAIL=N]— write path, gatedthe same way other
write/adminoperations are (permission engine,--dry-run, confirmation).Open question
I could not confirm from public docs or from kbagent's own REST surface
whether Keboola's Management/Billing API exposes Kai spend data or limit
mutation at all (only a generic
POST /manage/projects/{projectId}/limitswith an undocumented catalogue of
namevalues, e.g.goodData.usersCount, and a PAYG-onlyGET /creditswith no per-categorybreakdown). Before implementation, this needs a check with Keboola on
whether:
nameexists for the generic limits endpoint, orpublicly documented yet.
If neither exists yet, this issue is really a request to expose one,
filed here so it's tracked against the CLI that would consume it.
Why this matters
Kai spend is real money with no automated ceiling visibility today outside
clicking through the UI per project — for orgs running many Keboola
projects (e.g. one per data domain), that doesn't scale, and it blocks
treating spend-limit configuration as code (PR review, audit trail, CI
enforcement) the way the rest of this CLI already treats Keboola config.