Skip to content

docs: document undocumented customer-facing changes from the last week #11677

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
keydunov wants to merge 1 commit into
base: master
Choose a base branch
from
Open

docs: document undocumented customer-facing changes from the last week #11677

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 6 additions & 5 deletions docs-mintlify/admin/account-billing/ai-tokens.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,12 +75,13 @@ allowance resets at the start of each calendar month.

## Tracking usage

Administrators can monitor token consumption through the **AI Tokens Usage**
tab in the billing settings page. The dashboard shows:
Administrators can monitor token consumption on the billing settings page,
under two tabs:

- Total token usage over time
- Remaining allocation from per-seat grants and token packages
- Breakdown by usage dimension
- **AI Usage** — aggregate spend per user or per role over a billing period,
with a chart and a table. Covers the full period, not just recent activity.
- **AI Requests** — the raw request log, on a rolling window of hours with a
live tail of new requests as they come in.
Comment on lines +78 to +84

@claude claude Bot Aug 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rewrite drops "remaining allocation" and nothing else on the page covers it.

The old bullet list included "Remaining allocation from per-seat grants and token packages" — that's the one thing an admin most wants from this page, and it's now unmentioned anywhere in the file. It matters directly for the very next section (## When limits are reached), which tells admins to go buy packages but never says where they can see how much is left. If the AI Usage tab still shows remaining balance, keep a clause for it.

Two smaller things:

  • "on a rolling window of hours" is vague — say the actual window (e.g. "the last 24 hours") or drop the qualifier and just call it a live log of recent requests.
  • AI Usage collides with the existing AI Usage dashboard in Usage Analytics. Same name, different surface. Worth a parenthetical here (or in the Usage Analytics row) so the two don't get confused — the BYOM line names the tabs with no location qualifier at all.
  • "aggregate spend per user or per role" — the page is about tokens, and spend only applies to on-demand/contract customers. If the tab shows tokens with a cost column, say "token usage and cost".

Fix this →


## When limits are reached

Expand Down
2 changes: 1 addition & 1 deletion docs-mintlify/admin/ai/bring-your-own-model.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ directly by your model provider based on their pricing.
This means:

- No Cube token quota is deducted for BYOM chat requests
- No token usage is tracked in the AI Tokens Usage dashboard for BYOM requests
- No token usage is tracked in the AI Usage / AI Requests tabs for BYOM requests
- Per-seat token grants and token packages do not apply

See [AI Tokens][ref-ai-tokens] for details on how token billing works with
Expand Down
9 changes: 9 additions & 0 deletions docs-mintlify/docs/pre-aggregations/cube-store-architecture.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1045,6 +1045,15 @@ Self-hosted deployments can raise the ceiling instead, but
`CUBESTORE_TRANSPORT_MAX_MESSAGE_SIZE` and `CUBESTORE_TRANSPORT_MAX_FRAME_SIZE`
have to go up together, since a message is sent as a single frame.

### Connection limits

Alongside message size, a node can also cap how many of these WebSocket
connections one authenticated user holds at once, via
[`CUBESTORE_MAX_WS_CONNECTIONS_PER_USER`](/reference/configuration/environment-variables#cubestore_max_ws_connections_per_user).
At the limit, the user's oldest connection is closed to admit the new one; a
client that still needs it reconnects. The limit is counted per node and
disabled (`0`) by default.

### Why it lives in Cube Store

Folding the cache and queue into Cube Store is itself a design decision in
Expand Down
31 changes: 31 additions & 0 deletions docs-mintlify/reference/embed-apis/generate-session.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -281,6 +281,37 @@ DELETE /api/v1/embed-tenants/{embedTenantName}/user-attributes/{id}

These endpoints use the same `Api-Key` authentication as Generate Session and require admin access. List endpoints return cursor-paginated results (`?first=`, `?after=`).

### Provisioning users

An embed user otherwise only exists in Cube once they generate their first
session, which means a workbook or dashboard can't be shared with a teammate
who hasn't opened the embed yet. To provision a user ahead of time — from
your own user directory, before their first session — use:

```text
POST /api/v1/embed-tenants/{embedTenantName}/user
Comment on lines +289 to +292

@claude claude Bot Aug 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit / follow-up: neither POST /api/v1/embed-tenants/{embedTenantName}/user nor POST .../users is in docs-mintlify/api-reference/api.yaml — it currently only has GET /api/v1/embed-tenants/{embedTenantName}/users (listEmbedUsers, line 3047). Since that file is generated by scripts/extract-api.mjs from the enterprise repo, the prose here will be ahead of the OpenAPI reference until the next extraction. Not blocking, and the same is already true of the user-attributes endpoints listed just above, but worth a re-run so the two references agree — that's also where the bulk-action limit and the exact succeeded/failed shape would get pinned down.

POST /api/v1/embed-tenants/{embedTenantName}/users
```

The single-user endpoint takes one body with the same fields `generate-session`
accepts for an external user — `externalId`, `email`, `userProfile`, `groups`,
`tenantGroups` — so an integration uses one vocabulary whether it pushes its
directory ahead of time or lets a session provision the user. Session-only
fields (`userAttributes`, `securityContext`) aren't accepted here: a later
session re-applies them anyway, so provisioning can't be a second source of
truth for row-level security. `groups` and `tenantGroups` follow the same
replace-when-supplied, clear-with-`[]`, preserve-when-omitted rules as
Comment on lines +296 to +303

@claude claude Bot Aug 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tenantGroups isn't documented on this page — the framing and the #groups link both dead-end.

Two problems in this paragraph:

  1. It presents the accepted fields as "the same fields generate-session accepts for an external user — externalId, email, userProfile, groups, tenantGroups", but tenantGroups appears nowhere else in this file: it's not a row in the Request Body table and not in the <Info> list of fields disallowed with internalId. So the sentence's whole point ("one vocabulary") is undercut — the reader can't look the field up. It's only described in api-reference/api.yaml and api-reference/changelog.mdx.
  2. [Groups](#groups) resolves, but that section is exclusively about groups (tenant-wide names, embed_user_groups in creator mode). Sending the reader there for tenantGroups semantics gives them the wrong scope, and the replace/clear/preserve table there never mentions tenantGroups.

Suggest adding a tenantGroups row to the Request Body table and a short paragraph under ## Groups (or a sibling ## Tenant groups) before pointing at it from here.

Fix this →

[Groups](#groups).

The bulk endpoint takes `{ "users": [...] }` (up to the account's bulk-action
limit) and is partially successful: it always returns `200`, with each entry
reported in `succeeded` or `failed` (with an `error.status`/`error.message`),
in the order requested.

Provisioning is idempotent — an existing `externalId` is updated, not
rejected — and the embed tenant itself is created on demand if it doesn't
exist yet.

### Response

@claude claude Bot Aug 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

### Response now reads as the provisioning endpoints' response.

### Response documents the Generate Session response ({ "sessionId": ... }). It was already awkwardly nested under ## Embed-tenant admin API, but before this PR it at least sat right after a short paragraph. Now it immediately follows a section that describes two POST endpoints and explicitly says the bulk one returns succeeded/failed — so a reader scrolling in lands on "Response → { "sessionId": ... }" and reasonably concludes that's what POST .../users returns.

Cheapest fix while you're in here: promote it back out of the admin-API section, e.g. rename to ## Generate Session response and move it above ## Embed-tenant admin API, or at minimum retitle it ### Generate Session response.

Fix this →


The API returns a session object:
Expand Down
Loading