> ## Documentation Index
> Fetch the complete documentation index at: https://docs.averta.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Checkpoints

> The runtime decision points Averta uses in an agent loop.

Checkpoints are the enforcement points around a model call. They decide whether the provider sees input, which tools the model can see, whether your app can execute a tool, whether tool output can re-enter the model, and whether final text can leave the system.

## Lifecycle

| Order | Checkpoint    | Runs when                                        | Valid decisions                              |
| ----- | ------------- | ------------------------------------------------ | -------------------------------------------- |
| 1     | Request       | Before provider execution.                       | `allow`, `block`, `restrict_tools`           |
| 2     | Tool exposure | During request preflight when tools are present. | `restrict_tools` as part of request decision |
| 3     | Tool call     | After the model requests a tool.                 | `allow`, `block`                             |
| 4     | Tool result   | Before tool output goes back to the model.       | `allow`, `block`                             |
| 5     | Output        | Before final text returns to your app or user.   | `allow`, `block`, `rewrite`                  |

Tool exposure is listed separately because developers need to reason about it separately, but it is delivered as a request checkpoint decision.

## Request

The request checkpoint runs before the upstream provider call.

The SDK normalizes the latest user input into an Averta payload. For supported [images and rich media](/concepts/images-and-rich-media), it sends image data separately from text.

If the request decision is:

* `allow`: the provider call continues.
* `block`: the wrapper throws before the provider call.
* `restrict_tools`: the wrapper removes blocked tools, then continues if the request itself is not blocked.

## Tool Exposure

Tool exposure controls the tool list sent to the provider. Configure it from the [tool exposure policy](/dashboard/tool-exposure-policy) page.

Example: a support agent may expose `search_docs` but hide `send_email` when a request looks risky. The model can still answer or use safer tools, but it cannot choose the hidden tool because it never sees it.

The wrapper also sanitizes forced tool-choice settings when the requested tool was removed.

## Tool Call

The tool-call checkpoint runs after the model asks for a tool and before your app executes it.

This is the checkpoint that protects side effects:

* sending email
* creating tickets
* changing account state
* running shell or browser actions
* calling external APIs

If a tool-call decision is `block`, the wrapper throws and your app should not execute the tool.

## Tool Result

The tool-result checkpoint runs when your app sends tool output back into the model loop.

Treat tool output as untrusted input. Search results, HTML, ticket comments, emails, database rows, and API responses can carry prompt injection or unsafe instructions.

If a tool-result decision is `block`, the continuation request is not sent to the provider.

## Output

The output checkpoint runs on final model text.

For non-streaming calls:

* `allow` returns the original provider result.
* `block` throws before the result reaches your app.
* `rewrite` asks the provider for a safer answer, then checks the rewritten answer with `rewrite_attempt: 1`.

For streaming calls, behavior is stricter. OpenAI streaming output checks are supported with limits, but streaming rewrites fail closed. Anthropic streaming is not supported in the current wrapper. See [fail-closed behavior](/concepts/fail-closed-behavior) for how wrappers handle unsupported paths.

## Provider Coverage

| Checkpoint           | OpenAI wrapper   | Anthropic wrapper |
| -------------------- | ---------------- | ----------------- |
| Request              | Yes              | Yes               |
| Tool exposure        | Yes              | Yes               |
| Tool call            | Yes              | Yes               |
| Tool result          | Yes              | Yes               |
| Non-streaming output | Yes              | Yes               |
| Streaming output     | Yes, with limits | No                |

## If a Checkpoint Event Is Missing

Use this table when you expected a decision in [Events](/dashboard/events), but one checkpoint is absent. A missing event usually means that stage did not happen in the provider flow, the call used an unsupported method, or the client was not wrapped at the point where the provider call happened.

| Expected event        | Check                                                                                          |
| --------------------- | ---------------------------------------------------------------------------------------------- |
| Request               | Confirm the client is wrapped and the call uses a supported provider method.                   |
| Tool exposure         | Confirm the request actually includes tools.                                                   |
| Tool call             | Confirm the model returned a provider-native tool call.                                        |
| Tool result           | Confirm the continuation sends provider-native tool-result content through the wrapped client. |
| Output                | Confirm the response is final text and does not still contain tool calls.                      |
| Dashboard correlation | Pass `conversationId`, `requestId`, or `traceId` in `requestContext`.                          |

## Next Steps

<CardGroup cols={2}>
  <Card title="OpenAI" icon="wand-magic-sparkles" href="/openai/overview">
    See checkpoint coverage for OpenAI.
  </Card>

  <Card title="Anthropic" icon="sparkles" href="/anthropic/overview">
    See checkpoint coverage for Anthropic.
  </Card>

  <Card title="Events" icon="activity" href="/dashboard/events">
    Investigate checkpoint decisions in the dashboard.
  </Card>

  <Card title="Decisions" icon="git-branch" href="/concepts/decisions">
    Understand decision outcomes.
  </Card>

  <Card title="Images and rich media" icon="image" href="/concepts/images-and-rich-media">
    See current multimodal request support.
  </Card>
</CardGroup>
