---
title: "Add Caveman to an Arize Phoenix workflow"
description: "Keep Phoenix available while you evaluate Caveman. A local compression trial can run beside your current tracing setup. Moving observability or evaluation workflows to Caveman Platform requires privat"
canonical: https://caveman.so/switch/arize-phoenix
last-updated: 2026-09-07
---

# Add Caveman to an Arize Phoenix workflow

Keep Phoenix available while you evaluate Caveman. A local compression trial can run beside your current tracing setup. Moving observability or evaluation workflows to Caveman Platform requires private access and an agreed ingestion contract.

Do not assume an OpenTelemetry endpoint swap migrates Phoenix datasets, prompts, annotations, or experiments. Start with one application and one question the candidate should answer better.

## Record your current collection path

Inventory the application instrumentors, SDK initialization, collector, exporter protocol, endpoint, authentication, and resource attributes. Record whether your stack uses OTLP over HTTP or gRPC and how it assigns trace and span IDs.

Check for automatic instrumentation and manual wrappers around the same model client. Adding another wrapper can produce duplicates or change parent relationships. Save the working configuration before adjusting collection.

Use [Phoenix's documentation](https://arize.com/docs/phoenix) for the deployment and version you run. Keep local server storage and any historical exports available through the migration review period.

## Capture representative evidence

Choose one normal run, one retry, one streaming response, a tool failure, and a multi-step task. Retain the task's starting input and final result under your data policy.

Record the fields needed to connect the trace to the work: task ID, workflow, environment, model, provider, usage, timing, and status. Include parent span relationships. A set of disconnected calls may add up numerically while hiding why the task was expensive.

Save evaluation inputs, expected outcomes, scorer code, and prompt versions separately. Those assets have their own lifecycle and are not equivalent to trace spans.

## Test context reduction with a saved tool result

Install the local CLI and inspect a representative fixture:

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

Review the smaller view and verify that retained fields are useful. If a recovery handle is produced, use that actual handle to retrieve the original. Follow [the compression guide](/guides/prompt-compression) for the full sequence.

Next run a supported coding-agent trial:

```bash
caveman setup --install
caveman doctor codex
caveman codex
```

Compare a fresh direct run with the same task and model. Existing Phoenix instrumentation does not automatically cover a separate coding-agent process; connect the result through your established evaluation workflow or keep an explicit run record.

## Validate the Platform destination

Arrange private Platform access and confirm which source path is supported. If you already use LiteLLM, review [Caveman for LiteLLM](/switch/litellm). Use provisioned configuration rather than guessing an OTLP URL or credential scope.

Check a small staging batch against Phoenix and the application logs. Compare IDs, parent relationships, provider usage, cache fields, errors, and task attribution. Unknown usage or pricing should stay visibly unknown.

Confirm content collection, redaction, and retention. Metadata-only collection may support timing and usage analysis while leaving content-based investigation unavailable. Record that limit in the pilot acceptance criteria.

## Move consumers in order

Begin with one investigation or cost-review workflow. Keep prompt delivery and release evaluations in Phoenix until the candidate has proven their required behavior. Test a collector outage and check that the application follows its intended reliability policy.

Avoid permanently sending the same records to two billed destinations without a reason. After validation, remove duplicate collection deliberately and reconcile the overlap period before comparing totals.

## Restore the baseline if checks fail

Restore the saved exporter or instrumentor configuration. Launch the agent directly if the compression candidate regresses. Retain recovery data while any active candidate session still needs it.

Keep Phoenix history accessible until reviewers and automated jobs have moved. The [comparison](/compare/arize-phoenix) helps decide whether a full migration is useful or local Caveman already solves the cost problem.