Rank catalog model profiles by agent-supplied criteria.

Ranked catalog candidates with reasons and source provenance. minThroughputTps and maxLatencySeconds are inclusive bounds on the latest llm-stats throughput_tps (tokens/second) and latency_s (seconds). Missing or non-finite requested metrics and bound failures appear in excluded with reasons. maxCostPerTaskCents requires expectedInputTokens and expectedOutputTokens; estimates use uncached catalog input/output prices in cents per million tokens. Unpriced and over-budget rows appear in excluded with reasons; accepted rows carry estimatedCostPerTaskCents. Every returned result carries a granting profileId — a catalog entry with no profile grant for this project/org/system scope is excluded from results entirely rather than returned with a null id. Pass minBenchmark {source, metric, minValue} to require a minimum benchmark result on a candidate's latest snapshot (a model with no numeric value for the pair is excluded, reported as floors-too-high), or objective: highest-benchmark with benchmarkRank {source, metric} to rank by that value highest-first (models without a value sort last and say why). A benchmark ranking first checks per-eval SCALE comparability across the pool: mixed or unrankable scales refuse with benchmark-scale-mismatch instead of ordering numbers that mean different things. Each candidate's benchmarks list carries the latest snapshot values with source and observed date, plus per-eval scores (benchmark id, scale, version, observed date) at full source precision. Artificial Analysis entries are effort-qualified: one entry per effort (null for a base observation), and a floor or rank reads only the entry at the granting profile's own effort, never another effort's number. status distinguishes why results may be empty: runner-capacity-unavailable (the project has no runner-capable execution pool) and verification-budget-exhausted (ranked candidates existed but the bounded launch-verification pass could not confirm one within budget — narrowing the criteria may help) are both distinct from credentials-missing (candidates existed and were all tried, none resolve today). Candidates are verified against the real launch resolver in ranked order, sequentially, under a BOUNDED attempt budget of min(max(3 × limit, 30), 40) resolutions — at most 40 for any request, the accepted worst case (~250 statements). truncated: true means that budget ran out before every ranked candidate was tried, so a launchable row may exist past the point this answer looked; a short results page with truncated: false is a complete answer. Retrying with a larger limit buys a larger budget, but only within that ceiling: the spread between the default page and the maximum page is 30 attempts to 40, not more, so limit is a narrow recovery lever rather than an unbounded one.