Check selected models with one task

Review GPT-6 Astra and Claude Opus 5.5 for a checkout incident.

These routes show Needs action. Prepare the review now; paid checks stay blocked until price and account requirements are resolved.

Connect provider
Add a model
Check models

If your account is already connected, open this guide’s Add a model tab. Open Check models to prepare the task and inspect the selected routes’ requirements.

Open provider setup

From Arms, choose Browse model catalog, then open Provider accounts > Connect a provider.

Provider accounts menu with Connect a provider selected. — Screenshot detail: Connect a provider, from Provider accounts in the catalog.

View full catalog screen

Model catalog with Astra and Opus listed and the Provider accounts menu open. — Start from Provider accounts in the current model catalog.

Name the connection

Set up the account you’ll use for both models. These field details are shown before Continue.Choose OpenRouter and keep the displayed authentication method.

Provider field fragment: OpenRouter. — Screenshot details: Provider and Authentication.

Authentication field fragment: API key. — Screenshot details: Provider and Authentication.

Use Support engineering so you can recognize this account later.

Connection-name field fragment: Support engineering. — Screenshot details: Connection name and Continue in the setup footer.

Native Continue button from the provider setup footer. — Screenshot details: Connection name and Continue in the setup footer.

Continue to private authorization. No paid model run starts.

View full provider setup screen

Complete Connect and test your provider form with OpenRouter and Support engineering; no authorization or connection test has been performed in this capture. — Choose the provider and name the connection before continuing.

Select Continue, then Authorize. Finish on the private provider page and return to Millwork; enter credentials only there. Use Check access, then View model catalog after Test and sync completes.Connecting approves no paid model run and does not establish that every model route is ready. If setup stops, continue your provider connection.

Inspect the account route

Expand GPT-6 Astra in Model catalog and choose Add arm. Repeat for Claude Opus 5.5. Confirm the model and account in the Add model arm sheet.

Match Model / release, Publisher, Source, and the intended Connection. Keep the exact connection and route identifiers.
Read Access route, its permission scope, and Last tested. Use Read an access route for every field, including Unknown, Not issued, data controls, and test history.
Read every requirement and its next actor. Follow Why is this route unavailable? for current labels and supported recovery. Permission, saving, testing, and paid-task approval remain separate.

Match the models and account. GPT-6 Astra and Claude Opus 5.5 should both use Support engineering.

View full model catalog

Model catalog showing OpenAI GPT-6 Astra and Anthropic Claude Opus 5.5 as observed routes through the same account. — Listed models still need their account routes reviewed.

A saved model is a configured model option Millwork can run. Read the route requirements even if the catalog shows ACTIVE or Eligible routes (1); those labels do not establish paid-check eligibility.If Temporary label (optional) is available, you can keep a local note for an account listing while reviewing it. This optional note does not make the route eligible or authorize the route or save a model.

Read the requirements

Both sheets show Needs action and a disabled Authorize route button. The current source cannot establish the complete pricing and spend bounds needed for these paid checks. Keep the routes at this requirement stage.

Resolve the requirements before authorizing. No permission or saved model has been created.

Disabled Authorize route control from the illustrative Astra requirement sheet. — Screenshot detail: Authorize route is disabled.

Requirement shown	Who needs to act
Route permission disabled	An authorized staff member must enable the source for the organization.
Route unavailable	The responsible owner must resolve the route’s blocking requirement.
Route identity requires review	The source maintainer must verify the exact route identity.
Pricing needs review	The source maintainer must resolve current rates and billing conditions.
Maximum request cost needs review	The source maintainer must establish the complete maximum provider charge for one request.
Data controls require review	The organization’s policy administrator must review the data controls.

This example shows a subset of requirements. Older screenshots can say Price information required; the current sheet separates pricing review from maximum request cost. Use the complete requirement and recovery reference for the exact current notices. Do not infer that one repair clears them all.

View full Astra requirements

Illustrative native Astra sheet showing Needs action, source requirements and disabled Authorize route. — Astra’s requirements and disabled authorization action.

View full Opus requirements

Native Opus sheet showing Needs action, source requirements and disabled Authorize route. — Opus has the same unresolved source requirements.

Inspect the lower route details

