Budget enforcement at the middleware level — has anyone explored this?

[Albert M (amavashev)]

The README notes: "Enforce boundaries at the tool/sandbox level, not by expecting the model to self-police."

Agreed — but there's one enforcement problem that's hard to solve at the tool level: concurrent agents sharing a budget.

Two sub-agents check the same balance, both see enough, both proceed. A per-tool check can't prevent this without atomic cross-agent coordination.

The pattern that works: reserve estimated exposure before execution, commit actual usage after, release the remainder on failure. Fits naturally into the middleware lifecycle (before_tool_call → execute → after_tool_call) but the coordination has to live outside the agent process.

Has anyone tackled this on deepagents? Curious whether the middleware system is flexible enough or whether this needs to be a separate server-side concern.

For context, I built an open protocol for this: https://runcycles.io/ — but genuinely interested in how others are approaching the coordination problem.

[Yokubjon (yakubka)]

Budget enforcement at the middleware level is possible and worth exploring. The most practical approach I have seen is to wrap the model client in a middleware that tracks token usage across turns and raises an exception or returns a canned "budget exceeded" response when the cumulative spend crosses a threshold.

Here is a minimal sketch:

from deepagents import Middleware, ModelRequest, ModelResponse

class BudgetMiddleware(Middleware):
    def __init__(self, max_tokens: int):
        self.max_tokens = max_tokens
        self.spent = 0

    async def run(self, request: ModelRequest, call_next) -> ModelResponse:
        if self.spent >= self.max_tokens:
            raise RuntimeError(f"Token budget of {self.max_tokens} exceeded ({self.spent} used)")
        response: ModelResponse = await call_next(request)
        if response.usage:
            self.spent += response.usage.total_tokens
        return response

A few things to think about:

1. The spent counter above is instance-level, so it is per-agent-instance. If you want per-user or per-session budgets, you need to key the counter by thread ID from the request context.

2. Raising inside middleware aborts the current turn. If you want a graceful degradation (the agent replies "I have reached my token limit for this session") instead of an error, return a synthetic ModelResponse with a canned message rather than raising.

3. Input tokens vs output tokens: models charge differently for each. If you care about cost rather than raw token count, weight them by the per-token price before comparing against the budget.

Has anyone tried keying the counter by thread_id to get per-session limits? That seems like the most useful shape for a multi-tenant setup.

[Sergey Bolshchikov (bolshchikov)]

We've implements soft and hard limits of tokens per turn that resets on every turn.