Where Millwork fits

Millwork is useful when your application calls more than one model and you need to know what ran and what it cost. You save the models your organization may use and send each task with its data rules, budget, and runtime limit. A completed live run returns the model output as a result. Every run that ends leaves a receipt recording what happened, without your prompt or output. Every live run, one submitted to call a model, has a platform fee, charged when Millwork accepts the run; see Model access and billing. Each situation below follows the same shape: what you have, what changes, and what you can inspect afterwards.

​

Use models from several providers through one API

The situation: your application needs models served by different providers, clouds, or gateways. What changes: you connect each provider account once, in a secure setup step. Your catalog then lists the models you can use. Your application sends every task the same way, and Millwork picks among the saved models that fit the task’s limits. Your request body does not change when you connect another provider. What you can inspect: for a model saved from your catalog, the requested and provider-reported models, the provider connection, and who bills the model usage.

​

Put the same limits on agent work

The situation: an agent workflow calls models, services, or procedures, and each path handles limits and failures differently. What changes: you set data rules, a model-usage budget, a runtime limit, and an output check for each task. These settings apply to saved models, agent endpoints, and reusable skills (versioned procedures you saved as options). Millwork falls back to another saved option or proposes a repair (a change to a saved skill) only when your request allows it. A proposed repair changes nothing until someone in your organization approves it. What you can inspect: which saved options were kept and which were left out, with a reason, which one ran, whether the output passed its check, which response followed, and the final status.

​

Change models without changing your code

The situation: a provider changes a model, a new provider account becomes available, or a model is no longer ready. What changes: the model and its model route live in your saved models, not in your feature code. Add or replace a saved model and the next run can use it. A model that is not ready is left out of the run; it is never used as a fallback. What you can inspect: the saved model selected for each run. Completed live runs on catalog models also report the provider and model that answered, including a more specific model name when a gateway supplies one.

​

Use the checks you already trust

The situation: your team already has a policy evaluator, compliance rule, or completed workflow record that it trusts to judge an answer. What changes: put that logic behind an output-check endpoint. Millwork sends the candidate output; your service returns a hard verdict, a quality score, and optional named results. Your service keeps its own models, proof sources, and credentials. Long-running evaluation finishes upstream before the endpoint returns its bounded answer. What you can inspect: the recorded verdict, score, and named checks beside the run’s cost and outcome. These are your service’s claims; if the agent being graded can also write the evidence, use a check-owner source or signed proof. Choose an output-check recipe to test the pattern locally before connecting it.

​

Keep an audit record without the prompts

The situation: your team needs to know what ran, without storing prompts and outputs in the audit trail. What changes: a completed live run’s result holds the output. The receipt holds the record of the run and never holds the prompt or output. The two share one run ID, so you can keep the receipt and discard the result when your application no longer needs it. What you can inspect: the chosen model, recorded usage, check outcome, and any follow-up action in the receipt. Read the run’s events for its status history. Results and receipts explains the model and provider details available in each record.

​

Private-preview fit

The private preview is for teams evaluating text-model runs over REST with public information or test data created for the evaluation. Check What is available today before planning restricted-data or production use.