Know what a change costs your latency before it ships.

Software change is accelerating. Nobody checks what it costs.

When code is written at machine speed, testing and performance limits have to be checked at machine speed too. DORA’s 2025 research already found that AI adoption is associated with increasing delivery instability.

The gate every change passes through

Available Every verdict above is computed live by Rhobound’s queueing model on a 12-service reference system at a 70 req/s peak. Roadmap The latency budget returned to the agent, and running Rhobound as a CI check and an MCP tool that agents call.

The performance gate, from traces to a verdict

It sits between “the change builds” and “the change is rolled out”, needs a few minutes of OpenTelemetry traces, and asks for no changes to your code.

1. Capture traces

   A few minutes of OpenTelemetry traces from your cluster: every request, or a head-sampled share, which Rhobound reads from the trace IDs. No code changes and no switches describing your system.

2. Infer the architecture

   Calls and their order, parallel fan-outs, replicas and routing, and per pod the worker count and own time, rebuilt from the spans.

3. Profile the change in your cluster

   The new image runs against the old one among live traffic, replaying your own arrivals with the pod’s own CPU request and placement, so CPU limits and contention show up in the profile.

4. Predict

   Latency change at every service, an SLO verdict, p99 before and after, lost headroom, and a certified breach when a service would pass 100% busy.

5. Verify

   After the deploy, the prediction is judged against the new traces, criterion by criterion. Each verified deploy calibrates the next prediction and sets its error range.

rhobound profile CAPTURE registry/auth:1.1
rhobound predict CAPTURE CAPTURE/profiles/*
rhobound verify  CAPTURE/rhobound/report.json AFTER

IMPACT    MODERATE
  checkout    93.5 -> 110.1 ms  (+17.8%)  p99 207 -> 239
  storefront  71.8 ->  78.3 ms   (+9.0%)  p99 206 -> 214
  capacity    180 -> 156 rps (-13%), bottleneck pricing -> auth

PER SERVICE      util          mean ms         change
  payments *     44% -> 55%    23.1 -> 33.3    +10.2 ms
  auth *         48% -> 64%    11.9 -> 18.3     +6.4 ms
  catalog        40% -> 40%    27.1 -> 27.1     +0.0 ms
  * changed image

Headroom over today's load: 81% -> 57%
Inferred from 686,104 spans: 10 services, 11 pods,
2 entry points. Nothing else was given.

• Deterministic and explainable. Closed-form queueing mathematics, not a black box. Same inputs, same answer, and every number traces to an input.
• Refuses instead of guessing. Contradictory data or inputs outside the validated range return a reason, not a number.
• Runs in your environment. A command-line tool that works on your traces and your cluster. Nothing has to leave it.
• Milliseconds for means. Mean predictions take milliseconds. Percentiles take seconds to minutes at high load.

Where it fits in your pipeline

Built to be audited

Criteria are declared before each run, tested on fresh cases, and the failures are published next to the successes. Every number says what it was measured on.

• Kubernetes cluster0.1%Gap between the profiled change and production’s on Online Boutique, after replaying production’s own traffic in the profile.
• Kubernetes cluster9 of 9Criteria passed with only 10% to 25% of requests traced. The sampled share is found from the trace IDs.
• Kubernetes cluster18 of 18Fresh Online Boutique deploys with composed p95 within 20% of what happened.
• Kubernetes cluster70 of 70Worker-pool sizes inferred correctly from traces alone, across every service capture.

396 automated tests lock the validated results. Accuracy figures are measured on benchmark applications on a Kubernetes test cluster, on public data from real systems and against independent simulation, and each is labelled. Validation on a customer’s production system is the design-partner milestone.

A missing gate in every delivery pipeline

Tests and security scans are standard gates in the pipeline. Performance is the missing one, and agents writing code at machine speed make it urgent. Rhobound is built to be that gate.

Why today’s tools don’t close it

How we grow

1. Design partners

   We backtest your last patch rollouts and incidents and show what Rhobound would have predicted. Each partner adds a measured record of predicted against deployed.

2. The pipeline

   A check in CI and a pre-rollout gate for progressive delivery, so every change gets a verdict without anyone asking for one.

3. The agents’ check

   A tool that coding agents call inside their loop. Clear results let cheaper models keep iterating; borderline ones escalate.

What compounds

• A validated, auditable model with a published error record for each kind of architecture.
• An inference engine that rebuilds an architecture from traces alone.
• In-cluster profiling that replays your own traffic, which sees the contention and CPU limits an idle benchmark misses.
• A per-cluster history: every verified deploy calibrates the next prediction and sets its error range, and every design partner adds to the record.

Where this goes

1. Now

   MVP with design partners

   • The rhobound command: profile, predict, verify
   • Backtests on partners’ real rollouts, with predicted against deployed quoted
   • A better first prediction on a new cluster, and the answer-size case: measuring what callers spend decoding a bigger response
   • Onboarding without custom hooks

2. Next

   The pipeline

   • CI check for GitHub and GitLab, and a rollout gate for Argo Rollouts and Flagger
   • Latency budget per call and per service
   • Validated change of p99, and burstiness measured from real traffic
   • Event-driven consumer lag and autoscaling

3. Then

   The platform

   • MCP server so coding agents call Rhobound inside their loop
   • Versioned architecture store with every change and its measured impact
   • Signed performance attestations next to image provenance
   • Admission policy: no rollout without a passing verdict

Team

• Sharvil Bhatt

  Founder

  Researches software supply chain security, secure systems architecture, and the trade-off between security and performance in real systems. First author in IEEE Open Journal of Vehicular Technology, reviewer for IEEE Transactions on Vehicular Technology, and speaker at KubeCon India and OpenSSF Korea.

  Profile

Questions