altimate-code: a deterministic tool layer for dbt and warehouse work, wrapped around an LLM
Open-source agentic data engineering harness for dbt, SQL, and cloud warehouses. 100+ tools, 10 warehouses, AI-powered.
At a glance
- What is it?
- AltimateAI's altimate-code is an MIT-licensed fork of OpenCode that adds 100+ data engineering tools for SQL analysis, column-level lineage, dbt manifests, FinOps and PII detection. The judgement: the tooling is the product, the model is swappable, and the free default provider logs your requests.
- Who is it for?
- Adopt altimate-code if you already run dbt or SQL against Snowflake, BigQuery, Databricks or Redshift and you want deterministic analysis rather than an LLM guessing at schema. Do not adopt it if your SQL is mostly ad-hoc against a warehouse you cannot connect to from a terminal, or if you cannot send query text to any external provider.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap altimate-code is aimed at: agents that edit SQL without knowing your schema
A general coding agent can open a .sql file and rewrite it. What it cannot do, per the README's own framing, is understand the data stack around that file. The comparison table in the repository puts it bluntly: general coding agents score "None" on SQL anti-pattern detection, column-level lineage, schema-aware autocomplete, cross-dialect translation, FinOps analysis and PII detection. altimate-code exists to fill those six rows.
The intended user is a data or analytics engineer who already has a dbt project and a cloud warehouse, and who wants an agent to reason about models, tests, lineage and cost without inventing column names. The README describes the project as "the data engineering tool layer" and positions it as complementary to Claude Code or Codex rather than a replacement. You can run it standalone in a terminal, mount it underneath another agent, or call it from CI and orchestration DAGs. That three-way positioning is the most interesting design decision in the project, and it is also the source of most of its complexity.
How the harness is put together: a fork of OpenCode plus a deterministic tool layer
altimate-code is a fork of OpenCode, rebuilt for data teams, written in TypeScript and distributed as a CLI. The architecture that emerges from the README is a split between an agent runtime (inherited from OpenCode, model-agnostic, able to run against Anthropic, OpenAI or a local Ollama instance) and a set of tools the runtime can call.
The tools are the part that matters. The README describes the SQL Intelligence Engine as "deterministic SQL parsing and analysis (not LLM pattern matching)" with 19 rules. Column-level lineage is described as automatic extraction from SQL across dialects. Warehouse intelligence comes from indexed schemas, query history and cost data pulled from the actual warehouse. PII detection is described as 30+ regex patterns across 15 categories, enforced pre-execution, which means the check runs before a query is sent rather than after results come back.
That split is the whole argument for the project. The LLM decides what to ask; the tools decide what is true. A lineage edge is computed from parsed SQL, not generated as prose. The repository claims 100 percent F1 on anti-pattern detection across 1,077 queries and 19 rules with zero false positives, and 100 percent edge-match on lineage across 500 queries in 13 categories, with a methodology file at experiments/BENCHMARKS.md. Those numbers come from the project's own benchmark, not from independent replication, and the README does not describe who ran them.
Installing it: two binaries, three platforms, and one required provider step
There are two install paths and they do not produce the same command names. The npm route is `npm install -g altimate-code`, which exposes both `altimate` and `altimate-code` on PATH. The curl route on macOS and Linux is `curl -fsSL https://www.altimate.sh/install | bash`, which installs a self-contained binary to `~/.altimate/bin` and exposes only `altimate`. Windows gets the same self-contained binary via PowerShell, landing in `%USERPROFILE%\.altimate\bin`, with no Node required.
The platform caveats are stated in the README and are worth repeating because they are easy to hit. Alpine Linux on musl is not supported by the standalone binary; the suggested workaround is `apk add gcompat`. Windows on ARM64 is also unsupported by the standalone binary, with WSL suggested instead.
After install, nothing works until a provider is configured. You launch the TUI with `altimate` and run `/connect`, or you set `ANTHROPIC_API_KEY` or `OPENAI_API_KEY` directly in the environment. The README describes Altimate Base as the free, no-signup option, and then states the trade-off in plain terms: it is rate limited, and its requests and responses are logged and may be used to improve Altimate products and services. The setup dialog shows that disclosure and defaults to No before registering. That default is the right call, and it is the single most important thing to read before clicking through.
The optional second step is `altimate /discover`, described as read-only and safe for production connections. It auto-detects dbt projects, warehouse connections and installed tools. For warehouse credentials it checks `DBT_PROFILES_DIR`, then the project directory, then `<home>/.dbt/`, plus Docker and environment variables. If you run headless, `altimate --yolo` auto-approves every permission prompt, and the README explicitly does not recommend it against live warehouse connections. Take that warning at face value.
Where it breaks down: warehouse access, benchmark provenance and review scope
The sharpest limitation is structural. Almost everything that makes altimate-code more than a SQL linter depends on reaching a live warehouse: schema indexing, query history, cost data, credit consumption, warehouse right-sizing. Without a connection, you are left with the parsing tools, which are useful but not the pitch. Teams whose warehouses sit behind a bastion host, a VPN with no CLI path, or a policy that forbids query text leaving the network will find the interesting half of the tool unavailable. The local Ollama option addresses which model sees your data, not whether the harness can reach Snowflake.
The benchmark numbers need the same skepticism. "100% F1" and "0 false positives" are strong claims, and the README links to a methodology document rather than to a third-party evaluation. A benchmark built by the maintainers, on queries chosen by the maintainers, against rules written by the maintainers, is a reasonable internal check and a weak external one. Treat those figures as a statement of intent about the rule set, not as a measurement of your SQL.
The third limitation is scope. The README's feature list includes a GitHub App for interactive agent tasks and a deterministic GitHub Action for automatic dbt pull-request reviews, with public demo PRs linked at AltimateAI/dbt-pr-review-demo. Those are separate installs with separate permissions, and the README itself suggests looking at the demo PRs before installing the Action in your own repository. Nothing in the supplied material describes what the Action posts, how it handles a failing review, or how to turn it off per repository. If PR review is your reason for looking at this project, that gap is the first thing to close.
The honest alternative: Claude Code with a SQL linter bolted on
The obvious comparison is a general coding agent such as Claude Code or Codex, and the README makes the comparison itself. The difference is not intelligence, it is grounding. A general agent reads your files and reasons about them; it has no parser for 19 named anti-pattern rules, no lineage extractor, and no path to your warehouse's query history. When it tells you a join is inefficient, that is a language-model judgement. When altimate-code flags an anti-pattern, the README says a rule fired.
The trade is real in both directions. A general agent works on any repository with no warehouse connection, no profiles.yml, and no provider registration beyond the one you already have. It also has no opinion about your data stack, which means no false confidence either. If your work is mostly application code with occasional SQL, the harness is overhead. If your work is dbt models, warehouse cost, and lineage across dialects, the deterministic layer is the reason to switch.
A narrower alternative is to keep the general agent and add a standalone linter such as sqlfluff, which `/discover` detects as an installed tool. That gets you style and some correctness checks without the harness, but it does not get you lineage, FinOps or PII enforcement, and it does not give the agent a structured way to call those checks.
Maintenance, releases and what the MIT licence actually buys you
The repository is active and not archived, with a last push in September 2026 and a release cadence visible in the supplied material: v0.11.0-beta.5, then v0.11.0, then v0.11.1 within roughly two days. That is a fast cycle, and beta tags appearing in the same window as stable tags suggests the project ships incrementally rather than batching. Plan for version churn in CI, and pin a version rather than tracking latest if you wire the binary into a pipeline.
The licence is MIT. That permits commercial use, modification and redistribution with the copyright notice preserved. It does not give you support, a compatibility guarantee, or any claim on the hosted Altimate Base service, which is a separate offering governed by its own terms and its own logging disclosure. The MIT grant covers the code in the repository, not the endpoint the free provider talks to.
Maintenance cost has two parts. The binary itself is a single self-contained executable on the curl and PowerShell paths, so upgrading is a reinstall rather than a dependency graph to untangle. The harder cost is configuration drift: `profiles.yml` resolution walks `DBT_PROFILES_DIR`, then the project directory, then `<home>/.dbt/`, and any of those can point at a different warehouse than the one you meant. Re-run `altimate /discover` after changing dbt profile locations, and check which credentials it resolved before trusting a cost report.
Who should install it, and the two commands to run first
Install it if you have a dbt project and a cloud warehouse you can reach from a terminal, and you want an agent that grounds its SQL advice in parsed rules and real metadata rather than in plausible-sounding prose. The `/discover` step is read-only and reversible, which makes the trial cheap. Run `altimate /discover` first and read the detected connections, then run a single `/sql-translate` or anti-pattern analysis against a query you already understand. If the output matches what you know to be true about that query, the tool layer is doing its job.
Skip it if your SQL work is ad-hoc, if your warehouse is unreachable from the machine running the CLI, or if sending query text to a third-party provider is not something your team can approve. The Altimate Base default is free and rate limited, and its terms say requests and responses are logged and may be used to improve Altimate products. That is a disclosure you can accept or decline, but you cannot configure your way around it while still using the free tier. Bring your own key or run Ollama locally if that matters.
Before rolling it into a shared repository, verify three things: which warehouse `/discover` resolved from your `profiles.yml`, what the GitHub Action posts on a pull request (the demo PRs at AltimateAI/dbt-pr-review-demo are the only evidence supplied), and whether your CI pins a version. The MIT licence means nobody owes you a migration path when v0.12 changes a config key.
Editorial conclusion
Adopt altimate-code if you already run dbt or SQL against Snowflake, BigQuery, Databricks or Redshift and you want deterministic analysis rather than an LLM guessing at schema. Do not adopt it if your SQL is mostly ad-hoc against a warehouse you cannot connect to from a terminal, or if you cannot send query text to any external provider. Before installing, read the Altimate Base disclosure in the /connect dialog and verify what /discover reads from DBT_PROFILES_DIR and your profiles.yml, because that is the file that decides which warehouse credentials the harness can reach.
Community notes