docs: document undocumented Cube Cloud/Core features

[keydunov]

• CubeStore: document the new CUBESTORE_MAX_CONCURRENT_QUERY_PLANS and
  CUBESTORE_MAX_QUEUED_QUERY_PLANS environment variables (feat(cubestore): Limit how many logical plans are built at once #11924), which
  throttle how many query logical plans Cube Store builds and queues at
  once. Both were missing from the environment variables reference.
• Agent config: add chassis as a third documented runtime value (it's
  a live option in both agents/config.yml and the agent settings UI) and
  list the Fireworks-hosted kimi_k3 / glm_5_3 predefined models under
  the LLM section.
• GCP OIDC / CSPS: note that a Test Connection failure on GCS past the
  token exchange now reports the underlying GCS error instead of a
  generic internal one (cubejs-enterprise#15187).

Part of the recurring undocumented-features sweep across cube-js/cube and
cubedevinc/cubejs-enterprise.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GAQae3M3w5yukEDWT2ikUQ

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
cubed3	🟢 Ready	View Preview	Sep 19, 2026, 12:15 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[claude]

Claude finished @keydunov's task in 1m 46s —— View job

---

Docs are accurate against the Rust source — 1 medium, 2 low, all inline.

Review details

• Read the diff and the changed doc page
• Verify env var names, defaults and semantics against the Rust source
• Check placement/ordering and table formatting conventions
• Handle prior review threads
• Post findings

Verified against the source

Claim	Source	Verdict
auto default sizes to max(4, 2 * cores)	rust/cubestore/cubestore/src/config/mod.rs:1402-1407	✅
auto is the default when unset; case-insensitive	config/mod.rs:1411-1429	✅
0 disables the concurrency limit	queryplanner/planning_throttle.rs:34-42	✅
CUBESTORE_MAX_QUEUED_QUERY_PLANS default 5000	config/mod.rs:1822	✅
0 disables the queue limit	planning_throttle.rs:94-103	✅
Queue full ⇒ rejected, not queued	planning_throttle.rs:96-103	✅

Findings

1. Medium — environment-variables.mdx:2230-2233: the CUBESTORE_MAX_CONCURRENT_QUERY_PLANS description omits rejection after CUBESTORE_QUERY_TIMEOUT. queryplanner/mod.rs:296 passes query_timeout() as the throttle's max_wait, and the resulting user error names this variable — but the page gives no way to connect the two. Suggestion posted inline.
2. Low — environment-variables.mdx:2228: both entries sit after CUBESTORE_QUERY_TIMEOUT, breaking the section's alphabetical order; they belong before CUBESTORE_MAX_WS_CONNECTIONS_PER_USER (line 2109).
3. Low — environment-variables.mdx:2235-2237: first table's separator row is one char wider than its header cell, and 2 x cores should read 2 * cores.

Nothing security- or performance-relevant; the change is docs-only, so no tests apply. No build or lint was run — a .mdx content edit doesn't compile, and Mintlify has no CI lint in this repo.

Review threads

No prior threads — the listing returned 0 of mine (single page, empty nodes). Nothing resolved, nothing re-affirmed, no duplicates to skip.

· [`claude/gallant-ramanujan-v78ks1`](https://github.com/cube-js/cube/tree/claude/gallant-ramanujan-v78ks1)

[claude]

The description leaves out the one behaviour an operator actually hits: a query that can't get a planning slot is rejected after CUBESTORE_QUERY_TIMEOUT seconds, not queued indefinitely.

rust/cubestore/cubestore/src/queryplanner/mod.rs:296 passes config.query_timeout() as the throttle's max_wait, and planning_throttle.rs:85-90 turns the expiry into a user error:

Waited longer than 120 s (CUBESTORE_QUERY_TIMEOUT) for a query planning slot.
Raise CUBESTORE_MAX_CONCURRENT_QUERY_PLANS to plan more queries at once.

Someone reading only this page sees that error and has no way to connect it to this variable. Worth one sentence:

Suggested change

	The maximum number of query logical plans Cube Store builds at the same time.
	Planning runs before the result cache and is CPU-intensive, so a burst of
	queries can oversubscribe the available cores; this limit gates how many
	plans are built concurrently. `auto` (the default) sizes the limit to
	The maximum number of query logical plans Cube Store builds at the same time.
	Planning runs before the result cache and is CPU-intensive, so a burst of
	queries can oversubscribe the available cores; this limit gates how many
	plans are built concurrently. A query that waits longer than
	[`CUBESTORE_QUERY_TIMEOUT`](#cubestore_query_timeout) for a planning slot is
	rejected with an error. `auto` (the default) sizes the limit to

[claude]

Both entries land out of alphabetical order. The Cube Store section runs AWS_* → BIND_ADDR → CACHE_* → … → LOG_LEVEL → MAX_WS_CONNECTIONS_PER_USER → META_* → MINIO_* → NO_UPLOAD → PORT → QUERY_TIMEOUT, so MAX_CONCURRENT_QUERY_PLANS and MAX_QUEUED_QUERY_PLANS belong immediately before CUBESTORE_MAX_WS_CONNECTIONS_PER_USER (line 2109), not after CUBESTORE_QUERY_TIMEOUT. Readers scanning the page for MAX_* will stop at 2109 and conclude these don't exist.

[claude]

Separator row is one cell-width off from the header (27 dashes under a 26-char cell), the only table on the page where they don't line up. Rendering is unaffected; it's the diff that looks wrong.

Suggested change

	| Possible Values | Default in Development | Default in Production |
	| ------------------------- | ---------------------- | --------------------- |
	| Possible Values | Default in Development | Default in Production |
	| ------------------------ | ---------------------- | --------------------- |
	| `auto`, `0`, or a number | `auto` | `auto` |

Also 2 x cores on line 2233 reads as a typo for 2 * cores — the source is std::cmp::max(4, 2 * cores) at rust/cubestore/cubestore/src/config/mod.rs:1406.

[claude]

Claude finished @keydunov's task in 2m 58s —— View job

---

Docs-only; env-var behaviour verified against the CubeStore source and accurate. 0 high, 0 medium, 3 low posted inline; 2 prior threads re-affirmed.

Review details

• Read the diff and changed files
• Verify documented env vars / features against source
• Handle prior review threads
• Post findings

Verified against source

CUBESTORE_MAX_CONCURRENT_QUERY_PLANS / CUBESTORE_MAX_QUEUED_QUERY_PLANS check out:

Doc claim	Source
auto default, sized max(4, 2 × cores)	rust/cubestore/cubestore/src/config/mod.rs:1402-1407, 1411-1430
0 disables the concurrency limit	queryplanner/planning_throttle.rs:35-43
Queue default 5000, full queue rejects	config/mod.rs:1822, planning_throttle.rs:98-106
Planning runs before the result cache	queryplanner/mod.rs:148 — throttle.acquire() is the first statement of logical_plan, ahead of the SqlResultCache

The chassis runtime and the two Fireworks model ids are not verifiable here — no chassis, Fireworks, kimi or glm reference exists anywhere in this repo, so that registry is in cubedevinc/cubejs-enterprise. Same for the CSPS/GCS error-detail claim in gcp.mdx. Flagged for author confirmation rather than treated as wrong.

Findings posted

#	Location	Concern
1	environment-variables.mdx:2242-2247	Queue limit is inert when CUBESTORE_MAX_CONCURRENT_QUERY_PLANS=0; doc presents the two as independent
2	admin/ai/index.mdx:96-98	kimi_k3 / glm_5_3 and chassis unverifiable from this repo — confirm against the enterprise registry
3	admin/deployment/oidc/gcp.mdx:412-416	New paragraph is written as a change-from-past-behaviour instead of guidance

Not posted (re-affirmed prior threads)

Two findings were duplicates of still-open threads from an earlier round, so no new comment:

• PRRT_kwDOCOH19M6j7bDg — CUBESTORE_MAX_CONCURRENT_QUERY_PLANS doesn't mention that a query without a slot waits up to CUBESTORE_QUERY_TIMEOUT and is then rejected with an error naming this very variable (planning_throttle.rs:84-91, budget wired at queryplanner/mod.rs:296). Still live.
• PRRT_kwDOCOH19M6j7bHJ — the two sections sit after CUBESTORE_QUERY_TIMEOUT (:2220), breaking the file's alphabetical ordering; natural home is beside CUBESTORE_MAX_WS_CONNECTIONS_PER_USER (:2109). Still live.

Review threads

The listing returned 3 of my own threads. 0 resolved — all three concerns are still live in the working tree. 2 re-affirmed as duplicates of findings this round (above); the third (PRRT_kwDOCOH19M6j7bJ0, table separator width and 2 x cores typography at :2237) remains open on its own and wasn't re-raised.

No tests or lint were run — the change is three .mdx files with no build step of its own. The Mintlify preview build in the PR comments is green.

· branch `claude/gallant-ramanujan-v78ks1`

[claude]

The queue limit is presented as independent of the concurrency limit, but CUBESTORE_MAX_CONCURRENT_QUERY_PLANS=0 makes it entirely inert. PlanningThrottle::new stores permits: None when max_concurrent == 0 (rust/cubestore/cubestore/src/queryplanner/planning_throttle.rs:35-43), and acquire then returns Ok(None) before any queue accounting happens (planning_throttle.rs:52-55) — max_queued is never consulted.

So someone who sets CUBESTORE_MAX_CONCURRENT_QUERY_PLANS=0 and leaves CUBESTORE_MAX_QUEUED_QUERY_PLANS=5000 gets no queue cap at all, not a 5000-deep queue. Worth one clause: "Has no effect when CUBESTORE_MAX_CONCURRENT_QUERY_PLANS is 0, since queries are never queued."

[claude]

These two ids can't be verified from this repo — grep -rni chassis and a search for Fireworks/kimi/glm across the whole tree hit only this file, so the predefined-model registry lives in the enterprise repo. kimi_k3 and glm_5_3 are one character away from plausible neighbours (kimi_k2, glm_4_x), and a wrong id here fails at config-validation time for the user with no way to discover the right one from the docs.

Please confirm both strings against the enterprise model registry before merge (same for the chassis value of runtime at line 119). Quoting the registry constant in the PR description would make this checkable on the next round.

[claude]

Phrased as a diff from previous behaviour ("reports the underlying GCS error ... instead of a generic internal error") rather than as guidance. A reader arriving at this page today has no memory of the generic error, so the contrast carries no information, and in six months the sentence is just stale narration.

The actionable content is one clause — that the CSPS-on-GCS test surfaces the raw GCS status, gRPC code and message, so a permission or principal error can be read straight off the failure. That also fits the If the test fails: table right below as an extra row rather than a standalone paragraph above it.