What the agent does
The agent reads the Python project before choosing an upgrade command. In fastapi/full-stack-fastapi-template, backend/pyproject.toml requires Python >=3.14,<4.0 and declares FastAPI, SQLModel, Alembic, psycopg and Pydantic together. The development group includes pytest and coverage. The lockfile is uv.lock at the repository root, not a separate backend lockfile. The agent checks that workspace layout and the existing environment before running uv lock --upgrade, so it updates the dependency graph the project actually installs.
Database preparation is part of this job. compose.yml defines a postgres:18 service and supplies the backend a DATABASE_URL, while backend/tests/conftest.py imports the application's real engine and creates a SQLModel Session. Its session fixture initializes the database and deletes Item and User records during cleanup. The agent points those settings at a disposable PostgreSQL database inside the sandbox, never a shared or production database. It follows .github/workflows/test-backend.yml for database and Mailpit readiness and the uv run bash scripts/prestart.sh migration step before interpreting pytest output as an upgrade result.
It establishes a baseline with uv run pytest from backend, then resolves the proposed dependency versions and installs the updated environment. The existing backend/scripts/test.sh runs FASTAPI_ENV=development coverage run -m pytest tests/ and produces coverage reports. The agent follows that environment convention where needed and records the exact invocation. It checks both dependency installation and the API tests, because a successful lock operation alone cannot show whether SQLModel queries, password handling or request validation still work.
If the broad upgrade fails, the agent narrows the candidate set and identifies the incompatible dependency group. It retains only a final combination that passes the agreed checks, keeping pyproject.toml and uv.lock consistent. It does not replace PostgreSQL with an in-memory database to hide a driver problem, raise version ceilings without permission or update the React frontend as collateral work. Each deferred bump receives the command and failure that prevented its inclusion.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Upgrade this FastAPI app's Python dependencies with uv lock --upgrade while preserving existing compatibility constraints. Inspect backend/pyproject.toml, the root uv.lock, existing test scripts and database configuration. Start a disposable PostgreSQL database in the sandbox, install the baseline and run uv run pytest from backend with the required test environment. Update and sync the dependencies, then run the tests again against PostgreSQL. Leave out dependency groups that introduce failures and explain why. Do not touch production data, weaken tests or upgrade the frontend. Open a pull request with one line per retained package bump, exact check output and deferred upgrades.",
"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 returned pull request contains the proposed uv.lock changes and any justified edits to the backend manifest. Its summary names the Python runtime, the database used for testing, the commands attempted and the dependency versions kept. Deferred packages appear separately with a concrete compatibility or test failure. If PostgreSQL setup prevents the suite from running, the result says so rather than presenting dependency resolution as application verification.
A reviewer checks the final dependency graph, especially related changes across FastAPI, Pydantic, SQLModel and psycopg. They confirm that the reported pytest invocation exercised the backend with its real database engine and that no production credentials or local environment files enter the diff. The session transcript retains the install and test output, while existing pull request checks remain the place to verify the branch in CI.
Run it on every weekly Python dependency check
Run a weekly scheduler that posts this request with your API key and your connected repository resource. The scheduler owns the timing; the session request contains the task rather than a schedule field. Save the execution_id returned when the session starts, then read GET /o/{org}/sessions/{id} for the answer and PR. A completion webhook configured on the key can tell your service when to collect the result.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
A uv upgrade can require a different Python interpreter and a clean database before a failure becomes reproducible. Running it on Rush keeps the temporary environment and PostgreSQL state away from the developer's current virtual environment. The agent has room to test an incompatible candidate without leaving your laptop on a half-upgraded dependency set.
The API also makes dependency maintenance repeatable across repositories without pretending their environments are identical. Each session keeps its own commands and output. When one backend fails during database initialization and another fails during response validation, your review queue receives those different explanations with the proposed changes, rather than one generic update notification.
Frequently asked questions
Does the agent change pyproject.toml or just uv.lock?
The default task upgrades within the manifest's existing ranges and primarily changes the lockfile. A manifest edit must be explained rather than used to bypass a constraint. The agent checks that the updated lockfile still represents the backend project and its development dependencies.
Why start PostgreSQL for a dependency update?
The inspected template's test fixture uses the application engine and a real SQLModel session. Driver or ORM changes can therefore fail after installation has succeeded. A disposable PostgreSQL instance lets the agent exercise that path without sending test cleanup queries to a live application database.
Will it upgrade FastAPI and Pydantic independently?
Only when the dependency solver and tests allow that combination. Related packages may need to move together, and the report should describe those groups. The last check runs against the complete proposed lockfile rather than assuming separately passing candidates remain compatible together.
Can I run this on a backend with no frontend?
Yes, the work targets Python dependencies and backend checks. The full-stack template is a concrete example of the files and database setup the agent inspects, not a requirement to have React. Your repository's manifest, lockfile location and test commands determine the actual scope.