Your request stays flexible until it conflicts with platform identity.
Anyhost is a transparent inference proxy. It preserves request parameters for the current model adapter and owns only authentication, one requested Catalog Model ID, one Generation, privacy-safe storage, and settlement.
Request contract
Anyhost does not maintain a frozen allowlist of upstream parameters.
For the current transparent adapter, fields that Anyhost does not own are forwarded with their JSON types and values intact. This includes newly released sampling, reasoning, tool, modality, provider preference, and protocol fields even when the Anyhost documentation has not named them yet.
model is required and is replaced internally with the matching reviewed route. The public response continues to show your requested Anyhost Catalog Model ID. Anyhost does not silently add max_tokens, change your sampling values, or overwrite caller-selected provider preferences.
Contract hierarchy
Read the request from the outside in.
Protocol fields describe valid JSON. Model metadata narrows that set to capabilities advertised for one Model ID. The selected Provider endpoint makes the final live support decision. Anyhost owns only the outer platform boundary.
Protocol request fields
Types and shapes follow the released Anyhost contract.
Choose one protocol, copy an exact Anyhost Catalog Model ID, and use that protocol's request shape. Object fields such as provider, reasoning, tools, plugins, and structured output retain their upstream JSON structure.
Platform boundary
Only active controls that break one-Generation semantics are rejected.
| Field | Released behavior | Why |
|---|---|---|
models, fallbacks | Must be absent, null, false, or empty | One Anyhost Generation has one requested Catalog Model ID. |
previous_response_id | Must be absent, null, false, or empty | Anyhost does not expose stored response continuation. |
prompt | Must be absent, null, false, or empty | Anyhost does not expose stored prompt references. |
background | true is rejected; false is allowed | The released request lifecycle is synchronous JSON or SSE. |
store | true is rejected; false is allowed | The Model API does not persist prompt or response content. |
SDKs may serialize inactive optional values such as null, false, empty strings, or empty arrays without being rejected. Anyhost can add a future adapter without weakening this boundary; a new adapter starts strict until its transparency contract is reviewed.
Provider routing
Provider preferences remain caller-controlled.
The current adapter forwards the provider object instead of injecting a Catalog snapshot over it. You can select provider order, allow or disable provider fallback, require parameter support, filter providers, choose price/throughput/latency ordering, request privacy properties, or set a maximum upstream price using the upstream routing contract.
model is not inside provider. Put the required exact Anyhost Catalog Model ID at the top level; copy it from authenticated GET /models or the public model browser. The optional top-level provider object only chooses among eligible serving endpoints for that same model; it cannot replace the model or select a second one. Accordingly, provider.allow_fallbacks is allowed because it falls back between Providers for the same model, while active top-level models or fallbacks are rejected because they request cross-model fallback.{
"model": "meta-llama/llama-3.3-70b-instruct",
"messages": [{"role": "user", "content": "Hello"}],
"provider": {
"sort": "throughput",
"allow_fallbacks": true,
"require_parameters": true
}
}
provider field | Type / values | Routing effect |
|---|---|---|
order | Provider slug array | Try eligible Providers in the specified order. |
only | Provider slug array | Allow only the listed Providers for this request. |
ignore | Provider slug array | Exclude the listed Providers for this request. |
allow_fallbacks | Boolean; default true | When the first eligible Provider is unavailable, allow another Provider to serve the same top-level model. |
require_parameters | Boolean; default false | Use only endpoints that support every supplied model parameter instead of allowing unsupported parameters to be ignored. |
sort | String or { "by", "partition" } | Order eligible endpoints by the released price, throughput, latency, or other current sorting strategy. |
quantizations | Quantization array | Filter endpoints by values such as int4, int8, fp8, fp16, or bf16. |
data_collection | "allow" or "deny"; default "allow" | Choose whether endpoints that may collect request data are eligible. Anyhost does not override this value. |
zdr | Boolean | When true, use only Zero Data Retention endpoints. |
enforce_distillable_text | Boolean | When true, use only models whose authors allow text distillation. |
max_price | Object with prompt, completion, request, image, or audio | Reject endpoints priced above the supplied per-request ceiling. |
preferred_min_throughput | Number or percentile object | Prefer endpoints meeting the requested tokens-per-second threshold; slower endpoints may remain as fallbacks. |
preferred_max_latency | Number or percentile object | Prefer endpoints meeting the requested latency threshold in seconds; slower endpoints may remain as fallbacks. |
Provider slug spellings and the nested shapes for sort, max_price, and percentile thresholds are published in the provider request schema of the current Anyhost OpenAPI. The OpenAPI is authoritative if the live routing contract adds a field before this guide names it.
These fields influence live routing; they do not change Anyhost's public Model ID, Resource, Generation, customer price policy, or settlement. A provider preference can reduce the available endpoint set and can make a request fail even while the model remains active. Set provider.require_parameters: true when silently ignoring a requested model parameter would be incorrect.
Generation controls
Sampling and output length belong to the caller.
Common controls such as temperature, top_p, top_k, min_p, frequency_penalty, presence_penalty, repetition_penalty, seed, stop, logprobs, max_tokens, max_completion_tokens, and max_output_tokens are forwarded when present.
Anyhost supplies no hidden output-token default. If you omit a parameter, the live model/router default applies. If you set an output length, live provider routing decides which endpoints can satisfy it. When the Catalog has an evidenced provider-level completion limit, it publishes that value as max_output_tokens without injecting it into your request; when no limit is published, Anyhost omits the Catalog field.
Reasoning controls such as reasoning, reasoning_effort, include_reasoning, thinking, and verbosity remain protocol- and model-dependent.
Content, tools, and output
Preserve each protocol's native request shape.
Chat Completions and Messages use messages; Responses uses input and may use instructions. Text, image, audio, file, and video parts are forwarded in the selected protocol's released shape. Model pages expose the current Catalog modality metadata, but live route support remains authoritative.
tools, tool_choice, parallel tool controls, structured output fields such as response_format or text.format, streaming options, and server-tool/plugin fields are transparent parameters. They are not executed by Anyhost; the live adapter handles or rejects them.
Set stream: true for native SSE. Anyhost preserves event order and exposes x-anyhost-generation-id after admission.
Transport and safety limits
Large requests are accepted up to 50 MiB.
- The JSON request body limit is 50 MiB (52,428,800 bytes). Larger requests return
413 request_too_largebefore inference. - A non-streaming upstream JSON response is bounded at 64 MiB. This protects Server memory and does not limit SSE stream duration.
- The load balancer idle timeout is 600 seconds. A connection with no network data for that interval may close; normal SSE events keep the connection active.
- The request must be exactly one JSON object and include a non-empty string
model.
These are transport and identity safeguards, not model creativity limits. Credits, Resource budget, Runtime Key validity, Resource lifecycle, model lifecycle, and protocol membership are separate admission checks.