LlmGetStatusCode Function  
 
INT WINAPI LlmGetStatusCode(
  HCLIENT hClient  
);

The LlmGetStatusCode function returns the most recent HTTP status code for a client request.

Parameters

hClient
A handle to the client session.

Return Value

If the function succeeds, the return value is the HTTP status code. If the function fails, the return value is LLM_ERROR. To get extended error information, call LlmGetLastError.

Remarks

The LlmGetStatusCode function returns the HTTP status code returned by the provider for the most recent request associated with the specified client session. This value reflects the result of the underlying HTTP operation used to communicate with the provider.

HTTP status codes are three-digit numeric values which indicate whether a request was successful or if an error occurred. They may be interpreted using the following general ranges:

Value Description
100-199 Informational responses. These are rarely used in practice and indicate that the request has been received and processing is continuing.
200-299 Successful responses. The request was successfully processed by the provider. A value of 200 (OK) is typically returned for successful API requests.
300-399 Redirection responses. These indicate that additional action may be required to complete the request. These responses are uncommon when using API endpoints.
400-499 Client errors. The request was invalid or could not be processed by the provider. This may indicate issues such as invalid parameters, missing authentication credentials or rate limiting.
500-599 Server errors. The provider encountered an error while processing the request. These errors are typically transient and may succeed if the request is retried.

This function can be used in conjunction with the return value of a function such as LlmSendMessage or LlmConnect. The status code may provide additional information about why a request was rejected or processed with an error condition by the provider. For example, if a request fails and the status code is 503, this indicates the service is temporarily unavailable.

HTTP status codes are returned by the provider service and their exact meaning may vary slightly between providers. Some providers may also return additional diagnostic information in the response body which can help identify the specific cause of the error. Here are some common error status codes and what they could mean in the context of the client session:

  • 400 Bad Request - The request was malformed or contained invalid parameters. This usually indicates an internal error in the library where a request was not composed correctly. This could occur if the service provider does not support certain functionality, an invalid option was used, or an incorrect endpoint was specified.
  • 401 Unauthorized - The API key is missing, invalid, or expired. If you are using an environment variable or Windows credential, check to make sure it is defined and contains the correct value. If you continue to experience this error, check the provider account to ensure the key has not been revoked or replaced.
  • 403 Forbidden - The request was understood, but the provider refused to process it. This can occur if the account does not have permission to use the selected model, endpoint, organization, or project. Verify that the API key has access to the requested resource and that billing or account restrictions are not preventing the request.
  • 404 Not Found - The requested resource could not be found. This commonly indicates an incorrect endpoint URL, deployment name, model name, or provider-specific path. Verify that the provider, base URL, and model name are correct for the account being used.
  • 408 Request Timeout - The provider did not complete the request before the timeout expired. This can occur because of network latency, a temporary service issue, a large prompt, or a model that requires more time to generate a response. Consider increasing the timeout value, reducing the prompt or history size, or retrying the request later.
  • 409 Conflict - The request conflicts with the current state of the service or resource. This is uncommon for simple message requests, but may occur with provider-specific operations, duplicate requests, or incompatible settings. Review the request options and retry the operation after any pending provider-side operation has completed.
  • 413 Payload Too Large - The request body is larger than the provider allows. This usually means the prompt, conversation history, attached content, or generated request JSON exceeds the model or endpoint limit. Reduce the prompt size, clear or shorten the conversation history, or select a model with a larger context size. The LlmTrimHistory function can be used to reduce the amount of conversation history included with a prompt.
  • 415 Unsupported Media Type - The provider does not support the request content type or encoding. This can indicate that the request was not submitted as JSON, that the wrong endpoint was used, or that the provider does not support the submitted content format. Verify the endpoint and make sure the request format matches the provider requirements.
  • 422 Unprocessable Entity - The provider accepted the request format, but could not process the request contents. This can occur if a model option, reasoning level, response format, tool definition, or other provider-specific setting is not valid for the selected model. Review the selected model and options, and disable unsupported features.
  • 429 Too Many Requests - The provider rejected the request because a rate limit, usage limit, or account quota was exceeded. Applications should wait before retrying the request, reduce the request rate, and avoid retrying immediately in a tight loop. If the error persists, review the provider account limits, billing status, and usage quotas.
  • 500 Internal Server Error - The provider encountered an unexpected server-side error while processing the request. This usually indicates a temporary problem with the provider rather than the application. Retry the request later, and check the provider status page if the problem continues.
  • 502 Bad Gateway - A gateway or proxy received an invalid response from an upstream service. This is typically a temporary provider-side or network condition. Retry the request after a short delay, and check whether the provider is experiencing a service disruption.
  • 503 Service Unavailable - The service is temporarily unavailable because of maintenance, overload, or resource limits. Retry the request after a delay. If the provider returns a retry interval, the application should wait at least that long before trying again.
  • 504 Gateway Timeout - A gateway or proxy timed out waiting for an upstream service to complete the request. This can occur when the provider is under heavy load or when a response takes too long to generate. Retry the request later, reduce the prompt size, or request a shorter response.

If no request has been made, or if the client has not yet received a response from the provider, the return value may be zero. If the client handle is invalid or a request is currently in progress, the function will return LLM_ERROR (-1). In this case, a status code is not available.

Requirements

Minimum Desktop Platform: Windows 7 Service Pack 1
Minimum Server Platform: Windows Server 2008 R2 Service Pack 1
Header File: cstools12.h
Import Library: csllmv12.lib

See Also

LlmConnect, LlmGetLastError, LlmSendMessage, LlmTrimHistory