How to Optimize for Price Latency or Reliability

To optimize for price latency or reliability, start with the workload that is buying the API call. The right preference belongs to that request, not permanently to the company, the agent or the provider.

One parameter can change which eligible provider wins. That is useful only when the buyer knows what the parameter means, keeps it separate from hard constraints and can inspect the rule that produced the choice.

The preference orders survivors

An optimization preference is a ranking instruction. It answers: among the providers allowed to serve this request, which measured dimension should matter most?

It does not decide whether a provider is allowed into the comparison. Requirements such as `max_price`, `max_latency_ms`, `min_reliability`, `settlement` and `require_all_inputs` are hard constraints. They remove candidates first. The `optimize_for` value then orders what remains.

This distinction matters because “prefer lower price” and “must not exceed this price” lead to different records. A provider can survive a price preference and lose to a cheaper alternative. A provider above `max_price` is not a runner-up at all; it is rejected by the ceiling. Budget-bound API selection explains that eligibility boundary in detail.

The same logic applies to latency and reliability. A latency ceiling rejects a slow candidate. A latency preference can still select the fastest candidate inside that ceiling. A reliability floor rejects a candidate below the required measured success rate. A reliability preference ranks the providers that satisfy the floor.

Pick the rule per workload

A company-wide default is convenient, but it is rarely a complete routing policy. Different workloads pay for different failure modes. The preference should describe what matters for the current action.

Choose `optimize_for=price` when the request can wait, repeated calls make unit cost important and every surviving provider already meets the required operating limits. Batch enrichment, scheduled collection and exploratory work often fit this shape. Price optimization should not be used to excuse missing inputs or unreliable delivery; those belong in the constraints.

Choose `optimize_for=latency` when the call sits on an interactive path or blocks another action. The buyer should still set a price ceiling and reliability floor if those are non-negotiable. “Fastest” then means the lowest measured latency among eligible candidates, not permission to ignore cost or failures. Providers can understand the distinction through measured versus advertised API latency.

Choose `optimize_for=reliability` when a failed call creates more operational work than a slower or more expensive success. Retry-sensitive workflows, irreversible downstream actions and time-limited jobs can justify that preference. The comparison uses measured success rate where enough proxied calls exist. It does not turn a provider claim into a measurement.

Choose `optimize_for=balanced` when no single dimension should dominate. Balanced is an explicit weighted decision, not an absence of policy. The response must carry the weights and every candidate's contribution so the buyer can see what “balanced” meant for that comparison.

Build a small workload policy

The routing decision becomes repeatable when each workload supplies the same compact policy fields. Keep the policy close to the operation that makes the purchase rather than hiding it in a global label.

• Capability or job the endpoint must perform.
• Required input fields and whether every input must be accepted.
• Maximum price allowed for this request.
• Maximum latency when a deadline is real.
• Minimum measured reliability when failure is unacceptable.
• Required settlement mode, if the workflow has one.
• One optimization preference: price, latency, reliability or balanced.

These fields should be passed once and reused through discovery, comparison and decision. Changing them between stages changes the question. It can also make the final explanation misleading because a provider discovered under one policy was selected under another.

Input requirements deserve particular care. Two endpoints can perform the same named job while accepting different parameters. If the chosen provider cannot consume the buyer's required fields, its favorable price or measured latency is irrelevant. API input compatibility mapping shows why compatibility belongs before ranking.

Read the decision, not just the winner

Changing `optimize_for` can change the winner without changing the candidate set. That is the point of the parameter. The provider did not become globally better; it became the best fit under the active rule.

`GET /v1/compare?candidates={id},{id}` returns price, measured latency, measured success rate and input compatibility side by side. Each 0–100 score is relative to the candidates in that one comparison. The response also carries the weights and per-dimension contributions. A score cannot be treated as a permanent provider grade.

`GET /v1/decide?candidates={id},{id}` then returns one provider, the rule that selected it, every rejected candidate with the exact constraint that removed it, and the runners-up in order. An operator reviewing the call should be able to answer:

• Which candidates failed a hard requirement?
• Which eligible candidates lost only because of the active preference?
• Which weights produced the winning score?
• Which dimensions were unavailable and therefore dropped?
• Would another workload preference have selected a different survivor?

That last question is useful for providers. Losing a latency-focused workload points to a different operating issue from being excluded by input incompatibility. The decision record turns a lost call into a specific reason instead of a vague ranking. Comparing paid APIs at decision time covers the evidence that makes such a comparison recomputable.

Treat missing measurements honestly

Reliability and latency preferences depend on observed data. When Apiosk has not proxied enough calls to measure one of those dimensions for a candidate, the dimension is dropped from the weighting and named. It is never scored zero.

That rule avoids punishing a provider for an observer's missing data. It also means a buyer that requires measured operating evidence should express that requirement as a constraint rather than assume the optimization preference will manufacture it.

Two boundaries remain. Apiosk does not measure result quality or provider terms. A high relative score says how candidates compared on the returned dimensions under the returned weights. It does not certify output quality, contractual fit or universal superiority.

External x402 results remain separate too. Discovery may return them in `external_candidates`, but they have no `candidate_id`, are unreviewed and unmeasured, and cannot continue into comparison, decision or settlement through Apiosk.

Where Apiosk fits

Apiosk lets an agent discover reviewed candidates, compare their returned operating data and decide with one visible rule. Use `optimize_for=price|latency|reliability|balanced` alongside the same hard requirements across the chain. The decision names the winner, the selecting rule, the exact rejections and the ordered runners-up. `POST /v1/decisions` can record the chosen provider and rejected alternatives afterward.

For an API provider, this makes workload fit inspectable. Your endpoint can win a price-sensitive job and lose an interactive one without either result becoming a permanent grade. Keep the listing, schema and payment terms current, then list your API so buyers can evaluate it under the policy their workload actually needs.