Scrolled Astra details with no deployment issued, spending not approved and no model test. — Astra’s illustrative lower route details retain the blocked state.

Scrolled Opus details with no deployment issued, spending not approved and no model test. — Opus’s illustrative lower route details retain the blocked state.

Only after requirements have actually been met can a route be authorized and registered through Add model arm > Add with defaults. Confirm Ready in Arms and return through Browse model catalog. Reuse a matching ready saved model if one exists. No saved model or permission is demonstrated for this pair.

You can select these routes and prepare a read-only review. They remain ineligible for paid checks, so there are no model responses or receipts to compare.

Prepare the incident task

Expand each intended model’s route in Model catalog. Select its checkbox in Actions, then choose Review selected models (2). Enter this brief in Task and choose Review requirements and costs. These preparation actions start no paid checks.

Copy the incident task

Assess this incident brief: After a 10:00 deployment, checkout errors rose from 0.3% to 8%. Only European traffic is affected. Latency and database CPU are unchanged. Rolling back one of three instances reduced errors on that instance; the others remain unchanged. Return: what we know; the leading hypothesis and one plausible alternative; three proposed next steps with the evidence each would provide; and an internal status update under 40 words. Separate facts from assumptions. Do not claim that the root cause or recovery is confirmed. Use only the information provided.

Inspect the requirements review

Read the selected, eligible and blocked counts and each model’s requirements. This pair has 0 eligible checks: Selected 2 · eligible 0 · blocked 2. Both show Needs attention and Not started. Resolve the requirements before any paid approval.

Two selected, none eligible. Both models remain blocked. Nothing has started.

Native warning heading: No checks are ready to run. — Screenshot details: Read-only review warning, selection count and run status.

Native review count: Selected 2 · eligible 0 · blocked 2. — Screenshot details: Read-only review warning, selection count and run status.

Both models remain blocked. Resolve the route requirements shown in this guide’s Add a model tab before authorizing a route and adding or selecting its matching ready saved model.

Complete native outcome and requirements cell from Astra’s row; Opus shows the same requirements. — Screenshot detail: Complete requirements from Astra’s row; Opus shows the same requirements.

View full selected-model review

Complete Check selected models sheet with the exact incident task, No checks are ready to run, and Selected 2 · eligible 0 · blocked 2. — Two selected routes, zero eligible checks, two blocked. No checks have started.

Before approving eligible checks, review each eligible model’s Provider maximum and Separate fee, the total Maximum provider charges and Maximum Millwork fees, and both deadlines. Review the current fees; each receipt records the fee charged.Approval deadline is when you must confirm; Deadline to start new checks is the latest start. Both are UTC. Only the displayed eligible set can be approved while other options remain blocked.

Approve only eligible checks

Do not continue around Needs action or select paid consent for the current routes.For a later eligible plan, permission to use a route and approval to spend are separate decisions. The consent reads: I approve only the displayed eligible paid checks, their provider maximum and the separate Millwork fee.After a valid review, use the approval button’s displayed eligible count. Review again if the account, task, models, prices or deadlines change. Each model gets at most one attempt, one check at a time, with no automatic retry or fallback.

Inspect completed responses

After actual approval, open View check progress and select Refresh progress. Read each model’s outcome; Scheduling finished can include failed or blocked checks and charges not yet confirmed. Refreshing progress starts no new checks.Run opens status; Original receipt records what ran and its charges, without the task or response. Use the matching model’s original links. Keep provider charges and Millwork fees separate. Maximum charges for checks that have not started are not an amount already charged.Retrieve a completed run’s result separately. Results can expire. Inspect whether the assessment separates facts from assumptions, considers an alternative, explains the evidence each next step would provide, and avoids claiming a confirmed root cause or recovery.

Read a completed model response

Use this only when you already have an original completed run ID from its Run link. The two model routes shown here have not run. Use the Millwork organization key you already configured in a local terminal with curl and jq. Use a local scratch folder; keep the key out of chat. This reads the existing result and starts no new run.The API URL includes /v1. The example accepts an existing MILLWORK_API_KEY or the CLI’s SOLVERAPI_API_KEY; it never uses a provider key.

