Clients
Python LLM Proxy client with v2 messages
Use ClientMessagesRequest and post_messages for canonical text requests from Python.
Python workflow authors and service developers standardizing on the /v2 messages contract.
The problem
Python callers often start with raw requests and then duplicate provider-specific payload details in scripts.
How LLM Proxy helps
The Python package exposes Client, ClientConfig, ClientMessage, ClientMessagesRequest, and Client.post_messages for v2-only text transport.
How it works
- Install the package from the repository.
- Create ClientConfig with base_url and secret.
- Build ClientMessagesRequest with one or more ClientMessage values.
- Set reasoning_effort only for a nonblank value declared by the resolved route, or omit it to retain the tenant default.
- Set request_timeout_seconds only when this request needs a specific proxy work budget.
- Call post_messages and let the proxy route provider details.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Messages request object | Callers send system, user, and assistant messages in one typed request shape. | Chat workflows avoid ad hoc JSON. |
| Optional order | Messages can include order values when array order is not enough. | The proxy sorts before routing. |
| Reasoning-effort override | ClientMessagesRequest serializes an optional nonblank reasoning_effort value. | The proxy validates it against the exact resolved provider/model capability. |
| Per-request work budget | ClientMessagesRequest serializes request_timeout_seconds as the canonical timeout header. | The default urllib transport adds no unrelated total-response deadline. |
| Transport context | Python client errors include non-secret provider, model, and timeout context. | Debugging avoids leaking credentials. |
Use-case examples
Scripted summary
A Python script sends one user message to a configured provider default.
Transcript replay
A workflow sends ordered chat messages for review.
Reasoning route
The client targets provider=openai with gpt-5.5 and reasoning_effort=high for one supported request.
Objections and limitations
- The package is v2-only for text requests.
- It does not send raw provider API keys.
- Dictation requires direct multipart HTTP usage today.
Repository evidence
from llm_proxy_client import Client, ClientConfig, ClientMessagesRequest, ClientMessage
client = Client(
ClientConfig(
base_url="http://localhost:8080/?provider=openai",
secret="mysecret",
)
)
text = client.post_messages(
ClientMessagesRequest(
messages=(ClientMessage(role="user", content="Summarize this"),),
model="gpt-5.5",
max_tokens=512,
reasoning_effort="high",
request_timeout_seconds=900,
)
)Verified 2026-08-08 by Tyemirov on GitHub against README.md.
FAQ
What is the main job of Python LLM proxy client v2?
The Python package exposes Client, ClientConfig, ClientMessage, ClientMessagesRequest, and Client.post_messages for v2-only text transport.
Who should read this clients resource?
Python workflow authors and service developers standardizing on the /v2 messages contract.
Does this page claim provider performance or pricing advantages?
No. The supported claim is about LLM Proxy's documented routing, configuration, management, security, usage, and deployment contracts. Provider cost, speed, rankings, and benchmark claims are not made here.
Where should setup details come from?
Use the main README and implementation notes for current command, config, and endpoint details. This page summarizes the workflow without replacing LLM Proxy documentation.
What should I read next?
A closely related resource is Authenticate an LLM Proxy client with a tenant secret, which covers LLM Proxy client authentication.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference