Let your agentbuild your analytics.

Dex is an open-source, agent-native analytics engine that lets Claude Code and other coding agents build your analytics. It explores your data, whether it lives in a data warehouse, a lakehouse, or a database; authors dbt models and semantic layers; and detects schema, volume, grain, and semantic drift. Your repository is the source of truth and every change is a reviewable diff.

In Claude Code, run the commands one at a time: /plugin marketplace add exmergo/exmergo-agent-plugins, then /plugin install dex@exmergo. The skills appear as /dex:explore, /dex:transform, and /dex:maintain. For other agents such as Codex, Gemini CLI, and Cursor, run npx skills add exmergo/dex.

Dex connects to data warehouses, lakehouses, databases, and SQL engines: BigQuery, Snowflake, Databricks, Redshift, ClickHouse (both ClickHouse Cloud and self-hosted), PostgreSQL, Trino, and DuckDB. Every connector has a cost guard in its own billing unit: bytes scanned on BigQuery, compute time on Snowflake, DBUs on Databricks, RPU-hours on Redshift, compute seconds on ClickHouse, a load limit on PostgreSQL, and cluster-seconds on Trino. DuckDB is the zero-credential on-ramp: point Dex at a local file and nothing else is needed.

Yes, natively. Apache Ossie (incubating) is the vendor-neutral standard for exchanging semantic metadata, and Dex reads it as a first-class semantic layer. Install the extra with pip install 'exmergo-dex-core[ossie]', set semantic.vendor: ossie in .dex/config.yml, and list your .ossie.yaml, .ossie.yml, or .ossie.json documents under semantic.ossie.files. Dex reads the datasets, fields, relationships, and metrics they declare into the same catalog /dex:explore has always returned, authors documents as reviewable diffs, and detects drift against them.

Yes, natively. SLayer by Motley keeps a semantic layer as YAML model files, and Dex reads it as a first-class semantic layer. Install the extra with pip install 'exmergo-dex-core[slayer]', set semantic.vendor: slayer in .dex/config.yml, point semantic.slayer.base_dir at SLayer's storage root, and list your model files under semantic.slayer.models. Dex validates every file with SLayer's own model class from one pinned release, authors models as reviewable diffs, and detects drift against them. For a governed query, SLayer renders the SQL as a dry run and Dex runs it under its own cost guard and PII gate, so SLayer never opens a warehouse connection.

Yes, natively, each in its own format with no conversion. Cube cubes and views, Snowflake Semantic Views, and Databricks Metric Views are read from the YAML files in your repository: install exmergo-dex-core[cube], exmergo-dex-core[semantic-views], or exmergo-dex-core[metric-views], set semantic.vendor to cube, snowflake, or databricks in .dex/config.yml, and list the files under semantic.cube.files, semantic.snowflake.files, or semantic.databricks.files. Dex validates every file against its port of the vendor's rules, authors files as reviewable diffs, derives a cube, logical table, or Metric View from a declared dbt mart, and detects drift against the warehouse. It never deploys a Semantic View or Metric View for you. On Cube, a governed query is rendered by your Cube server and run by Dex under its own cost guard and PII gate.

No. Dex reads Apache Ossie documents, SLayer and Cube model files, Snowflake Semantic Views, and Databricks Metric Views natively, so a repository with no dbt project and no MetricFlow anywhere in the path still gets a governed semantic layer: set semantic.vendor to ossie, slayer, cube, snowflake, or databricks in .dex/config.yml and Dex explores, authors, and drift-checks against those files. A repository that keeps dbt for its models and declares its semantics in one of those formats beside them gets both.

Through semantic ossie define, update, and plan, applied with transform apply like every other Dex change. Each prospective document is validated against a content-pinned copy of the Ossie JSON Schema and then against Dex's own integrity rules, unique names, resolvable relationship endpoints, and matching key arity, before a plan is stored. Writes are confined to the exact paths in semantic.ossie.files, applied edits are byte-for-byte so your comments, quoting, and ordering survive, and a file that changed after planning refuses the whole edit.

Yes. Dex is read-only against your data and writes only reviewable diffs to your repo. Understanding is built from SQL aggregates, not raw rows, so credentials and raw data never enter the model context. Every scan is estimated with a dry-run and confirmed before it spends, capped by a per-connector cost guard.

Dex is free and open source under Apache 2.0, including the full Explore, Transform, Maintain loop with manual drift detection. Dex Enterprise is the harness that runs that loop for a whole team, deployed on your infrastructure: it scopes analytics goals, builds dbt changes from tickets, and fixes drift on a schedule, in your own CI, with every change opened as a draft pull request.

Agentic analytics is billed twice: the data platform charges for every scan, and the model charges for every token. Dex forces the agent to clear a cost guard before it runs an exploration query or a transformation, and it routes the agent through tight control scripts on /dex:explore, /dex:transform, and /dex:maintain rather than letting it dump schemas into context. On dbt Labs' ADE-bench, Dex with Claude Sonnet 5.5 resolves 80% of tasks, and in the July model sweep Dex with Claude Sonnet 5 outscored the same loop on Claude Fable 5 for about 2.5x less. On Snowflake's data-eng-bench, Dex with Claude Sonnet 5 is the top published Sonnet 5 result at 57.3% and used 32% fewer tokens per trial than the identical harness on Snowflake's own published board.