MILLWORK_API_URL="https://api.getmillwork.dev/v1"
MILLWORK_API_KEY="${MILLWORK_API_KEY:-$SOLVERAPI_API_KEY}"
: "${MILLWORK_API_KEY:?Load your configured organization key privately}"
EXECUTION_ID="<original completed run ID>"

curl --fail-with-body --silent --show-error \
  --header "Authorization: Bearer $MILLWORK_API_KEY" \
  "$MILLWORK_API_URL/executions/$EXECUTION_ID/result" \
  --output result.json &&
jq -er '.final_text' result.json

Inspect the printed text. A 404 means the result is unavailable, has not been produced, or has expired. Inspect the original run and receipt; do not automatically rerun the check to replace it.

The built-in check confirms output presence; it does not grade the assessment or confer Tested by Millwork status. If charges are unconfirmed, do not retry or replace the original runs. Check actions > Cancel remaining checks stops new checks. Accepted runs keep their fees; sent requests may finish and incur charges.

Give the same task to an agent

Copy the shared agent brief

A browser or computer agent follows the dashboard’s observed labels and accessibility names to prepare the review. It stops before the paid checkbox and approval button.
A coding agent checks which documented CLI, MCP or API operations are available and prepares the review. It directs you to the dashboard for paid approval.

When reading this guide, select Connect provider, Add a model, or Check models to read the relevant phase. Product actions happen in the actual dashboard. Copy this shared instruction for either agent path. Adapt the example model and account names if your choices differ. Attach this guide’s Copy page Markdown with the brief.

Read the attached current guide Markdown first. Otherwise retrieve
https://docs.getmillwork.dev/guides/check-selected-models.md.
If unavailable, ask me for the current Markdown; do not infer instructions
from screenshots or titles.
Related docs: https://docs.getmillwork.dev/llms.txt and
https://docs.getmillwork.dev/llms-full.txt.
Documentation MCP: https://docs.getmillwork.dev/mcp/documentation.md.
Canonical route fields:
https://docs.getmillwork.dev/concepts/models-and-sources.md.
Requirement owners and original-operation recovery:
https://docs.getmillwork.dev/help/provider-connections.md.

Help me review GPT-6 Astra and Claude Opus 5.5 through my Support engineering
OpenRouter account for this incident-assessment task. Confirm the intended
models, account and current routes. Task: Assess this incident brief: After a 10:00 deployment, checkout errors rose from 0.3% to 8%. Only European traffic is affected. Latency and database CPU are unchanged. Rolling back one of three instances reduced errors on that instance; the others remain unchanged. Return: what we know; the leading hypothesis and one plausible alternative; three proposed next steps with the evidence each would provide; and an internal status update under 40 words. Separate facts from assumptions. Do not claim that the root cause or recovery is confirmed. Use only the information provided.

The current guide shows requirements that block these routes. Report those
requirements and who must act; do not claim that eligibility, paid approval
or completed model responses exist. Do not bypass Needs action.
When reading the rendered guide, select its observed Connect provider,
Add a model and Check models tabs. Perform product actions in the actual
dashboard. Use the browser/computer path or discover supported coding-client
operations. Preserve the model/account/route names and exact returned IDs.
Never derive IDs or permission from names. Keep credentials private.
For the route-inspection step, report the exact organization/account/model,
Source and payer, connection/route/invocation IDs, observation revision,
confirmed deployment/authorization IDs, permission/expiry, data scope,
protocol/location, and Last tested evidence. Quote every requirement and
its actor/action. Keep connection tests and Provider Last live check separate.
Mark unknown, not-issued, not-tested, and absent facts; do not borrow them
from another route or image. During inspection, do not refresh, recover a
write, authorize, save, or run. Report missing installed client operations.
For any later eligible plan, explain per-option and total provider maximums,
separate current Millwork fees and deadlines. Stop before paid consent or
approval in the dashboard. If an original request is uncertain, retain its
request/key, recover it, and read fresh progress before more work. Do not
retry or replace runs with charges not yet confirmed. After actual human
approval, inspect original outcomes and receipts. Completed output needs
the documented result request; do not infer assessment quality from status.

Terms and detailed rules

