Use Orq.ai as the model control layer for PydanticAI. Route LLM calls through one OpenAI‑compatible endpoint, capture traces, monitor cost, and manage fallback behavior without rebuilding your PydanticAI agents, tools, or typed interfaces.
What is PydanticAI?
PydanticAI is a framework for “structured AI” built on Pydantic: you define typed models for inputs and outputs, and it handles calling the LLM and validating responses against those schemas. It helps teams focus on data contracts, tools, and business logic instead of hand‑parsing and validating model output.
Why use Orq with PydanticAI
Trace typed agent behavior end to end
Trace PydanticAI runs end to end, including prompts, typed inputs, tool invocations, validated model responses, and errors in one place. You get clearer visibility into how each structured result was produced, without stitching together logs across multiple services.
Model flexibility without rewiring agents
Test new models, add alternative providers, or assign different model tiers to different PydanticAI agents and endpoints from Orq.ai, while keeping your Pydantic models and agent logic stable. Your PydanticAI code still “thinks” it’s talking to a single OpenAI‑style client; Orq decides which underlying model is called.
Evaluate real production runs
Use real PydanticAI traces like typed inputs, validated outputs, and schema errors to build datasets, compare prompt or model changes, and move from subjective tuning to measurable quality checks. Failed or malformed structured responses can be turned into eval inputs before you roll out changes.
Control spend and access centrally
Track token usage and spend per agent, schema, team, and workflow so you can see which routes drive cost. Add budgets, rate limits, and approved‑model lists at the Orq platform layer instead of enforcing governance separately inside each PydanticAI‑based application.
How the integration works
Step 1
Point PydanticAI’s client at Orq.ai’s router
Configure the OpenAI‑compatible client that PydanticAI uses so its HTTP calls go to Orq.ai’s base URL and key instead of calling each model provider directly. This gives Orq the context it needs to apply routing rules, capture usage, and enforce fallback behavior behind your structured endpoints.
Step 2
Enable tracing from PydanticAI workloads to Orq
Keep your existing logging and monitoring in place while routing LLM calls through Orq’s AI Gateway / Router. Your app continues to emit logs around schema use and agent execution, and Orq records LLM interactions, latency, and cost metrics, so you can see both agent‑level and model‑level traces.
Step 3
Define routes, fallbacks, and policies in Orq
Create routes for key PydanticAI workflows (for example extraction agents, classification endpoints, or copilots that return typed results) and assign them model tiers, fallback chains, and region/data policies. Your agents send LLM requests to the configured Orq routes, and Orq applies routing before invoking OpenAI, Claude, Gemini, or other models.
Step 4
Monitor, evaluate, and tune
Once connected, use Orq’s dashboards to watch latency, errors, and cost for PydanticAI‑based agents, and run evals or experiments on their traces. You can adjust routes, models, or prompt configurations centrally where supported, while PydanticAI continues to handle schemas, tools, and validation.
Use Cases
Multi‑endpoint products with real observability
Trace which PydanticAI agent, schema, and model contributed to a failed workflow or unexpected output, combining your own logs with Orq’s router‑level traces.
Cost‑aware internal tools
Route routine structured tasks (for example simple extraction, tagging, or scoring) to lower‑cost models while keeping complex reasoning or safety‑critical typed responses on your strongest routes configured in Orq.
Eval‑driven schema and agent improvements
Reuse failed validations, malformed JSON, and PydanticAI traces as eval inputs before shipping schema, prompt, or model changes, turning production telemetry into a continuous improvement loop.
Safer experimentation across providers
Test a new provider or model on a small share of PydanticAI traffic, then promote or roll back based on traces and evals, instead of editing each agent or client configuration by hand.
FAQ
Do I have to change my PydanticAI code to use Orq.ai?
In many cases, you can repoint the OpenAI‑style client PydanticAI uses (base URL, API key, and model identifier) to Orq’s router and keep your existing Pydantic models, agents, and validation logic as‑is, adding only minimal configuration instead of rewriting endpoints.
Does Orq.ai replace PydanticAI’s own runtime or framework?
No. PydanticAI remains your framework for structured prompting and typed agents; you keep using its Pydantic models and validation. Orq.ai sits alongside it as the control plane for models, multi‑provider routing, cost tracking, and evaluation. You still design and run typed agents with PydanticAI at the core, but you use Orq to see what they cost, which models they should call, and how LLM behavior compares across providers under the same structured workflow.
Can I keep using my existing LLM providers with PydanticAI if I move to Orq.ai?
Yes. You can bring your existing provider keys into Orq.ai and route PydanticAI traffic through them, alongside any new models you add later. That way you centralize access, routing, and tracking without losing the LLM and PydanticAI setup you already rely on. Bring production controls to PydanticAI agents
