Runs

A Run is one piece of work Budi does for a User. There are five kinds. A User has one Run at a time.

Kind	Started by	What it does
Workspace setup	the api, after the Intake	Turns a Pro or Max User’s CV and Intake into a ready Workspace. See How provisioning works.
Job search	`POST /v1/discovery-runs`	Checks the User’s Job boards and records the new Listings. Uses no model tokens.
Evaluation	`POST /v1/evaluations`	Scores up to 10 Listings against the User’s Profile: a score out of 5, the reasons and the gaps.
Tailoring	`POST /v1/tailored-resumes`	Turns the Listing into an Opportunity and writes a Tailored CV for it, kept as a PDF in R2.
Managed submission	`POST /v1/managed-submissions`	Fills and sends the Application on the employer’s form. See Managed submission.

Each endpoint replies 202 with the Run. A refused start says why:

Reply	Error	Meaning
`409`	`run_in_progress`	Another Run is active. Wait for it.
`409`	`workspace_not_ready`	The Workspace is still being set up.
`409`	`evaluation_required`, `tailored_resume_required`, `already_applied`	The previous Step is missing, or the User already applied.
`403`	`pro_required`	The Step needs Pro or Max.
`403`	`consent_required`	The User has not accepted the current privacy notice.
`403`	`account_closed`	The account is closed.

A Run never starts the next one: the User picks the job when they tailor and when they apply.

Read the state with GET /v1/runs, GET /v1/runs/:id, GET /v1/listings, GET /v1/evaluations/:id, GET /v1/opportunities and GET /v1/opportunities/:id. GET /v1/me tells the web where the User stands between sign-up and a ready Workspace.

Inside a Run

Figure 2. One Run. Time goes down. Dashed arrows are replies. The session exists only during the Run.

The web sends the request with the User’s Privy identity token.
The api checks the token, the Plan and that no other Run is active. It records the Run as queued and replies 202.
The api starts a fresh Tenki session from the pinned image and mounts the User’s Volume at /workspace/data.
The api writes the Run’s inputs to the session’s own disk and starts Claude Code, headless and detached, in the User’s career-ops copy, with one prompt for this kind of Run.
Claude Code calls the model, does the work with career-ops and writes its verdict to result.json.
The api checks for the exit file every 10 seconds. When Claude Code is done, the api reads the result and copies any files the web shows (a Tailored CV, a Proof) to R2.
The api writes the outcome and the cost to Postgres and closes the session. The Volume stays.

A Free User has no Volume: their Job search runs in a throwaway session on the image’s own career-ops copy, with the title filter set from the Intake’s target roles.

Run states

State	Shown to the User as	Meaning
`queued`	En espera	Recorded, not started yet.
`running`	En curso	The session is working.
`succeeded`	Listo	Done.
`needs_human`	Te necesita	Only the User can unblock it. The reason says why.
`failed`	Falló	A Budi-side problem.

A Run that stops for the User has one reason: cv_unreadable or profile_incomplete (Workspace setup), or auth_required, bot_check, unsupported_ats, needs_candidate_input, posting_closed, duplicate_application or form_error (Managed submission). Failures before any work starts (Tenki not ready, the Volume still busy) are retried, up to 3 attempts. Once Claude Code has started, a failure is not retried.

Limits

Each Claude Code call has a dollar cap, on top of the model key’s own spend limit, and a time limit.

Kind	Dollar cap	Time limit
Workspace setup	$2	20 minutes
Job search	no model calls	10 minutes
Evaluation	$1.50 for each Listing	8 minutes for each Listing, 80 at most
Tailoring	$2	15 minutes
Managed submission	$4	25 minutes

The caps stop a runaway, not a normal Run. Measured on live Runs: a Workspace setup took 67 seconds and $0.23 (2026-10-17); a 10-Listing Evaluation cost about $0.15 for each Listing (2026-10-18). The web shows each Run’s cost in Activity.