A model is the AI system you want to try.A batch groups selected options and schedules eligible checks one at a time. Accepted checks have individual runs; inspect their receipts when available. Model routing chooses paths for later application requests. Selecting a batch does not configure that routing.A provider serves the model API; the example uses OpenRouter as a gateway. Your provider account is your access and billing account there. A provider connection is Millwork’s saved link to that account. Your Millwork organization is your team in Millwork, separate from the provider account.A saved model is a configured option Millwork may run; the API calls it an arm. If several match a selected route, choose the exact saved model in the review. The catalog’s model route is a provider/account path; a run route records which saved model a run chose. See How model routing works.

Eligibility requires current account-route permission, a matching ready saved model, and complete pricing and limit requirements. A listing, selection, permission, saving, and paid approval are separate actions.
Select up to 20 exact routes on one connection and credential revision. The selection also retains its filter and catalog snapshot. If those change, review or explicitly clear the old selection before replacing it.
The shared task is at most 4,000 characters. This flow has no custom output check, tools, repair, fallback, or automatic inference retry. A check here is a paid live attempt, different from a free Echo test run.
Planning reserves no credits or quota and establishes no provider balance. Each accepted check consumes one run from your quota and its applicable Millwork fee. All amounts are USD, including sub-cent values.
Refreshing progress starts no new checks. Keep the original run IDs to connect each selected option to its result, receipt, and support context.

The approval button’s count follows the current eligible set.Check current availability and allowed data. Reuse an already saved model when you configure your next task.

If checks stop, charges are unclear, or you want to cancel

Situation	Next action
Needs attention	Resolve the named requirement with its responsible person. If facts or prices changed, use Review remaining checks, then explicitly approve Continue remaining checks for untouched work.
Charges unconfirmed	Do not retry the original run. Ask billing support to reconcile it. Continuing other untouched checks needs the displayed acknowledgment and approval; unresolved exposure still counts against the approved maximum.
Check original request	Keep the saved request and key unchanged. Recover that original operation, then load fresh progress: recovery returns a historical response, not current charges. If current progress is unavailable, hold replacement work.
You want to stop	Choose Check actions > Cancel remaining checks. New checks stop. Accepted runs keep their fees; sent provider requests may finish and incur charges. This does not establish a provider cancellation or refund.

Model usage and Millwork fees stay separate after cancellation. Use Provider connection help for access problems and Errors and retries for request recovery. Copy the panel’s original IDs and support details when needed; exclude credentials and private setup links from shared reports.

Details for browser and coding agents

A browser or computer agent starts from Arms > Browse model catalog. Inspect the requirements in this guide’s Add a model tab, then close the sheet and return to the catalog. You can prepare a read-only review while these routes are blocked: select their checkboxes in Actions, choose Review selected models (2), enter Task, and choose Review requirements and costs. Authorization and a matching ready saved model are required before paid checks, not before this review.For a later route whose requirements have actually been met, use Add arm, review the named model and account, choose Authorize route, then Add model arm > Add with defaults. Confirm Ready in Arms; reuse an existing matching ready saved model. Follow visible labels and accessibility names, not coordinates. Stop before the paid checkbox or approval button.Preserve the returned connection, binding revision, snapshot, filter, item, route, observation, permission, and saved-model identities. Do not derive IDs or authority from a model’s name. Preparation must use an actually supported client and current returned facts.Source CLI and private execution-MCP batch start/resume refuse with host_batch_approval_required. Direct the person to the dashboard for paid approval; do not bypass that refusal or invent a published command.The documentation MCP uses search_millwork and query_docs_filesystem_millwork to find and read docs. It cannot inspect an account or execute paid checks. Discover its current address through the server card. Use a coding assistant explains supported setup. Have the person complete private setup in their own browser; never request provider credentials in chat.Treat unknown original runs as held, retain their original request/key, and read current progress after historical recovery. Report per-item outcomes, provider charges, charges not yet confirmed, maximum charges for checks not started, and Millwork fees. Scheduling completion never proves output quality or success for every item. For a completed live run, the documented result operation is GET /v1/executions/{executionId}/result. A Run page is not an answer viewer. For the incident brief, inspect its facts, assumptions, next-step evidence and status update yourself; the built-in check does not grade them.

Get started

Provide models

Build

Build safely

SDK and MCP

Check selected models with one task

Give the same task to an agent

​Give the same task to an agent

Give the same task to an agent