Conversation limits
max_messages blocks any request whose conversation exceeds a message count you
choose.
vulnetix ai-firewall policy guardrail cap-conversation \
--rule-type max_messages \
--action block \
--pattern 40 \
--priority 90 \
--enable
The --pattern is the integer cap. A request carrying more than 40 messages is
refused:
{
"error": {
"message": "request blocked by AI firewall policy: message count 41 exceeds limit 40",
"type": "policy_violation",
"code": "request_blocked",
"blocked_by": "cap-conversation"
}
}
Why you want this
An agent in a retry loop does not stop. It tries something, the tool errors, it tries a variation, the tool errors, and each turn carries the entire conversation so far back to the provider. Cost grows quadratically, and nobody notices until the bill arrives.
max_messages is the circuit breaker. Message 41 is refused, the agent surfaces an
error, and a human looks at it.
max_messages is
the only quantitative control there is, and it bounds the shape of a request, not
your spend.Choosing a number
Too low and you break legitimate long-running agent work — which is the whole point of a coding agent. Too high and the loop runs for an hour before it trips.
- Interactive chat: 40–60 is generous. Ordinary conversations do not get there.
- Coding agents: much higher. A Claude Code session doing real work legitimately runs to hundreds of messages. Start at 200–400 and raise it if you see false trips.
- Automated / CI agents: this is where the cap earns its keep. A CI agent has no human watching it. Set it as tight as the task allows.
If you cannot pick a number, run it at --action flag and look at what your actual
traffic does before you block on it.
What counts as a message
The number of messages in the conversation you send. It does not count:
- The system prompt — on the Anthropic surface the system prompt is a top-level field, not a message, and it is deliberately not counted. A cap of 40 means 40 messages, on every surface, consistently.
- Tokens. This is a message count, not a length limit. A single message can be enormous.
There is no token or byte cap. max_messages bounds how many messages a
request carries, not how big they are. One 5 MB message passes a cap of 40.
The only size limit is the gateway’s 8 MiB request-body ceiling, which returns a
413 and is a transport limit, not a policy.
Where to put it in priority order
Last. Give it a high priority number so it runs after your content rules:
--priority 90
A block short-circuits, so a max_messages rule at priority 1 would refuse a
runaway conversation without ever scanning it for secrets. You would lose the
signal about what was in it. Scan first, cap last.
Related
- Rollout — pick the number empirically with
flag. - Limitations & roadmap — why there are no budgets or rate limits.