Core
PWR Auto
How PWR Auto routes each run to a third-party model by purpose, cost and context, and which providers are executable today.
PWR Auto chooses which model runs each piece of work. It is a routing layer, not a model: PWR has not trained a foundation model. PWR Auto selects among catalogued models from third-party providers, and the model it picked is recorded on every run together with the reason.
Status: PWR Auto is implemented and tested against simulated providers. No routed run has been verified against a live provider. The scoring values and token profiles are starting values that have not been tuned on real usage.
Using PWR Auto
Set an agent's model to PWR Auto instead of a specific model. In the API the value is core-auto, and that identifier may also appear in PWR Studio. An agent has an implementation model and optional planning and review models; each can be PWR Auto or an explicit model. A task can override the model for itself. New agents created without a model default to PWR Auto.
If you select an explicit model, nothing is routed. The decision is still recorded, and your organization's provider approvals still apply.
How a model is chosen
For each run PWR Auto knows the purpose (implement, plan, review, chat, test or security), the credential mode, optional task hints (estimated context size, whether vision or shell is needed) and your organization's model policy.
Hard filters
These are never traded off against score:
- Reachability. A BYOK agent can only use the provider of its own key. A managed agent can only use providers PWR has configured. BYOK never crosses over to managed.
- Approval. Only providers your organization has approved.
- Availability. Only active catalog models that are available for the credential mode.
- Capabilities. Tool calling is required for implementation and test runs; vision when the task needs it.
- Context fit. The estimated context must fit within 80% of the model's context window.
- Cost cap. Models whose expected cost for the purpose exceeds your policy's per-run cap are excluded.
- Refusal cooldown. A provider that refused an earlier attempt of the same job or task (authentication, rate limit or server error) is avoided for 15 minutes when fallback is allowed.
Scoring
The remaining models are scored deterministically; the same inputs always give the same answer.
score = (w_q · quality + w_c · cost + w_x · context) × (0.5 + 0.5 · reliability)
- Weights depend on the purpose. Planning, review and security favour quality and context. Implementation is balanced. Chat favours low cost.
- A tier (
economy,balancedorquality) shifts weight between quality and cost. - Reliability is the model's rolling success rate over the last 7 days of routing decisions.
- Quality is a proxy. The catalog holds no benchmark data, so quality is derived from the model's price rank among candidates plus bonuses for reasoning controls and structured output. It will be replaced with measured quality when data exists.
If no model is eligible, the run is refused with no_eligible_model and the message lists why each candidate was excluded.
Fallback
Fallback happens between attempts, never as a loop inside one run. If a provider refuses a run, the next attempt of the same job or task excludes that provider when your policy allows fallback and another approved provider is reachable. Otherwise the run is refused with provider_unavailable until the cooldown passes.
Cost awareness
PWR Auto prices each candidate with a token profile for the purpose and the model's catalog price. The same routing is used for the pre-flight estimates shown before you launch a workflow, so the estimate reflects the model that would actually be picked.
Organization model policy
An owner can set the policy; members can read it.
| Setting | Effect |
|---|---|
approved_providers | Which providers may be used, for PWR Auto and explicit selections alike |
allow_fallback | Whether another provider may be used after a refusal |
default_tier | economy, balanced or quality |
max_cost_per_run_usd | Excludes models whose expected cost is higher |
data_residency_note | A free-text note for your own records |
Admins can read the routing decisions for their organization, each with a human-readable reason.
BYOK and managed
- BYOK. Add a provider key under Settings → Provider credentials and bind it to an agent. The key is stored encrypted and only a fingerprint is shown. If the key is revoked or invalid the run is refused; it never falls back to PWR's account.
- Managed. An agent without a credential uses PWR's provider account when one is configured, and the run is charged in credits.
During a run the real key stays outside the agent's sandbox: a broker on the worker injects it into provider requests. See Security and permissions.
Which providers are executable
| Provider runtime | Executable | Verified live |
|---|---|---|
| Anthropic Claude, Agent SDK runtime | Yes | Yes, with real model runs in a development setup. Not yet with a brokered API key. |
| Anthropic Claude, Messages API tool loop | Yes | No |
| OpenAI, Chat Completions / Responses tool loop | Yes | No |
| Google Gemini tool loop | Yes | No |
| xAI Grok tool loop | Yes | No |
| OpenAI Codex agent runtime | No | Interface only |
| Customer-hosted worker | No | Declaration only |
A task cannot be queued for an agent whose provider is not executable.
Status: The model catalog is seeded with placeholder prices that have not been checked against provider price pages, so catalog models start disabled. A model is published only after its pricing is verified. Structured output and image input are not used by any provider runtime yet.