What the agent does
In a project like dbt-labs/jaffle-shop, the dependencies live in three places and none of them pins dbt itself. dbt_project.yml says require-dbt-version: ">=2.0.0". packages.yml asks for dbt-labs/dbt_utils 1.4.1 from the hub and dbt-audit-helper from git at revision: main, and package-lock.yml has frozen that to commit 71817f0a7fa3df9f63adb90db0cf28f7423f720b. requirements.txt, compiled by uv from requirements.in, holds pre-commit, requests and jafgen but no dbt; Taskfile.yml installs it separately with an unpinned python3 -m pip install dbt. The agent reads all of this before choosing versions, because a dbt core release and a package release have to agree on require-dbt-version ranges.
The project's CI runs dbt Cloud jobs against Snowflake, BigQuery and Postgres, which a pull request from outside cannot use. So the agent builds the project on DuckDB in its own sandbox: it installs dbt with the DuckDB adapter at a pinned version, writes a profiles.yml in the run's working directory (not committed) that points the default profile at a local DuckDB file, and loads the CSVs in seeds/jaffle-data with dbt seed --vars '{"load_source_data": true}', since dbt_project.yml enables those seeds only when that variable is set.
With a baseline build passing on the current versions, it bumps one thing at a time: dbt_utils to its latest release, audit_helper to a tagged release instead of main, then dbt core and the adapter. After each it runs dbt deps to rewrite package-lock.yml and dbt build, which runs every model, seed and test, including the dbt_utils.expression_is_true tests in models/staging/stg_orders.yml, models/marts/orders.yml and models/marts/customers.yml and the dbt_utils.generate_surrogate_key call in stg_supplies.sql.
macros/cents_to_dollars.sql dispatches to postgres, bigquery and fabric versions and a default__ version that casts to numeric(16, 2). DuckDB uses the default, so a build that passes on DuckDB proves the default path and nothing about the warehouse-specific ones. The agent says so in the pull request instead of implying all three warehouses were tested.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Upgrade dbt, its adapter and the packages in packages.yml to the latest compatible versions. Pin dbt and the adapter in requirements.in and regenerate requirements.txt with uv, move audit_helper from revision main to a tagged release, and run dbt deps so package-lock.yml matches. Prove each bump on DuckDB in the sandbox: a profiles.yml you do not commit, dbt seed with load_source_data true, then dbt build. Get a passing baseline on current versions first. Leave out any upgrade that breaks the build or tests and say why. Open a pull request with one line per bump, and state which warehouse-specific macros DuckDB did not exercise.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The pull request changes packages.yml, package-lock.yml, requirements.in and requirements.txt, and nothing in models/ unless a package upgrade renamed a macro the models call. Its description lists each bump with old and new versions, the dbt build result on DuckDB for the baseline and after each bump, and a short note on what DuckDB could not prove: the postgres, bigquery and fabric branches of cents_to_dollars and anything else that dispatches by adapter.
A reviewer checks the dbt core version against require-dbt-version in dbt_project.yml and in each package, reads the dbt build summary in the transcript, and then lets the project's own dbt Cloud CI jobs run the merged change against the real warehouses. The run reduces what those jobs have to catch; it does not replace them.
Run it on every first Monday of the month
dbt core and hub packages release often enough that a monthly pass keeps each upgrade small. Have your scheduler send the same POST /o/{org}/sessions body on that day, with an Idempotency-Key that includes the month, and set a webhook URL on the key so a run.completed event links your team to the session and its pull request.
If you maintain several dbt projects, send one run per repository; each brings its own DuckDB build and its own pull request.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
Testing a dbt upgrade usually means a warehouse connection and a dev schema someone pays for. A DuckDB build in the run's own sandbox needs neither: it seeds the sample data, runs every model and test, and keeps the output of each dbt command in the session's transcript, so a reviewer sees which bump moved which test.
The work is mostly reading: which versions a package's require-dbt-version allows, what a dbt_utils release renamed, whether a git package has a tag to pin. An agent does that reading in the sandbox and comes back with a pull request whose description already answers the questions a reviewer would ask.
Frequently asked questions
My project runs on Snowflake. Is a DuckDB build enough?
It proves that the models compile and run, that tests pass on the seeded data, and that packages resolve. It does not prove warehouse-specific SQL, such as an adapter.dispatch branch for Snowflake. The pull request lists those gaps, and your existing warehouse CI covers them after it opens.
Will it commit a profiles.yml?
No. It writes one in the sandbox for the DuckDB build and leaves it out of the diff, so your real profile and credentials are untouched.
What does it do with a git package pinned to main?
It moves it to the newest tagged release that supports your dbt version, and package-lock.yml records the commit. If the repository has no suitable tag, it keeps the locked commit and says why.
Will it upgrade dbt across a major version?
Only if the packages and your require-dbt-version allow it and the DuckDB build passes. A major with breaking changes to the models is left out, with the dbt error, so you can plan it separately.