Budget-Bound API Selection for AI Agents

Budget-bound API selection starts with one rule: decide what a request may cost before an AI agent looks at providers. The price ceiling belongs in the candidate query, not in a final check after an expensive option has already won.

That ordering matters to API providers. If your endpoint is above the buyer's `max_price`, better latency cannot rescue it and a polished listing cannot move it back into the set. The provider is not ranked badly. It is ineligible for that request. A useful decision system keeps those two outcomes separate.

A price ceiling is a hard filter

Routing language often puts budgets, price sorting and cost optimization in the same bucket. They answer different questions.

A price ceiling asks whether a candidate may be considered at all. Price optimization asks which eligible candidate should rank first. A periodic spend limit asks whether an account or workflow has any allowance left. Mixing them produces decisions that are hard to explain and easy to misconfigure.

For one paid API request, `max_price` should act as a hard filter. A candidate above it leaves the set before scoring. The agent can then optimize the survivors for price, latency, reliability or a balanced result. This is the same separation between constraints and ranking used in an auditable API provider choice.

The alternative is to compare everything and check the budget at the end. That creates a false winner. The agent spends effort evaluating a provider it was never allowed to buy, then either fails late or silently falls back without retaining the reason.

Bind the limit before discovery

The agent needs to turn a task allowance into a request-level ceiling. Those are not automatically the same number. A workflow budget may cover several calls, retries and different capabilities. The limit for one provider selection is the amount this particular action may consume under that plan.

Before discovery, the buyer should have concrete answers for:

• The maximum price allowed for this request.
• The pricing unit that the ceiling applies to.
• Whether every required input must be accepted.
• Any maximum latency or minimum reliability requirement.
• Whether settlement must use Apiosk or go direct.
• The dimension used to rank candidates that survive.

This is narrower than a general account budget and earlier than an x402 payment check. It is also distinct from agent budget controls for paid API access, which cover spend exposure, retries and settlement records. Budget-bound selection answers only which provider can be chosen for the current job.

With Apiosk, the shared requirement parameters travel through the chain. `GET /v1/discover?q=…` can receive `max_price` alongside the other requirements. Each reviewed result has a stable `candidate_id`, so the already-filtered set can continue into comparison and decision without changing the question halfway through.

Keep the same constraint through comparison

Filtering once is not enough if the later stages reconstruct the candidate set from different inputs. The decision must inherit the same ceiling used during discovery.

`GET /v1/compare?candidates={id},{id}` places price, measured latency, measured success rate and input compatibility side by side. Each dimension is scored from 0 to 100 relative to the candidates in that comparison. The response includes the weights and each candidate's contribution, so the score can be recomputed rather than accepted on trust.

That score should never override eligibility. The comparison tells you how affordable candidates differ; it does not reopen the door to a candidate that failed `max_price`. This makes comparison at agent decision time useful without turning the score into a substitute for procurement policy.

The boundaries also stay visible. When Apiosk has not measured a dimension for a candidate, that dimension is dropped from the weighting and named, not scored zero. Result quality and provider terms are not measured anywhere. A budget filter can prove that the candidate fits the price ceiling. It cannot prove that the result will be good or that the provider's terms fit your organisation.

Price eligibility and price optimization are different

Suppose three reviewed providers perform the same job. Two fit the request ceiling and one does not. The agent should compare and rank the two affordable providers. The third should appear as rejected by the price constraint, not as a low-ranked runner-up.

Now suppose the buyer sets `optimize_for=latency`. The faster affordable provider may win even if it is not the cheapest. That is still budget-bound because every candidate under consideration fits the ceiling. If the buyer instead sets `optimize_for=price`, the cheapest eligible provider moves first. The ceiling does not change; only the ordering of survivors does.

This distinction prevents a common policy leak. “Prefer cheaper” allows a more expensive provider to win when another score contribution outweighs price. “Must cost no more than this” does not. A provider can respond to the first rule by improving its relative price or another measured dimension. It can satisfy the second only by fitting the limit for that request.

Empty results are a valid decision

A hard ceiling can leave no eligible reviewed provider. That is information, not a routing failure to conceal.

The safe next step is to return the empty set with the active constraints. The agent can ask for approval to raise the request allowance, reduce the scope, choose a different capability or stop. It should not relax `max_price` by itself, because that turns a stated limit into a preference.

External discovery does not provide a shortcut. `/v1/discover` may return matches from external x402 sources in a separate `external_candidates` block. Those entries have no `candidate_id`; they are unreviewed, unmeasured and not settleable through Apiosk. They cannot chain into `/v1/compare` or `/v1/decide`, even if their advertised price appears to fit.

For a provider, an empty result can expose a market mismatch. It says buyers are asking for the capability under a ceiling that no reviewed listing meets. It does not tell you to cut price automatically. It gives you a concrete constraint to evaluate against your own unit economics.

Preserve why each provider lost

`GET /v1/decide?candidates={id},{id}` returns one provider, the rule that selected it, every rejected candidate with the exact constraint that removed it, and the runners-up in order. In a budget-bound decision, the record must distinguish at least three outcomes:

• Rejected because the candidate exceeded `max_price`.
• Eligible but ranked below the winner.
• Excluded because another hard requirement was not met.

That distinction makes the decision actionable. A provider rejected on price sees a different problem from one that survived but lost on measured latency. An operator reviewing the purchase can tell whether changing the optimization rule would alter the winner. If price caused exclusion, changing the ranking weights alone will not.

The final choice can be recorded with `POST /v1/decisions`, including the chosen provider and rejected alternatives. Keeping the original price ceiling with that record explains the purchase later, even after provider prices or workflow policies change.

Where Apiosk fits

Apiosk applies the same requirements across discovery, comparison and decision. Set `max_price` before `GET /v1/discover`, pass the resulting `candidate_id` values forward, and let `GET /v1/decide` return the winner, the rule, the rejected candidates and the ordered runners-up. The limit filters first; the selected `optimize_for` value ranks what remains.

For API providers, this turns budget-bound API selection into a visible market rule. Your current price, input compatibility and measured operating data determine whether the endpoint enters and survives the decision. If you want an endpoint included in that reviewed candidate set, list your API with a clear capability and current input schema. The agent still owns its ceiling. Apiosk makes the consequence of that ceiling inspectable.