Chat Completions
OpenAI compatible /chat/completions endpoint for LLM inference.
Check the OpenAI
API reference
for the most updated documentation. The ground truth is always the latest OpenAI API
Reference. The arguments below are copied for convenience, but might not be fully
up-to-date at all times.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Body
A list of messages comprising the conversation so far.
The endpoint to use, in the format {model}@{provider}, based on any of the supported endpoints as per the list returned by /v0/endpoints
The maximum number of tokens that can be generated in the chat completion.
The total length of input tokens and generated tokens is limited by the model’s context length.
Up to 4 sequences where the API will stop generating further tokens.
If set, partial message deltas will be sent. Tokens will be sent as data-only server-sent events as they become available, with the stream terminated by a data: [DONE] message.
What sampling temperature to use, between 0 and 2. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic.
Generally recommended to alter this or top_p, but not both.
Number between -2.0 and 2.0. Positive values penalize new tokens based on their existing frequency in the text so far, decreasing the model’s likelihood to repeat the same line verbatim.
Modify the likelihood of specified tokens appearing in the completion.
Accepts a JSON object that maps tokens (specified by their token ID in the tokenizer) to an associated bias value from -100 to 100. Mathematically, the bias is added to the logits generated by the model prior to sampling. The exact effect will vary per model, but values between -1 and 1 should decrease or increase likelihood of selection; values like -100 or 100 should result in a ban or exclusive selection of the relevant token.
Whether to return log probabilities of the output tokens or not. If true, returns the log probabilities of each output token returned in the content of message.
An integer between 0 and 20 specifying the number of most likely tokens to return at each token position, each with an associated log probability. logprobs must be set to true if this parameter is used.
How many chat completion choices to generate for each input message. Note that you will be charged based on the number of generated tokens across all of the choices. Keep n as 1 to minimize costs.
Number between -2.0 and 2.0. Positive values penalize new tokens based on whether they appear in the text so far, increasing the model’s likelihood to talk about new topics.
An object specifying the format that the model must output.
Setting to { "type": "json_schema", "json_schema": {...} } enables Structured Outputs which ensures the model will match your supplied JSON schema.
Setting to { "type": "json_object" } enables JSON mode, which ensures the message the model generates is valid JSON.
Important: when using JSON mode, you must also instruct the model to produce JSON yourself via a system or user message. Without this, the model may generate an unending stream of whitespace until the generation reaches the token limit, resulting in a long-running and seemingly “stuck” request. Also note that the message content may be partially cut off if finish_reason="length", which indicates the generation exceeded max_tokens or the conversation exceeded the max context length.
If specified, the system will make a best effort to sample deterministically, such that repeated requests with the same seed and parameters should return the same result. Determinism is not guaranteed, and you should refer to the system_fingerprint response parameter to monitor changes in the backend.
Options for streaming response. Only set this when you set stream: true.
An alternative to sampling with temperature, called nucleus sampling, where the model considers the results of the tokens with top_p probability mass. So 0.1 means only the tokens comprising the top 10% probability mass are considered.
Generally recommended to alter this or temperature but not both.
A list of tools the model may call. Currently, only functions are supported as a tool. Use this to provide a list of functions the model may generate JSON inputs for. A max of 128 functions are supported.
Controls which (if any) tool is called by the model. none means the model will not call any tool and instead generates a message.auto means the model can pick between generating a message or calling one or more tools. required means the model must call one or more tools. Specifying a particular tool via {"type": "function", "function": {"name": "my_function"}} forces the model to call that tool.
none is the default when no tools are present. auto is the default if tools are present.
Whether to enable parallel function calling during tool use.
A unique identifier representing your end-user.
A string used to represent where the request came from, for examples, did it come via the Python package, the NodeJS package, the chat interface etc. This should not be set by the user.
Whether or not to use custom API keys with the specified provider, meaning that you will be using your own account with that provider in the backend.
Comma-separated list of tags to associate with the corresponding prompt.
Whether or not to drop unsupported OpenAI params by the provider you’re using
A string used to represent the region where the endpoint is accessed. This is only relevant for certain providers like vertex-ai and aws-bedrock, where the endpoint is being accessed through a specified region.
Whether to log the contents of the query json body.
Whether to log the contents of the response json body.