What Solver does in a run

Solver is the part of Millwork that runs your task. The API and dashboard use that name. When your application sends a task and its limits, Millwork keeps the saved models that fit those limits, picks one, runs it, and checks the output. A completed live run has a result, the model output. Every run that ends leaves a receipt of what happened. A saved model is a model your organization added from its catalog; the API calls it an arm. A run is one submitted task; the API calls it an execution. Every live run, one submitted to call a model, has a platform fee, charged when Millwork accepts the run. Model usage is billed separately. See Model access and billing.

What happens in one run

Step	What happens	What you can read afterwards
Keep the models that fit	Millwork keeps the saved models that are ready and allowed for the kind of data you declared. Every other saved model is left out of this run.	The receipt lists the models it kept (`eligible`) and the ones it left out, each with a reason (`rejected`).
Pick one	Millwork picks one of the kept models, preferring cheaper models as strongly as you asked (`cost_coefficient`, from 0 to 1).	The chosen model (`selected_arm`) in the receipt.
Run it	Millwork calls the provider for that model and follows the run to a final status, checking recorded spend before any further call (how the budget works).	The run’s status and its events.
Check the output	A basic check confirms only that output is present. It does not judge quality. Your own check can be stricter; see Connect an output check.	The check outcome in the receipt.
Respond to a failed check	Millwork follows your `on_eval` settings: try another saved model or propose a repair to a saved skill. If you allow neither, it does nothing more.	The response taken and its outcome in the receipt.
Read the records	A completed live run has a result with the model output. Every run that ends has a receipt with its outcome, model selection, recorded usage, and checks. It never holds your prompt or output.	`GET /v1/executions/{executionId}/result` for completed live runs; `GET /v1/receipts/{executionId}` for every final status.

A skill is a versioned procedure you saved as an option. A proposed repair changes it only after someone in your organization approves the change. A completed live run on a catalog model also records the requested and provider-reported models, provider, and connection. See the details available for each kind of saved model in Results and receipts.

Where the models come from

You can make models available in two ways. Both use the same run API, and the receipt records which one each run used.

How you use the model	What you set up	Who bills model usage
Your provider key	Connect your provider account once in a secure setup step, then add its models from your catalog.	Your provider, under your account’s terms. You pay Millwork the platform fee only.
A model Millwork provides	Add it from your catalog when it appears there. No provider account is needed.	Millwork, together with the platform fee. See Model access and billing.

The receipt says who paid. Who pays for model usage is fixed by the saved model that answers, and the receipt names it. When several saved models fit, Millwork may pick any of them; to keep a run on one saved model, pin it with routing.required_arm_id. Millwork never reveals your provider key. You can also save an agent endpoint or a reusable skill as an option. The same steps, limits, and receipt apply.

What stays in your control

You decide what a good result means for your product. Millwork does not judge that.
You choose whether model usage is billed through your provider account or Millwork.
The basic output check confirms only that output is present. Your own check (the API calls it a verifier, verifier_id) can be stricter.
A proposed skill repair changes nothing until someone in your organization approves it. Millwork does not apply it on its own.

Follow one run in detail

See each request, status, and record in order.

Start here

Understand Solver

Principles and scope

What Solver does in a run

What happens in one run

Where the models come from

What stays in your control

Follow one run in detail

​What happens in one run

​Where the models come from

​What stays in your control

Follow one run in detail

What happens in one run

Where the models come from

What stays in your control