Dispatch Studio is a desktop API workspace with a load tester and a JVM monitor in the same window. Scan a service, call it, put the calls in a suite and then under load — and switch to Observe to see the query it fired, the queue it published to, the log line it wrote and the object it left on the heap. A desktop agent does the steps no API reaches, and AI Ground answers questions about all of it with a model on your own computer.
Scan a source tree into catalogs, send any protocol, keep secrets in the OS keystore, and commit suites to your repository.
Turn the calls you built into a test plan, run it against an environment that allows it, and read what held and what bent — on a schedule if you like, with rules for what happens after.
One -javaagent flag on the service and the screens fill in: per-endpoint percentiles, the JDBC and broker calls behind them, the log, the live JVM, and heap dumps down to the object holding the memory.
Write the goal in your own words. The agent works through it with the mouse and keyboard, a stage at a time, each stage with its own limit, and stops the moment you tell it to.
Ask about your plans, runs, suites and catalogs, and read the answer beside the records it came from. The model runs in Ollama; nothing is sent anywhere.
For staging and production, run the APM server on your own hardware or in your own AWS account, and connect everyone's Studio to it.
Most API tools begin with an empty request and a URL you have to remember. Dispatch reads the routes out of the service's own source and hands you a catalog you can send straight away.
No running service and no OpenAPI document: Scan a project reads the controllers, works out the framework, and generates request bodies from the types the handlers take.
| Language | Frameworks |
|---|---|
| Java | Spring Boot, Play, JAX-RS, Quarkus, Micronaut |
| .NET | ASP.NET Core controllers and minimal APIs |
| Go | Gin, Echo, Fiber, Chi, Gorilla mux, net/http |
| Python | FastAPI, Flask, Django |
HTTP, GraphQL, WebSocket, server-sent events and gRPC share the same request pane; what changes is the middle. JSON is validated as you type, and the response shows its timing broken into DNS, TCP, TLS, first byte and download.
/books/{id} and ?id= are different things, so a catalog can be re-pointed.
POST built from the scan, answered 201 in 8 ms, the response as a tree you can query with JSONPath.A variable is {{name}}. Environments belong to the project and carry a colour, so production never looks like local. A variable marked secret lives in Windows Credential Manager — never in the workspace file, a backup, or the clipboard.
Copy as cURL and Copy as code write {{name}} in its place, so what you share keeps its structure and none of its secrets. Each environment also says whether load tests may run against it; none may until you allow it.
password is secret and never written to the workspace file.Assertions are declarative — status, time, a header, a JSONPath, the body — each with an operator and a value. Pre-request and post-response scripts handle what assertions cannot say: signing a request, computing a nonce, lifting a token out of a response for the next call.
Chaining is by name: a step in a suite reads the status, a header or the body of any step that already ran, as {{steps.post login.body.$.token}}.
A suite is setup, steps and teardown as a YAML file in your own repository, under .dispatch/suites/. It is reviewed in a pull request and travels with the branch. It is also how requests are put in order: a step reads any earlier step's response by its name, defaults are sent with every step, and Stop at the first failure does what it says. Diagram draws the steps and where each value comes from.
The Chrome extension records a real session — log in, do the thing, stop — and hands back a draft you review before it becomes a suite.
.dispatch/suites/Book catalogue smoke test.yaml.An OpenAPI or Swagger document from a URL or a file, a Postman collection, a HAR, or one pasted cURL command — into a catalog you can send straight away.
A local server on a port you choose, answering with the responses you recorded, so front-end work is not blocked on a service that does not exist yet. It never leaves your machine.
Documentation generated from your catalogs, and copied out as Markdown.
Every request you send, with its response, per project, across restarts.
Bring your own Anthropic key: the assistant explains a response and suggests tests for it. It asks before anything is sent, and Settings says exactly what it sends and what it holds back.
Ctrl K for the rest: scan, import, environments, the Fake API, copying a request as code, generating the documentation, the theme.
The requests you built are the load test. A plan is a file in the repository beside the suites, it runs only against an environment that allows it, and it ends with a verdict against conditions you set before it started.
A plan is written in five steps down the side of the editor — The numbers, Once at the start, Main, Passes when and After the run — and saved as .dispatch/load/<name>.yaml. Choose Smoke to ask whether it works at all, or Load to ask whether it holds a busy day, bends, or leaks over hours.
A run draws response time as the users ramp up, requests a second and errors, then a table for each API and a verdict against the plan's own conditions. It also says whether this computer kept up: a load generator that cannot keep pace is measuring itself, not your service.
With Observe connected, On the server shows what the application was doing while the run went on.
A plan is pinned to one environment, and that environment must allow load tests. One named like production asks for its name to be typed before every run, and is never run on a schedule.
Every day, or on the days you choose, at a set time. The computer is kept awake from ten minutes before until the run ends. Studio has to be open — minimised is fine — and a missed run is written into the list rather than run late.
Rules such as if the run fails, notify me, or if p95 is worse than last run, run an agent with the run's figures filled in. Each run's report can be saved as PDF or Excel into one folder for passed runs and another for failed ones.
The request you just sent and the database call it caused are the same event. Reading them in two tools means correlating by timestamp and hope — so the monitor is in the same window, behind the same requests. How it connects
Every endpoint's throughput and latency — p90, p95, p99 and the worst call — from histograms recorded per call inside the JVM and summed, never averaged across a window. The tail survives the trip to the desktop. Open an endpoint for its own history, with every collector stop marked under its latency.
Endpoints the scan found but nobody called are listed too, so No traffic is an answer rather than an absence.
Endpoint metrics are always on and cost next to nothing. Seeing inside a handler means sampling the threads serving requests, so it runs only when someone asks, for five minutes, and stops on its own.
Each application registers with its own key and reports on its own. Switch between them in the Observe column; each keeps its own history, errors and log.
The Runtime screens read the JVM behind the traffic. Findings opens on what is wrong now — threads deadlocked, a heap that is not coming back down, old collections costing more than young ones, a pool nearly full — each one linked to the screen that shows it.
Open an .hprof file, or send one straight from Objects on the heap, and the APM server analyses it — the parsing happens there, not on your desktop. The Dominator tree shows what each object owns: what only it keeps alive, biggest first, where retained is what would be freed if it went.
Why is it alive? walks the path from a GC root to the object, field by field, with weak, soft and phantom references left out unless you ask for them, the root's kind spelled out — a local variable on a thread's stack, a class the JVM itself keeps loaded — and any static field on the way named. Compare sets a dump beside an earlier one: what grew, where the growth is held, and what shrank.
Rules on what matters — what to watch, the measure, the threshold, the window it is measured over, and how many checks in a row confirm it — delivered to an email list or PagerDuty, each target checked with a test send. A firing alert can be silenced for an hour.
An application on several hosts reads as one, or host by host. The Overview's By host table shows each instance's traffic, heap, CPU and last report; one that stopped reporting stays listed, greyed, for 30 days so its logs can still be read.
Data stores, messaging and external calls can each be switched off while the JVM runs: the woven bytecode comes out and the methods go back to what they were.
Every number here came off a real service — a Spring Boot bookstore on a heap of a few hundred megabytes, with an audit cache deliberately left switched on, under steady traffic for about twenty minutes. This is the path the screens walk you down.
GET /api/books/:id answers in under 60 ms ninety-five times out of a hundred. Its slowest call took 6.7 seconds — more than a hundred times its own p95. A mean would have hidden it completely.
Every statement stayed under 15 ms at the 99th percentile. Connection acquisition is its own row: normally it takes 10 microseconds, and once it took 2.39 seconds — a thread waiting for the pool while the threads holding its connections could not run. The row also says where it was called from: 1.16 acquisitions per GET /api/books/:id, one request holding more than one connection.
A pool stalls when the threads holding connections are stopped. Seven old-generation pauses took 0.9 s — 134 ms each; all 116 young collections together took 0.6 s, 5 ms each. Old-generation collections that keep arriving are not a tuning problem — something is surviving them.
After each major collection the agent takes a class histogram of what is left. Over eleven minutes byte[] gained 90 MB while the number of arrays fell by 198,330 — so the ones being kept are the large ones, and 119 MB of them are still on the heap. Retained, not churn: something is keeping a copy of each.
![What keeps surviving, from 7 samples over 11 minutes: byte[] the worst offender at 500 MB an hour, 119 MB still on the heap after growing 90 MB, and grown after 4 of 6 collections, well ahead of java.lang.reflect.Method and the rest.](assets/50-runtime-leak-suspects.webp)
A histogram can only ever say byte[]. Retained size says who would free it: walk the dominator tree and one application object holds 85.6% of the reachable heap — a Spring singleton with an unbounded list of view records, each keeping a copy of the page it served.
![The dominator tree of a bookstore heap dump: ViewAuditService retaining 292 MB with a shallow size of 32 bytes, through an ArrayList and an Object[] that owns 72,096 ViewAuditService$ViewRecord entries of 4.1 KB each.](assets/51-heap-dominator-tree.webp)
Each answers something people ask out loud during an incident. Observe groups them the same way, in two rows above the screen: what the service did, the runtime that did it, and what wakes somebody up.
Some work only happens in a window, in a desktop program with no API. An agent in Workflows is given the goal in your words and does it with the mouse and keyboard, a stage at a time, on Claude or on a model running on your own computer.
An agent is a goal — with {{values}} you fill in at each run — and the stages it takes to get there, generated from the goal or written by hand. Each stage has its own limit of attempts, can open a program before it starts, and says whether it needs the model at all. The stages, values, attachments and model are checked first, and a run does not start until every check passes.
Observe can collect an application’s warnings and errors every few hours into a file of their own. When that window held something, it starts a desktop agent and hands it the figures: how many errors, which application, how far back it looked, and where the file is.
The agent is one you wrote. These six stages open a terminal in the checkout, give Claude Code the digest, wait while it reads the code the digest points at, ask for the tests that cover what it changed, and ask it to raise a pull request — then write the address of that pull request to a file.
A stage is a sentence. The agent works through them in order, and you can untick one to skip it without deleting it. Nothing here is a macro: each stage is read by the model, which looks at the screen and decides what to do next.
Which is also why the panel at the foot of the screen says what it says. While it runs, the agent has your real mouse and keyboard — so it tells you to close anything private first, and gives you two ways to stop it before you ever press Run.
The model is told that text on the screen is not an instruction, never to type a password, and to stop before it sends, submits, buys, deletes or changes a setting.
While it runs, an amber frame goes round the screen. Press Ctrl+Alt+Q or push the mouse into the top-left corner, and it stops before its next action.
Each run keeps its log and the last screen of every attempt, for 14 days and up to 50 runs an agent. An agent has no clock of its own: you press Run, or something else starts it — a Load rule after a run, or a log digest that found warnings.
AI Ground answers questions from what Dispatch already holds: your test plans and their runs, your suites and what they did, and the endpoints in your catalogs. The model runs in Ollama on your computer, and nothing is sent anywhere.
A question is matched against the records first; then a local model reads the best of them and answers, citing each one as [1]. The records it read are listed beside the answer, and one is marked as used only if the answer cited it, so a claim with nothing behind it shows as one.
With no model set up, the same question returns the matching records, ranked. Observe's readings and response bodies come in a later version.
Ask for a load test plan and you get a plan to read, not a paragraph: every call is one the project really has, runaway numbers are brought within limits, the environment is Dispatch's own, and nothing is written until you press Create the plan.
Ollama on 127.0.0.1, and nothing else. The Anthropic key the assistant uses is never used here.
A record of each run, plan, suite and catalog, in Dispatch's own folder on this computer. Credentials and secret values are taken out before anything is written, and Forget everything indexed clears the lot.
Every version below is one the integration has actually been run against; a range was run version by version, on every Java from 8 to 26 that the library itself supports. Where something is supported in the code but has not yet met a live system, the table says so.
| Java and Scala | |
| Spring Boot@RestController and @RequestMapping, bodies from the DTOs | VerifiedSpring Boot 3.3.4 · Java 21 |
| JAX-RS and Jakarta REST@Path with @GET and @POST, jakarta.ws.rs or javax.ws.rs | Verifiedjakarta.ws.rs |
| Quarkus, Micronaut@Path, and Micronaut’s @Get and @Post | Recognised |
| Play Frameworkconf/routes | VerifiedScala 2.13 |
| C# | |
| ASP.NET Core controllers[ApiController] with attribute routes | Verified.NET 8 |
| ASP.NET Core minimal APIsMapGet, MapPost and the rest | Tested |
| Go | |
| net/httpIncluding Go 1.22 method patterns | VerifiedGo 1.23 |
| Gin, Chi, Gorilla mux | Tested |
| Echo, Fiber | Recognised |
| Python | |
| FastAPI | VerifiedFastAPI 0.115 · Pydantic 2.9 |
| Django | Tested |
| Flask | Recognised |
| Import | |
| OpenAPIFrom a URL or a file | 3.0 · 3.1 |
| Swagger | 2.0 |
| Postman Collection | v2.1 |
| HAR | 1.2 |
| cURLOne command, pasted | |
| Send | |
| HTTP, GraphQL, WebSocket, server-sent events, gRPCGraphQL with introspection; gRPC from a .proto | |
| Copy as code | |
| cURL, JavaScript, Python, Go, Java, C#fetch and axios · requests · net/http · java.net.http · HttpClient | |
| Runtime | |
| Java 8 and laterThe agent is Java 8 bytecode, with no dependencies of its own | VerifiedJDK 8 · 11 · 17 · 21 · 26HotSpot |
| Web transactions | |
| Spring Boot ActuatorMicrometer’s http.server.requests; percentiles need micrometer-registry-prometheus | VerifiedSpring Boot 3.3.4 · Micrometer 1.13.4 |
| Any service with a Prometheus request histogramhttp_request_duration_seconds, as Go and Python services publish it | TestedGo 1.23 · client_golang 1.19 |
| OpenTelemetry HTTP metricshttp.server.request.duration | Tested |
| Data stores | |
| JDBC, any driverPostgreSQL, MySQL, MariaDB, SQL Server and Oracle named from the driver | VerifiedH2 1.4.200 – 2.4.240PostgreSQL 42.2.5 – 42.7.13 |
| HikariCPConnection waits and pool use | Verified3.4.5 – 7.0.2 |
| Redis through LettuceCommands, memory and hit rate; the async and reactive APIs, Jedis and Redisson not yet | VerifiedLettuce 5.0.5 – 7.7.0 |
| MongoDB Java driverThrough the driver’s own command and pool listeners | Verifiedsync driver 3.12.14 – 5.11.1 |
| Messaging | |
| RabbitMQamqp-client publish, Spring AMQP listeners; consuming with the plain client not yet | Verifiedamqp-client 4.0.3 – 5.35.0Spring AMQP 2.2 – 4.1 |
| Apache KafkaProducer sends, Spring Kafka listeners, consumer lag; a plain consumer’s poll and Kafka Streams not yet | Verifiedkafka-clients 2.4.1 – 4.3.1Spring Kafka 2.5 – 4.1 |
| JMS and Jakarta Messagingjavax.jms and jakarta.jms; ActiveMQ, Artemis, IBM MQ, Solace and TIBCO EMS named; MessageListener and JMSContext not yet | VerifiedActiveMQ 5.15 – 5.19 · 6.0 – 6.3Artemis 2.19 – 2.57 |
| Amazon SQSAWS SDK for Java 2.x, the synchronous client; the async client not yet | VerifiedAWS SDK 2.17 – 2.54 |
| Outbound HTTP | |
| Spring RestTemplate | VerifiedSpring Framework 4.3 – 7.0 |
| Apache HttpClient4.x, and 5.x classic | Verified4.3.6 – 4.5.145.0.4 – 5.6.1 |
| OkHttp3.x, 4.x and 5.x | Verified3.12.13 – 4.12.05.1.0 – 5.5.0 |
| JDK HttpClient, HttpURLConnection, WebClientAnd the async clients of OkHttp and Apache | Not yet |
| Logs | |
| LogbackLevel, logger, thread, context and stack traces as fields | Verified1.1.11 – 1.5.34 |
| Anything printing to standard outputKept as text, the level read from the line | Tested |
| Log4j2, java.util.logging | Not yet |
The agent is the only piece inside your process. It dials out — nothing in your application's network has to accept a connection — and the receiver keeps history on disk, so the screens still have yesterday in them after the service has gone.
Flags, system properties and log-context values whose names read like credentials are masked inside the application, before anything is reported.
The agent makes outbound calls only. The receiver attaches to a JVM only when you explicitly ask it to.
Your machine talks to your receiver. No account, no cloud, no telemetry. Two things send anything further, both started by you and both asking first: the assistant, and a desktop agent on a Claude model. AI Ground never does.
On one developer's machine the receiver runs beside Studio. For staging and production, a team runs the APM server on its own hardware or in its own AWS account, and everyone's Studio connects to it. Nothing leaves your network.
The agent targets Java 8 bytecode, so it attaches to anything from 8 upward — at startup, or, when the receiver is on the same machine, to a JVM that is already running, from the Runtime screens.
java -javaagent:/opt/dispatch-agent.jar=\ dispatch.apm.agent.report.url=http://127.0.0.1:8090,\ dispatch.apm.agent.report.key=dsk_… \ -jar your-service.jar
Every setting is optional, in the agent argument, a system property, an environment variable or a properties file.
# /etc/dispatch-apm-agent.conf dispatch.apm.agent.datastore.enabled=true dispatch.apm.agent.messaging.enabled=false dispatch.apm.agent.external.enabled=true # the Logs screen dispatch.apm.agent.logs.enabled=true # leak radar dispatch.apm.agent.radar.interval.minutes=15
Questions about running Studio, about the APM server across shared environments, or about anything on this page. It reaches one person, and he answers.
One installer with its own runtime. It opens on a sample project, so there is something to send before you have scanned anything of your own.