altimate-code: a fork whose root package.json still says opencode

The root manifest is still called opencode and refuses to publish

The package.json at the top of this repository carries three fields that belong to the project it was forked from:

"name": "opencode",
"description": "AI-powered development tool",
"private": true,

So the published npm package is `altimate-code`, installed globally, while the manifest that drives the build is named `opencode` and describes a general development tool. `"private": true` means this manifest is never the thing that reaches the registry; the distribution is assembled from the workspace packages under `packages/`. The fork relationship is stated openly in the README, which says altimate-code is a fork of OpenCode rebuilt for data teams and is model agnostic, so you can bring your own LLM or run locally with Ollama. What the manifest has not absorbed is the rename. The AWS SSO script is still wired to the upstream name:

"sso": "aws sso login --sso-session=opencode --no-browser"

For a tool whose main selling point is warehouse connectivity, the SSO session string is the kind of leftover that makes a fork's lineage visible in its own tooling.

npm test at the root exits 1 and tells you not to run it

One script exists purely to refuse work:

"test": "echo 'do not run tests from root' && exit 1"

Anyone who types `npm test` or the bun equivalent at the repository root gets a message and a non-zero exit rather than a test run. That is a defensible choice in a monorepo, where the meaningful suites live next to the fourteen workspace packages, but it means the conventional entry point is a dead end and the real one is undocumented at the root. What the root does expose is a linter and a type checker:

"lint": "oxlint",
"typecheck": "bun turbo typecheck",

The type checker runs through turbo, so it fans out across packages, and `bunfig.toml`, `turbo.json`, `tsconfig.json` and `.oxlintrc.json` at the root are the configuration for that fan out. A `postinstall` script also runs `bun run --cwd packages/core fix-node-pty`, meaning an install from a checkout executes a fix script against the core package rather than only unpacking it.

Three installers and two binary names for one tool

There are three ways in, and they do not leave you with the same thing. The npm route is:

npm install -g altimate-code

The macOS and Linux route pipes a script into a shell:

curl -fsSL https://www.altimate.sh/install | bash

which installs a single self-contained binary named `altimate` into `~/.altimate/bin`, and Windows has its own PowerShell form:

powershell -c "irm https://www.altimate.sh/install.ps1 | iex"

which targets `%USERPROFILE%\.altimate\bin` and needs no Node. The difference that matters is on your PATH. The npm install exposes both `altimate` and `altimate-code`, while the standalone install exposes only `altimate`, so a script written against one name breaks on the other. Two platforms are excluded from the standalone binary, Alpine Linux on musl and Windows on ARM64, with the workarounds given as `apk add gcompat` on Alpine and WSL on Windows on ARM. The installers themselves are in the repository as `install` and `install.ps1` at the root, so the curl one is inspectable before you pipe it anywhere.

The default provider registers itself with no dialog and logs the traffic

Step one of the setup is optional and its default is to send your work somewhere. The instructions say Altimate Base is used automatically if you skip provider selection, that a fresh install registers it automatically with no dialog to accept, and that the notice is printed once. What Altimate Base does is stated plainly: it is the free, no-signup option, it is rate limited, and its requests and responses are logged and may be used to improve Altimate products and services. The advice that follows is not to send secrets or confidential code. There are three documented ways out, and you need one of them before the first prompt:

altimate providers logout altimate-base

or set `ALTIMATE_BASE_AUTO_REGISTER=0`, or list `disabled_providers` in config. Bringing your own key is an environment variable instead, either `ANTHROPIC_API_KEY` or `OPENAI_API_KEY`. The tension worth naming is that the repository ships `.gitguardian.yaml` and `.gitleaksignore` at the root, so secret scanning is treated as a first class concern inside the codebase, while the out-of-the-box provider configuration is opt out rather than opt in.

/discover will find profiles.yml and your Docker credentials on the first run

Step two is described as read only and safe for production connections, and it is the step that goes looking for them. `/discover` auto-detects dbt projects, warehouse connections and installed tools, with `altimate /discover` as the command. The lookup order for the dbt profile file is specific: it checks `DBT_PROFILES_DIR`, then the project directory, then `<home>/.dbt/`, and it also looks at Docker and environment variables. It then reports installed tools including dbt, sqlfluff, airflow and dagster. Read only means it will not write to the warehouse. It does not mean it will not connect, or that it will not hand a model the contents of your connection profile, since a profile that resolves is exactly what makes lineage, cost and schema features work. If the machine running discovery is a laptop and the credential it finds belongs to production, that is the moment to decide whether you want it. The step is optional and the documentation says you can skip it and run it later.

