Cube Core
A governed semantic layer for consistent analytics across BI, embedded applications, and AI agents.
The workflow limits its default token to read-only contents and disables persisted checkout credentials; gateway tests cover JWT verification, rejection of missing or invalid tokens, scope gating, and secret rotation, giving concrete support for least privilege and sensitive-data controls. The README explains that data moves from sources through the semantic layer to SQL, REST, GraphQL, and downstream consumers, while the security policy provides a private reporting path. Deductions apply because no per-action end-user confirmation mechanism is shown, query/API effects, telemetry, and retention boundaries are not exhaustively documented, and no general undo or rollback procedure is provided. Version constraints, frozen-lockfile installation, and the FOSSA badge provide partial dependency controls, but no scan findings or remediation SLA are included. Repository, corporate author, and contacts establish internal attribution only; the publisher remains unverified and is treated as unknown.
The README, package metadata, CI, and tests consistently describe a semantic-layer and API-gateway product. Static tests cover authentication, caching, date parsing, HTTP failures, and migration warnings, while dependency installation uses Yarn constraints, resolutions, lockfile hashing, and retries. Deductions apply because the supplied evidence represents only part of a large multilingual monorepo, does not establish availability of every dependency, and provides neither actual run results nor a repository-wide runtime failure taxonomy or recovery policy.
The README thoroughly distinguishes self-hosted Cube Core from managed Cube and identifies BI, embedded analytics, custom applications, and AI agents as audiences. Its headless standard-API design, broad SQL-source categories, and Docker path establish useful boundaries and ordinary environment fit. Deductions apply because the claim of working with all SQL sources is not backed here by a detailed compatibility matrix, while setup evidence is mostly a local Docker example. This is not an autonomously triggered agent and the supplied files define no intent matching, invocation policy, or false-trigger controls, so trigger precision is absent.
The README has clear positioning, comparison, getting-started, resource, contribution, and licensing sections, plus a usable Docker command and documentation/example links. Cube Core versus commercial Cube is named and separated clearly. The root license establishes Apache-2.0 as the default with package-level MIT exceptions, fully justifying the license score. Deductions apply because complete configuration, production deployment, and upgrade notes are absent; FAQ and limitations are mostly delegated to external resources; no formal changelog or release policy is supplied; and the root 0.1.0 version does not describe all workspaces. Maintenance contacts exist, but there is no maintenance SLA or responsibility matrix and publisher identity remains unknown.
SQL, REST, and GraphQL interfaces produce outputs directly usable by BI tools, applications, and AI agents, while centralized metrics, dimensions, joins, and access rules offer clear reuse value. Caching, self-hosting, and define-once reuse support plausible efficiency gains. Deductions apply because latency, concurrency, universal compatibility, and economic benefits are predominantly README claims without benchmarks, capacity limits, resource requirements, or total-cost evidence in the supplied files.
Product claims can be traced across the README, package configuration, CI workflow, and concrete authentication, caching, and date-parser tests; security and licensing have dedicated files, providing moderate cross-file corroboration. Deductions apply because important performance and compatibility claims appear only in the README without implementation excerpts, benchmarks, or test reports, and the commercial-product statements lack independent corroboration within the supplied material. Facts and promotional inference are generally distinguishable, but no explicit claim-to-evidence index is provided.
- This is a low-confidence static assessment; no build, test, container, or dependency scan was executed.
- The repository is primarily a semantic layer consumed by AI agents, not an autonomous agent with confirmation and trigger policies; integrators must supply those controls.
- Before production use, verify data egress, telemetry, log redaction, retention, and query/write permission boundaries.
- Audit the complete lockfile, transitive vulnerabilities, and third-party GitHub Actions supply-chain exposure at the pinned revision.
- Validate the README's sub-second latency, high-concurrency, and broad source-compatibility claims with target-environment benchmarks and compatibility tests.
- The dual-license scheme varies by file or package; determine the exact license and notice obligations for every distributed component.
What does this agent do, and when should you use it?
Cube Core is an open-source, headless semantic layer for defining metrics, dimensions, joins, and access rules in code. It connects to SQL systems such as Snowflake, Databricks, BigQuery, Presto, Amazon Athena, and Postgres, then exposes the resulting model through SQL, REST, and GraphQL APIs. BI tools, custom applications, and AI agents can consume the same definitions instead of recreating business logic independently. A built-in relational caching engine targets sub-second latency and high concurrency for API requests. Cube Core can run locally or be self-hosted with Docker, but it does not provide an end-user interface; teams must build that experience or use the commercial Cube platform.
Users define metrics, dimensions, joins, and access rules in Cube Core code and mount the project directory at /cube/conf in the Docker container. Cube Core reads that model, queries connected SQL data sources, and returns governed analytical results through SQL, REST, and GraphQL APIs. Its built-in relational caching engine accelerates API requests and supports high concurrency. Visualization, chat, dashboards, and embedded user experiences remain the responsibility of downstream BI tools, custom applications, or AI agents because Cube Core itself is headless.
- A data team wants several BI tools to share one definition of business metrics and dimensions instead of maintaining separate models.
- A SaaS product team is building customer-facing embedded analytics and wants to own the interface while serving governed data through APIs.
- An AI application team needs analytical agents to consume defined metrics, joins, and access rules rather than interpret raw database schemas independently.
- A platform team wants to self-host a semantic layer that connects to SQL warehouses such as Snowflake, Databricks, or BigQuery.
- An API owner serving high-concurrency analytical workloads wants a built-in relational caching layer to reduce query latency.
What are this agent's strengths and limitations?
- One governed model can serve BI tools, embedded analytics, custom applications, and AI agents.
- SQL, REST, and GraphQL interfaces accommodate different downstream integration styles.
- Support spans multiple types of SQL systems, including cloud warehouses, query engines, and application databases.
- The built-in relational caching engine is specifically intended for sub-second latency and high-concurrency API traffic.
- Data models are described as compatible in both directions between Cube Core and the commercial Cube product.
- Cube Core is headless, so adopters must build or integrate dashboards, chat, and other end-user interfaces.
- The documented quick start depends on Docker, a mounted local configuration directory, and two exposed ports.
- The supplied setup material does not document data-source credential variables, API authentication, production hardening, or recovery procedures.
- The repository-level license is marked NOASSERTION; only the Cube Client MIT license and Cube Backend Apache 2.0 license are explicitly identified, requiring component-level review.
- RBAC, multi-tenancy, managed deployment, workbooks, and several office and BI integrations are presented as commercial Cube features rather than built-in Cube Core capabilities.
How do you install or deploy this agent?
Docker is required, along with a project directory that will hold Cube configuration. From that directory, run:
docker run -p 4000:4000 \
-p 15432:15432 \
-v ${PWD}:/cube/conf \
-e CUBEJS_DEV_MODE=true \
cubejs/cubeThis starts Cube Core in development mode, mounts the current directory at /cube/conf, and exposes ports 4000 and 15432. Open http://localhost:4000 to continue setup. The supplied material does not specify exact data-source credential names or production deployment settings.
How do you use this agent?
After starting the container, open http://localhost:4000 and follow the setup flow to connect a SQL data source and create a data model. Define metrics, dimensions, joins, and access rules in that model. Downstream consumers can then query the model through Cube Core's SQL, REST, or GraphQL APIs. Exact endpoint paths, request bodies, and authentication settings are not included in the supplied material. The example sets CUBEJS_DEV_MODE=true for local setup and should not be treated as documented production configuration.
How does this agent compare with similar options?
Compared with the commercial Cube product, Cube Core is the self-hosted, headless semantic-layer option for teams that want to own their stack and build their own BI, embedded analytics, or AI-agent experience. Cube uses the same underlying semantic layer but adds Analytics Chat, workbooks, dashboards, embedded analytics surfaces, managed deployment, RBAC, multi-tenancy, and integrations with Tableau, Power BI, Excel, and Google Sheets. Data models are stated to work unchanged in either product.