Struct RunConfig 

pub struct RunConfig {
    pub endpoint: Endpoint,
    pub claimed_model: Option<String>,
    pub depth: Depth,
    pub lang: Lang,
    pub selection: Selection,
    pub seed: Option<u64>,
    pub http: Option<Client>,
    pub pace: Option<Pace>,
    pub concurrency: usize,
    pub max_in_flight: usize,
}

Everything a run needs.

Fields

endpoint: Endpoint

claimed_model: Option<String>

The model the vendor claims to serve, when it differs from the id being requested. Defaults to endpoint.model.

depth: Depth

lang: Lang

selection: Selection

seed: Option<u64>

None draws one from the clock — see [Rng::from_seed] for why an embedder should choose its own instead.

http: Option<Client>

Reuse the caller’s HTTP client. See Client::with_http.

pace: Option<Pace>

Spread the run out instead of issuing it as a burst. See Pace.

concurrency: usize

Overlap the steps instead of running them one at a time. See RunConfig::concurrency.

max_in_flight: usize

Requests this run may have in flight at once, whatever the schedule. See RunConfig::max_in_flight.

Implementations

impl RunConfig

pub fn new(endpoint: Endpoint) -> Self

pub fn model_only(self) -> Self

Probe only what survives a relay — see probes::Subject.

pub fn turbo(self, in_flight: usize) -> Self

The cheapest run that still supports a verdict about the model.

Selection::turbo with the steps overlapped and the traffic capped. Twelve requests at Depth::Fast, in roughly four round trips instead of twenty-one, which is the difference between a run somebody can watch finish and one they give up on.

in_flight is the only number here worth thinking about, and it is a statement about the endpoint rather than about this crate: how many simultaneous requests it will answer without queueing or refusing. Set it too high and the run measures the endpoint’s saturation instead of its behaviour — and, on anything with a per-account concurrency budget, spends that budget on being examined. When in doubt, three.

pub fn concurrency(self, n: usize) -> Self

How many steps may be in flight at once. 1 is sequential, the default, and what every release before 0.5.0 did.

Ignored while a Pace is set: pacing exists to make a run hard to pick out of ordinary traffic, and overlapping exists to compress it into the smallest possible burst. A caller asking for both is asking to be unobtrusive quickly, and pacing wins.

Steps marked exclusive still run alone — preflight because everything after it depends on its answer, perf because a latency measurement taken alongside this run’s own traffic measures this run.

pub fn max_in_flight(self, n: usize) -> Self

Cap the requests in flight, independently of how many steps are.

Steps are uneven — the capability battery is a dozen requests and stop_sequence is one — so a step count does not bound what the endpoint sees. This does. 0 leaves it uncapped.

pub fn depth(self, d: Depth) -> Self

pub fn lang(self, l: Lang) -> Self

pub fn seed(self, s: u64) -> Self

pub fn claimed_model(self, m: impl Into<String>) -> Self

pub fn http(self, c: Client) -> Self

pub fn pace(self, min: Duration, max: Duration) -> Self

Wait a random interval between steps — see Pace.

Trait Implementations

impl Clone for RunConfig

fn clone(&self) -> RunConfig

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.