Ten warehouses, twelve warehouses, and four named dialects

The warehouse count is stated three times and it is not the same number each time. The project description says 100+ tools, 10 warehouses. The capability table row for cross-dialect data validation promises a row-by-row diff across 12 warehouses with 5 algorithms. The row above it, for cross-dialect translation, names four platforms explicitly: Snowflake, BigQuery, Databricks and Redshift. Four, ten and twelve are all plausible for three different claims, translation coverage being narrower than validation coverage being plausible in principle. As written, though, a reader has no way to tell which number a given warehouse falls into, and the distinction between a dialect that can be translated into and a warehouse that can be diffed against is exactly the distinction that matters if you are planning a migration. The rest of the table is more concrete: PII detection covers 30+ regex patterns across 15 categories, SQL anti-pattern detection runs 19 rules with confidence scoring, and observability is local-first tracing of AI sessions and tool calls.

Benchmark numbers live in experiments/, results in benchmark/, and one number needs the fine print

The precision claims are specific and they point at a methodology file. SQL anti-pattern detection is reported at 100% F1 across 1,077 queries, 19 rules and 0 false positives, and column-level lineage at 100% edge-match across 500 queries and 13 categories, with a link to experiments/BENCHMARKS.md. The repository root separately carries a `benchmark/` directory alongside `perf/`, `research/`, `experiments/` and `test/`, so a reader looking for the numbers has two plausible places to look. A 100% score with 0 false positives is a claim worth asking about before you gate a pipeline on it, and the fine print is that the rule count is the same 19 that ships in the tool, which means the benchmark measures the shipped rules on a chosen query set rather than on queries the rules were not written for. The documentation itself makes that framing argument, saying the features are deterministic because they parse, trace and measure rather than relying on LLM pattern matching.

Fourteen workspace packages, three betas on one build number, and 311 open issues

The workspace list is where the data engineering focus actually lives. Alongside `cli`, `core`, `server`, `tui`, `plugin`, `llm`, `util`, `script` and `sdk/js` there are three packages that exist because of the fork's purpose: `dbt-tools`, `drivers` and `http-recorder`. Three catalog entries sit on the same beta build, `@effect/opentelemetry`, `@effect/platform-node` and `@effect/sql-sqlite-bun`, all at 4.0.0-beta.74, which means the persistence layer, the OpenTelemetry layer and the Node platform layer upgrade together or not at all. Three more are pinned in lockstep at 0.3.4 for `@opentui/core`, `@opentui/keymap` and `@opentui/solid`, and there is a dedicated `upgrade-opentui` script for moving them. The repository has 819 stars, 135 forks and 311 open issues, which is an issue queue several times the size of the fork count, on a default branch last pushed 2026-10-01 with three releases in the preceding week.

Editorial conclusion

altimate-code suits a data team that already has warehouse credentials in profiles.yml and wants the same deterministic checks in a terminal, in an agent and in CI. It does not suit a team that cannot have its SQL leaving the machine, because the default provider registers itself and logs requests and responses unless you opt out first. Check five things before wiring it into anything. Check `ALTIMATE_BASE_AUTO_REGISTER=0` or `disabled_providers` in config, because a fresh install registers Altimate Base with no dialog and prints the notice only once. Check whether you are on Alpine or Windows on ARM64, since the standalone binary does not cover musl or that architecture and the npm path is the fallback. Check which installer you used, because npm puts both `altimate` and `altimate-code` on PATH while the curl script puts only `altimate` there. Check whether your CI runs the root test script, which exits 1 by design. And check the warehouse count you were promised, since the documentation names 10, 12 and 4 in three different places. The licence is MIT and the default branch moved on 2026-10-01, with releases v0.12.2, v0.12.3 and v0.12.4 published inside the same week.

Frequently asked questions

Official sources

1. AltimateAI/altimate-code on GitHub
2. License: MIT
3. Project website
4. README
5. Releases