---
title: "Test Caveman context compression with a Pydantic AI application"
description: "Keep the Pydantic AI agent in Python for the first trial. There is no reviewed native Caveman adapter for this framework. Start with one saved tool result, then decide whether an explicit integration "
canonical: https://caveman.so/switch/pydanticai
last-updated: 2026-09-07
---

# Test Caveman context compression with a Pydantic AI application

Keep the Pydantic AI agent in Python for the first trial. There is no reviewed native Caveman adapter for this framework. Start with one saved tool result, then decide whether an explicit integration is worth adding.

A move to Caveman's TypeScript Agent SDK requires porting application contracts. It is not an import rename, and it is unnecessary if a small context change solves the problem.

## Save the Python baseline

Record the Pydantic AI and provider SDK versions, agent instructions, dependencies, tools, output type, retry settings, and history handling. Keep your current evaluation suite callable.

Select a task with a large textual tool result and a final output you can validate. Include a missing field, invalid tool argument, provider failure, and a response that requires a validation retry.

Use [Pydantic AI's documentation](https://pydantic.dev/docs/ai/overview/) to identify which native context controls you already use. Avoid stacking a second transformation before understanding the first.

## Inspect a representative fixture

Save a permitted tool result as a fixture, then run the local CLI:

```bash
npm install -g @caveman-ai/cli
caveman shrink --file ./fixtures/tool-output.json
```

Compare the emitted view with the original. Note which fields remain, what was omitted, and whether the command provides a recovery handle. Use [the compression guide](/guides/prompt-compression) to retrieve the original through that handle.

Try at least one follow-up question that needs an omitted detail. A transform that looks readable to you may still remove the fact your agent needs.

## Define the tool contract before integrating

Do not replace a typed result with an arbitrary text marker. If a tool returns a complete list of records, downstream code and validators may rely on that shape.

One possible application design is an explicit evidence result with a readable view and a separate retrieval tool. The schema, handle lifetime, permissions, and retrieval behavior must be defined by your application. That is integration work, not something the standalone command supplies to Pydantic AI automatically.

Keep exact fields used for decisions or side effects. If the candidate cannot recover an original, use the unmodified content for that case. Verify that the local store remains accessible to the process that handles follow-up calls.

## Treat a proxy experiment as a separate path

If you control the provider client, review [Pydantic AI's OpenAI configuration](https://pydantic.dev/docs/ai/models/openai/) and [Caveman's provider mounts](https://docs.caveman.so/docs/proxy/providers). Use the actual API protocol your model wrapper emits.

Run the caller and loopback proxy on the same reachable host for a local trial. Preserve provider credentials through the documented configuration. Test tools, structured output, streaming, cancellation, and error responses before moving a real workflow.

Do not assume Responses API, Chat Completions, and provider-native requests share all behavior. An endpoint that accepts a text request may still be unsuitable for the agent's tool or recovery path.

## Judge the final typed result

Run direct and candidate tasks from the same starting history. Apply the same Pydantic validation and semantic acceptance checks. Count validation retries, recovery, extra tool calls, and the complete elapsed time.

Use provider usage when available and label local estimates separately. Keep failed tasks in the result set. [The measurement guide](/guides/measure-agent-cost) gives the accounting rules.

## Plan a full runtime move only with an explicit map

If you choose the TypeScript SDK, inventory every Python dependency, tool schema, output type, persistence behavior, and deployment requirement. Port one side-effect-free task first and compare the final artifacts. Build from the supported source revision described in [the SDK guide](/guides/agent-sdk-migration).

Do not remove the Python service until the required contracts pass. Keep a route back to the original agent while the candidate runs in staging.

## Roll back

Restore the original tool result and provider configuration. Retain the original fixtures and any recovery data needed by active sessions. Confirm that typed output and retries match the saved baseline.

The [comparison](/compare/pydanticai) helps decide whether Caveman belongs at a small tool boundary or whether a full runtime move has enough value to justify its cost.