---
title: "Caveman vs Mastra: agent runtime, processors, and cost evidence"
description: "Mastra provides a TypeScript framework for agents, workflows, memory, and application development. Caveman can attach a native processor to an existing Mastra agent for usage observations and an expli"
canonical: https://caveman.so/compare/mastra
last-updated: 2026-09-07
---

# Caveman vs Mastra: agent runtime, processors, and cost evidence

Mastra provides a TypeScript framework for agents, workflows, memory, and application development. Caveman can attach a native processor to an existing Mastra agent for usage observations and an explicit request transformation hook. Mastra still runs the agent.

Keep the framework that already fits your application. Add Caveman when its usage contract or model boundary solves a specific problem. A full move to Caveman's own agent definition is a larger choice with different migration work.

## Responsibilities after integration

| Area | With the Caveman processor |
| --- | --- |
| Agent and workflow execution | Mastra retains ownership |
| Memory and application state | Existing Mastra configuration stays in place |
| Provider calls, retries, and cache behavior | Remain native |
| Usage observations | Caveman reads the evidence available at processor hooks |
| Request transformation | Runs only when supplied through the model boundary |
| Budget or routing policy | Not created by installing the processor |

[Mastra's documentation](https://mastra.ai/docs) covers its current framework. The [Caveman processor source](https://github.com/caveman-ai/agent-sdk/tree/main/packages/adapters/mastra) targets `@mastra/core@1.63.2` exactly. Use that version boundary when evaluating the integration.

## Why the processor goes in two arrays

Mastra exposes model-request hooks through input processors and stream, tool, and terminal hooks through output processors. The same Caveman processor belongs in both arrays for the supported observation path.

Adding it only on input can make the integration appear active while leaving response evidence unavailable. Adding a second independent processor instance on output is also different from the documented setup.

The [switching guide](/switch/mastra) shows the attachment while preserving existing processors. Order matters if another processor already changes context, so keep the initial Caveman boundary empty.

## Missing usage should remain visible

A response-cache hit is not a new provider call. Retryable failures can also be invisible at an incomplete hook. A useful cost record needs to preserve those distinctions.

Caveman's adapter prefers supported raw usage evidence and retains missing cache, reasoning, and total fields as unknown. It does not invent token zeros or a local dollar saving. Provider and model identity are required before usage can be attributed.

The pinned processor seam does not expose complete model-error and terminal run-error coverage. Keep Mastra's operational error reporting for those cases. An absent event is not proof that the run succeeded.

## Context efficiency starts with a concrete task

Find an agent that repeatedly receives a large search or database result. Hold its workflow, memory settings, model, and acceptance test constant. Then evaluate a single context transformation against the complete result.

Do not combine a memory rewrite, model change, and compression policy in the first experiment. If the candidate becomes cheaper, you need to know which change caused it and whether the final artifact still passes.

Caveman's boundary supplies a place for the transformation, not a ready-made policy. For coding agents outside your application, [the local CLI](/guides/coding-agent-setup) offers another path.

## Decide from support and results

The adapter is experimental and uncertified. Tracing, replay awareness, durable observation, and compilation are unsupported. Its source API also requires a newer Caveman SDK than the published npm package at this review.

Choose it for a bounded source-based evaluation when those limits fit. Keep Mastra when its runtime and developer workflow already serve the application. The useful outcome may be better evidence inside the stack you have, followed by one tested cost improvement.