Releases: UiPath/uipath-llm-client-python
Releases · UiPath/uipath-llm-client-python
Release list
UiPath LangChain Client [langchain-v1.15.2]
[1.15.2] - 2026-07-03
Changed
- Bumped
uipath-llm-clientto>=1.15.1, which requiresuipath-platform>=0.1.91(fixes a circular-import crash in 0.1.89/0.1.90).
UiPath LLM Client [v1.15.0]
[1.15.0] - 2026-06-25
Added
UiPathError— a common root exception for everything the client can raise, re-exported fromuipath.llm_client.UiPathAPIError(and therefore every status-specific subclass) now inherits from it, soexcept UiPathErroris a single catch-all across all backends and providers. Fully backward compatible:UiPathAPIErrorstill inheritshttpx.HTTPStatusErrorand all existing handlers keep working.as_uipath_error(exc)and thewrap_provider_errors()context manager (inuipath.llm_client.utils.exceptions). They convert a provider/SDK exception into the matching UiPath exception so callers handle one taxonomy regardless of which provider produced the error. The cause chain (__cause__/__context__) is walked for anhttpx.Response; when found, its status code is mapped onto the correspondingUiPathAPIErrorsubclass (a 429 →UiPathRateLimitError, a 400 →UiPathBadRequestError, …) so semantic handling is identical across providers — including providers (e.g. Google) that wrap the response-bearing error one level down. When no response is available anywhere in the chain (client-side validation errors, connection failures) theUiPathErrorroot is returned. The original provider exception is preserved as__cause__.
Changed
UiPathRateLimitError.retry_afteris now parsed lazily fromself.response(via a property) instead of being cached in__init__._parse_retry_afterand the parsing behaviour are unchanged.patch_raise_for_statusnow routes the httpxHTTPStatusErrorthroughwrap_provider_errors, so directraise_for_status()callers and provider SDK exceptions share a single conversion path. The raisedUiPathAPIErrornow carries the originalHTTPStatusErroras__cause__(previouslyNone); status mapping is unchanged.
Note
- Provider errors are surfaced as pure UiPath types: an
openai.RateLimitErrorraised through a passthrough chat model becomes aUiPathRateLimitErrorand is not catchable asopenai.RateLimitError(the vendor exception is kept as__cause__). Standardise handlers onUiPathErrorand its subclasses.
UiPath LangChain Client [langchain-v1.15.0]
[1.15.0] - 2026-06-25
Added
UiPathBaseChatModelnow converts provider SDK exceptions intoUiPathError. When any chat client (UiPathChatOpenAI,UiPathChatAnthropic,UiPathChat, Bedrock/Vertex/Google/LiteLLM/Fireworks, …) raises during_generate/_agenerate/_stream/_astream, the error is converted into the matching UiPath semantic subclass (a 429 →UiPathRateLimitError, a 400 →UiPathBadRequestError, …) — including providers like Google that wrap the response-bearing error one level down — giving provider-agnostic error handling across every client. Errors without an HTTP response (e.g. client-side validation) become theUiPathErrorroot.UiPathErroris re-exported fromuipath_langchain_client.
Changed
- Bumped
uipath-llm-clientfloor to>=1.15.0to pick upUiPathErrorand thewrap_provider_errors/as_uipath_errorhelpers.
Note
- Provider errors are now surfaced as pure UiPath types and are not catchable as their original vendor type (e.g.
openai.BadRequestError); the vendor exception is preserved as__cause__. Standardise handlers onUiPathErrorand its subclasses.
UiPath LangChain Client [langchain-v1.14.1]
[1.14.1] - 2026-06-23
Fixed
WrappedBotoClient(the httpx-backed Bedrock shim) now callsraise_for_status()inconverse,invoke_model, and the streaming generator before reading the response. Previously a non-2xx gateway response (e.g. 403 License-not-available) was parsed as a normal result and handed tolangchain_aws, which raised a misleadingValueError("No 'output' key found in the response from the Bedrock Converse API ... misconfiguration of endpoint or region")— the real status code anddetailwere lost. Gateway HTTP errors now surface as the patchedUiPathAPIErrorsubclass (e.g.UiPathPermissionDeniedError), matching the OpenAI and Vertex paths. For streaming responses the error body is read first so the typed exception retains itsdetail.
UiPath LLM Client [v1.14.0]
[1.14.0] - 2026-06-15
Added
ApiFlavor.ANTHROPIC_MESSAGES("AnthropicMessages") for Bedrock-hosted Claude models that the discovery endpoint exposes with the native Anthropic Messages wire format. The value is the discovery string verbatim because it is forwarded as theX-UiPath-LlmGateway-ApiFlavorheader. Also mapped inAPI_FLAVOR_TO_VENDOR_TYPEtoVendorType.AWSBEDROCKso it resolves to the Bedrock passthrough route when discovery omits the vendor field.
UiPath LangChain Client [langchain-v1.14.0]
[1.14.0] - 2026-06-15
Added
- Support for the
AnthropicMessagesAPI flavor on Bedrock-hosted Claude models.get_chat_modelnow routes discovery'sapiFlavor=AnthropicMessages(vendorAwsBedrock) toUiPathChatAnthropicconfigured withvendor_type=awsbedrockandapi_flavor=ApiFlavor.ANTHROPIC_MESSAGES. The client keeps the Bedrock passthrough URL but uses the nativeAnthropic/AsyncAnthropicSDK (model-in-body wire format), which the gateway requires for this flavor, instead ofAnthropicBedrock. UiPathChatAnthropicnow accepts an explicitapi_flavor. When set toApiFlavor.ANTHROPIC_MESSAGESit selects the native Anthropic SDK regardless ofvendor_type; otherwise the flavor and SDK are derived fromvendor_typeexactly as before (awsbedrock→invoke+AnthropicBedrock, unchanged).
Changed
- Bumped
uipath-llm-clientfloor to>=1.14.0to pick upApiFlavor.ANTHROPIC_MESSAGES.
UiPath LLM Client [v1.13.1]
[1.13.1] - 2026-06-09
Fixed
PlatformSettingsnow accepts non-JWT access tokens (e.g. opaque UiPath reference tokens) forUIPATH_ACCESS_TOKEN. Previously any token that was not a parseable JWT failed validation with "Invalid access token: expected JWT with at least 2 dot-separated parts". Token introspection is now best-effort:is_token_expiredreturnsFalsewhen the token is not a parseable JWT, and the settings validator only extractsclient_idwhen the token is a parseable JWT. Addedtry_parse_access_tokenhelper inuipath.llm_client.settings.platform.utils.
UiPath LangChain Client [langchain-v1.13.1]
[1.13.1] - 2026-06-09
Fixed
- Picks up the core
uipath-llm-client1.13.1 fix allowing non-JWT access tokens (e.g. opaque UiPath reference tokens) asUIPATH_ACCESS_TOKEN, so LangChain clients built onPlatformSettingsno longer fail validation with "Invalid access token: expected JWT with at least 2 dot-separated parts".
UiPath LLM Client [v1.13.0]
[1.13.0] - 2026-05-27
Added
UiPathRequestTimeoutError(HTTP 408) andUiPathBadGatewayError(HTTP 502) exception classes. Both are registered in_STATUS_CODE_TO_EXCEPTION, re-exported fromuipath.llm_client, and inherit fromUiPathAPIErrorfor compatibility with existing handlers.
Changed
- Default retry set expanded.
_DEFAULT_RETRY_ON_EXCEPTIONSinuipath.llm_client.utils.retrynow coversUiPathRequestTimeoutError(408),UiPathRateLimitError(429),UiPathBadGatewayError(502),UiPathServiceUnavailableError(503),UiPathGatewayTimeoutError(504), andUiPathTooManyRequestsError(529) — up from{429, 529}. Applies to every provider client (UiPathOpenAI,UiPathAnthropic*,UiPathGoogle) since they all share the sameUiPathHttpxClient-backed retry transport.Retry-After/x-retry-afterheaders and exponential backoff with jitter behave as before. UiPathHttpxClient/UiPathHttpxAsyncClientdefaultmax_retriesraised from0to3. Callers that passmax_retries=None(or omit it entirely) now get 3 retries by default. Passmax_retries=0explicitly to opt out —max_retries=0continues to disable retries, so the opt-out path is unchanged.
UiPath LangChain Client [langchain-v1.13.0]
[1.13.0] - 2026-05-27
Changed
UiPathBaseLLMClient.max_retriesfield default raised from0to3. Every LangChain chat and embedding client built on this base (UiPathChat,UiPathChatOpenAI,UiPathAzureChatOpenAI,UiPathChatAnthropic,UiPathChatAnthropicBedrock,UiPathChatBedrock,UiPathChatBedrockConverse,UiPathChatVertexAI,UiPathChatFireworks,UiPathChatLiteLLM, plus the matching embeddings classes) now retries failed requests 3 times by default. Passmax_retries=0explicitly to disable retries — the opt-out path is unchanged. Combined with the expanded default retry set inuipath-llm-client1.13.0, every LangChain client now retries on HTTP 408, 429, 502, 503, 504, and 529 out of the box.- Bumped
uipath-llm-clientfloor to>=1.13.0to pick up the expanded default retry set and the newUiPathRequestTimeoutError/UiPathBadGatewayErrortyped exceptions.