1. Find models available to your key
GET /v1/models returns the models your key can call, after its allowed-model list and your account or organization settings.
The public model directory also shows models that need consent. Use the exact id from the API.
2. Check capabilities
Check category, supported_endpoints, available, capabilities and limits before you send a request. A missing capabilities or limits field means support is not confirmed.
Model limits can be lower than the gateway's general limits. Messages and Responses are translated to Chat, so they don't expose every provider feature.
See model fields for every field.
Parameter policy
Use the selected model’s parameter_profile for required inputs, defaults for omitted values, supported parameters and allowed combinations.
Set the policy in the request body, for example "everyais": {"parameter_policy": "strict"}.
everyais.parameter_policy | Behavior |
|---|---|
auto (default) | Drops unsupported sampling options (temperature, top_p, penalties, top_k), seed and user, and lowers values to a supported one. Other unsupported options, such as stop, logprobs or tools, return 400 |
strict | Any unsupported value or combination returns 400 unsupported_parameter |
Each adjustment is reported in x_everyais.parameter_warnings with param, action, reason and applied.
Tools, masks and response formats are never adjusted. Options that only some providers support are listed in parameter_constraints and parameter_profile.routes.
3. Check access policies
Community supply (supply) and provider training use (training_use) are off until you opt in. Personal keys use your account settings; organization keys use the organization's.
A model available only through community supply or only with training use returns 404 model_not_found on Chat, Messages and Responses until you opt in. Requests to mixed models go only to providers you allow.
If a model is missing, check the key's allowed models, both settings and the model's available flag.