Skip to content

Innovation

AI Load Testing With a French LLM: OctoPerf MCP Meets Mistral Vibe

When we released the OctoPerf MCP Server, most teams connected to it straight from Claude.ai. Then we showed how to run the whole stack on-premise with a local model. But a question kept coming back from European teams: can we drive our load tests with a French LLM, hosted in Europe, instead of a US model? The answer is yes, and it takes about five minutes. Mistral Vibe, the assistant formerly known as Le Chat, now supports custom Model Context Protocol connectors, so you can point it straight at the OctoPerf MCP Server and start testing in plain French (or English).

OctoPerf MCP Server, Fully On-Premise: AI Load Testing With a Local LLM

When we released the OctoPerf MCP Server, it ran as a hosted endpoint at https://api.octoperf.com/mcp, and most teams connect to it straight from Claude.ai or Claude Code. But a recurring question came from banks, hospitals, defense and public-sector teams: what if nothing is allowed to leave our network, not even the prompt? This article answers that question with a full walkthrough.

We will stand up a 100% on-premise, air-gapped stack, and it only takes two things to install: OctoPerf Enterprise in Docker, and a local Qwen3 large language model running in LM Studio, which doubles as the Model Context Protocol client. By the end, you will drive your load tests in plain language from a chat window, with no API key, no cloud LLM and no outbound traffic.

Webinar Replay: OctoPerf AI and the New MCP Server for Performance Testing

Last Thursday, we hosted a webinar to unveil one of the most important innovations in OctoPerf's recent history: OctoPerf AI and our new MCP Server.

If you have been using OctoPerf for a while, you know that we are not the kind of company that follows technology trends for the sake of marketing. Over the past months, AI has become impossible to ignore. At every conference, every booth seems to promote an AI-powered solution.

We deliberately took a different approach.

Playwright Virtual Users: Load Testing What Real Browsers Actually See

This is the third post in our "Features Sitting Idle" series, where we shine a light on OctoPerf features that are already in your account but rarely used to their full potential.

Features Sitting Idle - Playwright VUs

"Your Application Loads Content Through JavaScript. Your Load Test Doesn't See It."

This is a blind spot many teams discover too late. Tests pass, metrics look fine, yet real users report slowness or errors after a release.

The root cause is almost always the same: the load test was built against the HTTP protocol layer, but the user pain happens in the browser, above that layer.

Designing a Token-Efficient MCP Server: the OctoPerf Approach

In the first two articles of this series we showed what the OctoPerf MCP Server does. This one is for the builders: how we designed it, and specifically how we kept its token cost under control.

Because here is the thing nobody tells you when you start writing a Model Context Protocol server: the hard part is not exposing your API to an LLM. The hard part is not exposing too much of it. Every byte a tool returns lands in the model's context window, where it costs money, adds latency, and dilutes the model's attention. A server that naively mirrors a REST API produces an agent that is expensive, slow, and confused.

This article walks through the five patterns we applied to avoid that fate. None of them is specific to load testing: if you are building an MCP server for your own product, they should transfer directly.