#How Silex Data cut AIOps agent costs by up to 32% with Pydantic Monty

#The challenge: 400+ MCP tool calls per task, each one returning a wall of text

IT operations agents take hundreds of steps to finish a task. Silex's agents connect to the third-party observability tools its customers already run through those tools' MCP servers. They hand the changes themselves to Ansible Automation Platform, so the agent never needs direct access to production.

Each of those MCP servers can return long output, and the length grows with the environment. An enterprise estate has a lot of servers. Some Silex agents make more than 400 tool calls for a single task. With direct tool calling, every result lands in the model's context in full, and the model pays to read it again on each later turn.

Cost climbs with every turn, and so does the chance a task fails. Context fills with monitoring output when the model needed one line of it, the largest requests balloon, and some tasks never finish.

#The solution: code mode, with every MCP call running from Python in Monty

Pydantic Monty is an open-source interpreter built with Rust for running the code agents write. It is not a container or VM, and nothing boots per run. Applications written in Python, JavaScript/TypeScript, or Rust can embed it. Agent code in Monty can call only the functions Silex exposes, with no files, network, or secrets unless Silex grants them, and Silex's tool functions keep their own access. Adding code mode inside Silex's existing sandbox did not widen the agent's reach.

Silex exposes two tools to the agent: find_tool, which looks up the MCP tool the agent needs, and run_code, which runs the Python the agent writes. Every MCP tool call happens inside that code, so the agent filters and transforms each result before anything reaches the model. Lewis describes the setup, including how the gateway checks and audits every tool call a program makes, in Silex's blogpost, Cutting AIOps agent cost by a third with code mode and Pydantic Monty.

"We use Monty to expose run_code and find_tool, and all of our MCP tool calls go through run_code so the agent can transform and filter what it needs. That's where we got most of our token savings and a lot fewer turns."

Derek Lewis, CTO at Silex Data

A monitoring query over a large estate no longer costs the whole estate's worth of tokens. The agent's code loops over the result, keeps the lines that matter to the incident, and returns a short summary. Several calls that used to take several turns run as one program.

"Monty has been a big part of how we got our agents' token use and turn counts down."

Derek Lewis, CTO at Silex Data

#The results: 26 to 32% lower cost and every test incident solved

Silex tested direct tool calling against code mode on five incident types (a stopped service, a full disk, a bad certificate, an application setting, and a database refusing connections) in two environments: a small lab and a large estate.

26 to 32% lower cost. Across the five incidents, code mode cost $2.96 against $4.36 for direct tool calling on the small lab, and $3.56 against $4.78 on the large estate.

Cheaper on every incident. Code mode cost less and read fewer tokens on all ten incident pairs: 4.33M against 6.66M on the small lab (35% fewer), and 5.53M against 7.75M on the large estate (29% fewer).

Smaller peak requests. Code mode's largest request stayed under 85K tokens. Direct tool calling reached 144K.

Every incident solved. Direct tool calling failed one incident in each environment: the full disk on the small lab and the application setting on the large estate. Code mode solved all ten.

Lewis summed up the results when he shared them publicly:

"We had a 30% reduction in tokens with our agents after we implemented a code mode with Monty. Also allowed us to scale to handle some tools that produce some very long output, so now the agent can just write filtering code in code mode to deal with it. Monty is an awesome solution!"

Derek Lewis, CTO at Silex Data, on X

#How Silex's feature requests became Monty pull requests

Lewis reviewed Silex's agent transcripts and sent the Monty team the standard-library features that agent-written monitoring code reached for most: datetime.fromtimestamp() for the epoch timestamps that Prometheus, Loki, and most monitoring APIs return, ipaddress for subnet checks, zoneinfo for change windows in a customer's local time, urllib.parse, fnmatch, default= in json.dumps(), raise from, bound methods as values, generator expressions that are real iterators, and exceptions that subclass Exception. The Pydantic team shipped fixes for Silex's feature requests within hours. By the next morning seven of the ten had a pull request open, fnmatch and json.dumps(default=) had merged, and the other three, generators, class inheritance, and bound methods, were already being worked on. Silex's agents and everyone else's get the same coverage.

#Key takeaways

• Filter tool output in code before the model reads it. When an MCP server can return the state of an entire estate, let the agent's program reduce it first. Silex's token savings came from this step, and it kept every request under 85K tokens.
• Give agent code an interpreter, not another machine. The short programs Silex's agents write to call and filter tools need isolation, not a full OS. Monty runs them inside the environment Silex already had, and agent code reaches only the tools Silex exposes.
• Smaller contexts can mean fewer failed tasks. Direct tool calling failed one incident in each environment. Code mode, with the same models and the same tools, solved all ten.
• Test code mode against direct tool calling on your own incidents. Silex ran the same five incidents in two environments of different sizes and compared cost, tokens read, peak request size, and outcome. That pairing isolates the effect of code mode before anything changes in production.

Want your agents to run the Python they write? Read about Pydantic Monty or get started in the docs.

#FAQ