What's new in BreakTest

BreakTest includes an MCP (Model Context Protocol) server in the free tool. A connected agent, such as Claude Code, Codex, or opencode, can read the test plan structure, run validation, edit elements, and rerun checks in a closed loop. Because the agent sees actual responses, its fixes are based on what the server returned rather than inference from the script alone.

The tool set includes structural operations for cloning, moving, and deleting complete subtrees. They use the same code paths as GUI editing, so repairs preserve element properties instead of reconstructing them from partial data.

Repair runs are transactional: a failed batch is rolled back through undo, a pre-run backup can be restored explicitly, and an incomplete repair reports itself as blocked rather than as finished.

AI Repair is part of the free tool rather than the platform tier because script correlation and repair is where the most engineering time is lost, including on purely local tests.

BreakTest supports AI Repair through Claude Code, Codex, opencode, Pi Code, Gemini CLI, and Cursor Agent. Each harness can inspect the plan, validate it against real responses, make changes, and rerun until the journey works or the repair reports a clear blocker.

Each harness has setup guidance for its own model, authentication, and execution settings. BreakTest detects which tools are installed, puts available harnesses first, and keeps the repair workflow inside the desktop application instead of requiring a manually assembled command line.

Two modes of operation. Full repair: the agent validates the plan, reads the failures, repairs correlation and selectors, and verifies by rerunning. Targeted instructions: state a specific change directly, such as randomizing a field, fixing the extractor on the login response, adding pacing to a transaction, or writing a Groovy helper for request signing.

Targeted mode exists because experienced engineers usually know precisely which change they want; the instruction replaces navigating the GUI to apply it manually.

The Groovy script editor includes contextual AI chat. Describe what the script should do, or ask about the code already there, and the AI can create a complete script, finish an incomplete one, explain its behavior, improve its structure, or diagnose and fix a failure.

The chat works alongside the open script and its BreakTest context, so there is no need to copy code into a separate tool. Review the proposed change and apply it directly to the sampler, assertion, extractor, or helper you are editing.

When AI Repair runs against a plan open in the GUI, each change is highlighted in the tree as the agent makes it, showing which elements were touched and in what order. The repair can be followed while it happens instead of being reconstructed from a file diff afterwards.

All AI edits pass through the normal undo history, so any change the agent makes can be reverted step by step, exactly like a manual edit.

Scripting conventions, including transaction naming schemes, think-time placement, preferred extractor styles, and variable naming, can be stored in a file alongside the test plan, comparable to a CLAUDE.md for a codebase. The agent reads it before editing, so its changes follow the team's standards, and the conventions are versioned with the repository rather than depending on who runs the repair.

Without this, an agent produces edits that are technically correct but inconsistent with the existing suite, which then require manual rework.

BreakTest supports HTTP/2 through Apache HttpClient 5. Each connection negotiates the best protocol automatically: HTTP/2 when the endpoint supports it, with a seamless fallback to HTTP/1.1 when it does not. The same test plan works with both.

The Parallel Controller lets one virtual user issue 100 or more requests concurrently. With HTTP/2, those requests can be multiplexed as independent streams over the same connection, as HTTP/2 was designed to work, instead of opening a separate connection for every request.

This produces more realistic browser and service traffic. Your test exercises HTTP/2 concurrency, connection reuse, header compression, and the server's HTTP/2 code path under load, while remaining compatible with HTTP/1.1-only endpoints.

BreakTest 2026.07.19 adds native HTTP/3 sampling over QUIC through the Java 26 HTTP client. Select HTTP/3 explicitly for an HTTP/3-only request, or allow TCP fallback when an endpoint does not accept QUIC. Compatible default-protocol samplers can also follow the browser pattern: start over HTTP/2 or HTTP/1.1, discover HTTP/3 through the server's Alt-Svc response, and upgrade subsequent requests.

The negotiated HTTP version, destination endpoint, and TLS version are stored with the sample result, so HTTP/3 traffic stays visible in the Results Tree and reports. Clients are reused per virtual user, requests can be interrupted cleanly, and QUIC timeouts use BreakTest's concise network error reporting.

HTTP/3 requires Java 26. BreakTest itself and the standard HTTP samplers remain compatible with Java 21 and newer; on Java 21–25, an HTTP/3 sampler warns once and safely falls back to negotiated HTTP/2 or HTTP/1.1. This keeps the same JMX plan portable across load generators while making QUIC available wherever the runtime supports it.

HTTP/3 support is beta. Proxies, multipart uploads, Digest and NTLM authentication, the HTTP Cache Manager, JMeter client-certificate keystores, and lenient certificate trust are not yet available on the QUIC path. BreakTest rejects unsupported HTTP/3 combinations clearly instead of silently ignoring them.

Apache JMeter's built-in HTTP sampler does not support HTTP/3. BreakTest brings QUIC into the familiar JMeter test-plan, virtual-user, assertion, listener, and reporting workflow rather than limiting HTTP/3 testing to a command-line request benchmark.

BreakTest reports connect and response timeouts as a single line stating what timed out, against which endpoint, and at what configured limit. JMeter logged every timeout with a full Java stack trace. That added no useful information because the timeout limit and endpoint are the relevant facts, and it made logs and the results tree difficult to read during a run with many failures.

Unexpected errors still include full detail. The distinction keeps expected load-test outcomes (a slow system under test) visually separate from actual tool or script failures.

BreakTest includes native UDP Request and UDP Receiver samplers. UDP Request supports request/response and fire-and-forget datagrams, local address and port binding, configurable timeouts, named per-user socket reuse, and optional handling of unreachable destinations. UDP Receiver reads subsequent datagrams from a named socket and can treat receive timeouts either as successful no-content samples or as failures.

Payloads are entered as UTF-8 text, hexadecimal, or single-byte text via a format selector; custom encodings can be implemented against the native UDPTrafficCodec extension point. Oversized datagrams are validated before sending, truncation is detected on receive, buffers are reused, and named sockets are isolated per virtual user, including under parallel ForEach and Fork execution.

JMeter has no built-in UDP support; testing UDP protocols required third-party plugins with their own dependencies and limited integration with the execution model.

BreakTest decodes Brotli and Zstandard response encodings natively, in addition to gzip and deflate. JMeter 5.6.3 does not decode either format, although CDNs and modern services increasingly use them.

With native decoding, assertions and extractors operate on the actual response body rather than compressed bytes, and recorded response sizes remain accurate.

Measured scenarios show roughly 50–80% lower memory use and up to 50% lower CPU use than JMeter 5.6.3 on the same test plans, depending on the plan and workload. The reduction is the combined effect of several engine changes: lazy response decompression, response retention modes, lightweight test-plan cloning, per-thread buffer reuse, header-merge reuse, bounded HTTP/2 reactors, and lazy diagnostics collection.

The practical result is more virtual users per load generator before garbage-collection pauses begin to distort latency measurements, and fewer machines for the same load. Generator resource usage affects measurement validity as well as cost: a generator running near CPU saturation adds its own latency to every sample it records.

BreakTest stores response bodies in their compressed form and decompresses only when an assertion, extractor, or viewer actually reads them. JMeter decompressed and buffered every response unconditionally, spending CPU and heap on data that was often never inspected.

Retention modes additionally control what is kept per response: the full body, the compressed body, failures only, or an MD5 checksum in place of the body. Full retention suits scripting and debugging; failures-only suits load runs; checksums suit soak tests where the only question is whether content changed.

JMeter creates a full deep clone of the test plan for every virtual user. At high thread counts, those complete copies consume substantial heap before the test has sent a request.

BreakTest uses a lightweight clone that shares immutable plan data while keeping each virtual user's runtime state isolated. The test behaves the same, but requires significantly less memory per user and creates far less allocation pressure during startup.

BreakTest requires Java 21 or later. The raised baseline removed a large amount of version-compatibility code and directly enables current JVM features, most visibly virtual threads for virtual-user execution and embedded resource downloads. On virtual threads, a blocked thread costs almost nothing, which fits a load generator's workload profile of many concurrent blocking I/O operations.

Virtual threads are applied selectively rather than globally: code paths that pin carrier threads can perform worse on virtual threads, so they are used where blocking-I/O concurrency dominates.

Java 21 remains the minimum and Java 25 is recommended for general use. Run BreakTest on Java 26 when you want native HTTP/3 over QUIC; the standard HTTP/2 and HTTP/1.1 paths continue to work on Java 21 and newer.

One BreakTest Thread Group supports both workload models, so the same scenario tree can be configured as either a closed model or an open model. Closed mode chains phases with different ramp speeds, hold durations, and thread targets. Open mode chains constant-rate and ramping arrival phases, with a configurable cap on maximum active threads.

This makes complex, dynamic workloads practical without coordinating several Thread Groups. Add as many phases as needed, mix ramps and holds, and use the live preview graph to verify the complete load profile before the test starts.

JMeter's classic Thread Group is a closed model only: a fixed number of users looping. In a closed model, a slowing system reduces its own incoming load, because each user waits for a response before sending the next request. An open model holds the arrival rate constant regardless of response times. This matches production traffic and is the correct model when a target is expressed in requests per second. Reproducing this in JMeter requires third-party plugins and multiple coordinated thread groups.

Selecting the workload model that matches the question is a prerequisite for a test that predicts production behavior rather than merely confirming the configured concurrency.

The Parallel Controller executes its child elements concurrently within a single virtual user, with bounded scheduling and safeguards around shared HTTP state such as cookies and the cache, which were not designed for intra-user concurrency.

Browsers load page resources such as scripts, styles, and API calls over several connections at once. JMeter executes strictly sequentially within a virtual user, so this behavior had to be approximated with additional thread groups and synchronization timers, which is fragile and produces incorrect timing. With native parallel execution, transaction timings for composite pages correspond to what a browser-driven user actually experiences.

The Fork Controller starts its child elements asynchronously and lets the main scripted flow continue immediately. The forked branch shares the virtual user's variables and session context, modeling background traffic from the same user, such as analytics beacons, background polling, and long-running exports.

JMeter has no equivalent: background traffic either had to be modeled inline, distorting transaction timings, or omitted, understating the load.

Scripts can control active branches explicitly: ctx.getThread().stopForks() requests graceful completion, and stopForksNow() cancels them.

The ForEach Controller can execute its branches in parallel with a configurable maximum concurrency. Branches are created lazily as worker slots become available, so iterating over very large value lists does not create all controller clones up front. Retained state is proportional to the configured parallelism, not the item count. This is verified in benchmarks with inputs of a million values.

JMeter's ForEach is strictly sequential, so iterating an extracted list of 50 links takes 50 consecutive request times. A real client fans such requests out concurrently.

Parallel execution is opt-in per controller; existing plans keep their sequential behavior unless it is enabled.

Pause and resume control the workload schedule, not the virtual users already running. Existing users keep executing their plans normally. In a closed workload model, ramp-up stops and no new threads are started; in an open model, scheduled arrivals stop. Resuming continues the schedule and allows new users to start again.

This lets you stop adding load while observing how the system and existing users behave. Pause and resume are available in the GUI and on the command port, and the distribution includes bin/pause and bin/resume wrappers for scripted use.

Thread Groups support iteration pacing directly: a fixed rhythm per iteration independent of response times, used to hold a target transaction rate in a closed workload model. In JMeter this required constructing the same behavior from timers and arithmetic that stopped being correct as soon as response times drifted.

Iteration isolation is also corrected: when same-user mode is disabled, each iteration represents a new user, and BreakTest clears runtime variables at iteration start while preserving initial definitions. Previously, state could carry over from one simulated user to the next and mask correlation errors.

Transaction Controllers let you choose exactly how the reported response time is measured. Sum of sampler times adds the duration of every child sampler. Total run time including timers measures the real wall-clock time from the start of the transaction until it completes. Total run time excluding embedded timers measures that same elapsed execution time but removes delay introduced by timers inside the transaction.

This distinction matters with parallel execution: child samplers overlap, so adding all their durations produces a value longer than the transaction actually took. The two total-run-time modes report the real elapsed duration, while the summed mode remains available for compatibility with traditional JMeter measurements. Existing JMX files retain their original behavior.

Think time is configured on the transaction itself: fixed, random, or Gaussian delay and pacing per transaction. This replaces the JMeter pattern of placing timer elements in the tree and relying on scoping rules to determine where they apply.

On shutdown, BreakTest releases all waiting states, including ramp-up delays, timers, transaction pacing, and sampler waits, and only allows in-flight requests to complete. The results file ends with valid, completed samples.

In JMeter, a stop request did not interrupt sleeping threads, so a test with long think times could take minutes to shut down while thousands of threads finished their timer waits.

If and While Controllers accept structured condition rows for operands, operators, and values, combined with all-must-match or any-must-match. Operators are selected from a readable list that includes equality, contains, starts/ends with, regular expressions, numeric comparisons, and existence checks.

This makes conditions much easier to build and understand than the legacy approach. In JMeter, branching conditions are commonly written as expression strings such as ${__jexl3(…)}; those are harder to review, easier to break, and can silently evaluate to false after a typo.

Legacy expression strings remain supported, so existing plans run unchanged.

Boundary, CSS/HTML, Regex, XPath, XPath2, JSONPath, and JMESPath extractors have a fail-on-no-match option. When enabled and no value is found, the sampler is marked failed and the result names the extractor that produced no match.

In JMeter, a failed extraction leaves the variable at its default value and the test continues. A broken session-token extraction therefore produces a run in which every subsequent request nominally succeeds against error pages. The failure is only discovered during result analysis, after the run.

Failing at the extraction point identifies broken correlation immediately and names the exact element to fix.

CSV Data Set can read records in random order, with header behavior preserved. JMeter's sequential-only reading feeds every run the same records in the same order, which warms caches identically and introduces a hidden correlation into run-to-run comparisons. Random order removes this without maintaining pre-shuffled copies of data files.

The GUI additionally previews how the first records map onto variables before a run, so delimiter and column-mapping errors are caught during configuration rather than after a failed test.

Loop and While Controllers expose index behavior as an explicit option and export the index under a configurable variable name. In JMeter, the starting value and variable name of loop indexes were undocumented implementation details, which made scripts that derive data from iteration counters fragile across versions.

The HTTP Request sampler has been redesigned around the settings you use most. Method, protocol, host, port, and path form one clear request row; parameters, headers, body, files, advanced settings, and recorded evidence each have a dedicated tab. Request options and timeouts stay visible alongside the editor.

Headers that apply to a single request are configured directly on the sampler, with the number of configured values shown on the tab. Child HTTP Header Manager elements migrate automatically; Header Managers at higher scopes continue to apply for genuinely shared headers.

In JMeter, a request-specific header requires a child Header Manager element, so realistic plans accumulate hundreds of single-purpose manager nodes that obscure the actual test structure.

The official BreakTest HAR Recorder is available from the Chrome Web Store. It runs in Chrome's side panel, records a browsing session as a HAR file, and assigns every request to a named transaction while recording.

Given a start URL, it opens a blank tab, attaches the recorder first, and then navigates, capturing the initial document request and all resources it loads. During the session, the next transaction name (for example 02_Login) is typed into the panel; each request is assigned to the transaction active when the request started. A live list shows completed requests, response bodies are captured for later comparison, incognito/private windows are supported, and the browser cache can be disabled for cold-cache recordings.

The exported HAR includes the transaction names, so File → Import HAR generates Transaction Controllers with recorded think times directly. Recording with DevTools, by contrast, provides no transaction concept, misses the requests issued before the Network panel is opened, and depends on manual export settings.

Chrome users can install the official extension directly from the Web Store and receive updates through Chrome. Local Chrome, Edge, and Firefox versions also ship inside the BreakTest distribution under browser-extension/.

BreakTest imports HAR files directly via File → Import HAR. The first step lists every recorded hostname, groups related subdomains, and shows how many requests each host contributed. Select an entire domain group or individual hosts, making it easy to keep the application and API traffic you care about while excluding advertising, analytics, and unrelated third-party resources.

The wizard then groups requests into transactions using recorded idle gaps or the names recorded by the Browser Recorder, optionally ignores recorded error responses, adds request indexes, and detects dynamic URLs. JMeter has no HAR import; turning a recording into a plan required external tooling.

Transaction delays can be recorded, fixed, random, Gaussian, or disabled. Think times accept JMeter variable expressions, with optional ThinkTime, ThinkTimeMin, and ThinkTimeMax Test Plan variables, so pacing for the entire plan is adjusted in one place. The tree displays the resolved think-time summary next to each transaction and refreshes it when the variables change.

The generated plan includes Transaction Controllers, Parallel Controllers for concurrent requests, HTTP Request Defaults, a Cookie Manager, assertions, and shared versus request-local headers, and it retains the HAR metadata required for recorded-vs-replayed inspection and AI repair. After import, only the new Thread Group is expanded.

BreakTest scans HAR imports for grouped predefined correlations by default. It finds values produced by earlier responses and reused in later requests, previews exactly which request values will become variables, and lets you review the rule groups before it adds the extractors and substitutions to the plan.

The built-in catalog covers common OAuth/OIDC, SAML, identity-provider, enterprise-application, web-framework, and generic JSON/REST flows. Repeated and chained values receive unique variables and the nearest valid preceding extraction, preserving the application's real data flow instead of attaching every extractor to the first possible response.

The catalog is a starting point, not a closed system. Teams can create and maintain their own grouped Regex and JSONPath rules for the applications they test, then reuse those rules across recordings. Tools → Try Predefined Correlations applies the same guided discovery to an existing Thread Group.

The practical workflow is much shorter: import the HAR, apply the matching correlation groups, and start with most recurring extractors already in place. Manual scripting and AI Repair can then focus on the application-specific exceptions rather than rebuilding familiar correlation patterns for every recording.

Scripts created by HAR import keep a per-sampler reference to the originally recorded exchange. The results tree and the HTTP sampler editor can display the recorded request and response next to the replayed ones, with normalized formatting so the diff shows substantive differences, such as a missing header or an unsubstituted token, rather than formatting noise.

This directly answers the central question in correlation work: where does the replay deviate from the recording? In JMeter this comparison had to be assembled manually from the recording and a separate capture of the replay. Plain JMeter JMX also has no place to store the recording linkage, which is one of the reasons the BreakTest JMX variant exists.

BreakTest saves test plans as compressed archives (retaining the .jmx extension) that contain the plan and its recorded request/response evidence in a single file. Entries are deduplicated, checksummed, and validated without extraction to the filesystem. Four retention levels control what is embedded: the full recording, recordings without static response bodies, recordings without static resources, or none.

This keeps recording evidence attached to the plan as it moves through version control and between machines. Previously, the linkage broke as soon as the HAR file was separated from the JMX. Legacy plain-XML JMX files continue to load unchanged.

Store Replay takes the most recent replayed request/response for every resolved sampler in View Results and stores it as the plan's recording evidence, with the same retention levels as HAR import.

Recorded baselines lose value as the application changes. Updating the baseline from a verified replay keeps recorded-vs-replayed comparisons meaningful across application releases without repeating the browser recording.

The redesigned Results Tree keeps the request tree and the debugging data in one view, so you spend less time opening listeners, auxiliary samplers, and separate panes. Select a sample to inspect its summary, request, response, cookies, variables, and recorded request or response without leaving the tree.

Response output combines the protocol and headers with the body, detects text versus binary content, and supports Pretty Print for readable JSON or XML. Diff mode makes changes between responses visible directly in the viewer, which is especially useful when tracking down correlation and replay issues.

Each sample also exposes endpoint and TLS metadata, cookies sent and received, and the JMeter variables and user parameters available at that exact moment. Richer summary information and jump-to-source make it faster to understand a failure and return to the test element that produced it.

In JMeter, this information was partially available at best. TLS and endpoint details were absent, variable state required a separate debug sampler, and locating the producing element in a large tree was a manual search.

View Results has a Table mode in addition to the tree: timestamp, response time, latency, connect time, request/response sizes, thread group, thread name, label, and URL, with per-column visibility, numeric sorting, and full-value tooltips for truncated cells. Results can be filtered by thread group, thread name, or sampler label, including a context-menu action to filter to a selected thread. Scrolling and filters remain stable during live refresh.

The tree layout is suited to inspecting a single sample in depth; it is inefficient for scanning hundreds of samples or isolating one misbehaving virtual user. The table covers that second case, which JMeter addressed only partially through separate listeners.

The Performance Report listener is a complete live summary table for the run. Every transaction label gets samples, average, minimum, maximum, throughput, bandwidth, errors, connect time, and selected response-time percentiles, followed by a combined total row. Rows containing failures are highlighted in red so problems stand out immediately.

Choose exactly which columns the table displays, including median, P75, P90, P95, and P99. Percentile columns retain the response-time distribution data they need only while enabled, so the memory cost is paid only for the statistics you use. Error response times can also be excluded from timing metrics so fast failures do not lower the reported averages.

JMeter's aggregate listeners offered a fixed column set, kept full distribution data regardless of use, and included error samples in timing statistics without an option to exclude them.

View Results can be detached into its own window and docked back, so the test plan and results stay visible at the same time. That means less clicking between the sampler you are editing and the response you are debugging, whether the results window sits beside the plan or on a second display.

The detached view keeps the full results table and sample details together, including the JMeter variables captured when each request ran. Seeing extracted values such as IDs and correlation variables at the exact sample that used them makes scripting and debugging much more direct. Validation can also target exactly the selected thread group instead of the whole plan.

In JMeter, results viewers were fixed inside the main window, and validating a single thread group in a multi-group plan required disabling the others manually.

The GUI uses FlatLaf-based light and dark themes with consistent controls, modern SVG toolbar and tree icons, cleaner menu organization, and more compact editor layouts, so more of a test plan and its editor fit on screen at once.

Information density in the tree is improved with child-count badges on nodes, compact delay summaries next to Transaction Controllers, and value counts on the HTTP Request's Params, Headers, Body, and Files tabs. Configuration is visible without opening each node.

The Settings page makes the full JMeter and BreakTest properties catalog discoverable in the GUI. Browse by category or search across settings, read a plain-language description and current default, then change booleans, numbers, and text values with the appropriate editor.

Changes are written to local user.properties or system override files instead of modifying the bundled jmeter.properties defaults. Your configuration therefore survives BreakTest updates, while modified-setting badges and per-setting reset make overrides easy to manage.

JMeter configuration required knowing which of several hundred properties exists and editing jmeter.properties or user.properties by hand, without validation or discoverability.

Use Help → Check for Updates to check for a stable release, review its release notes, and start the update directly from the GUI. BreakTest can also notify you when an update is available; automatic checks are configurable or can be disabled entirely.

The updater verifies the published SHA-512 checksum, installs safely after BreakTest exits, and rolls back if installation fails. Your settings, user properties, third-party lib/ext plugins, and driver JARs are preserved, so updating does not mean rebuilding your local configuration.

JMeter had no update flow: staying current meant manually downloading and extracting a new installation, then copying configuration and plugins back into it. BreakTest turns that into a straightforward GUI update.

The GUI tracks edits as semantic operations, including add, delete, update, move, and search-replace, with standard keyboard shortcuts and menu state kept in sync. AI Repair edits enter the same history and are undoable like manual edits.

JMeter had no undo: an accidental deletion could only be recovered from the last saved file. That risk discouraged restructuring of large plans. With operation-level history, each undo step corresponds exactly to one edit.

JMX files load on a background thread with a progress overlay, so the application remains responsive during loading. JMeter loaded plans on the UI thread, freezing the GUI without feedback for as long as the load took.

An optional fast-load path (jmeter.gui.load.fast=true) caches normalized elements during load and is worthwhile for plans with thousands of elements.

Plans containing elements from unavailable plugins load anyway: unknown elements become disabled placeholders that preserve their configuration, and a notification lists what is missing. The plan can be inspected, partially migrated, or reloaded after installing the plugin.

JMeter refused to open a JMX containing any element it could not instantiate, making the entire file inaccessible over a single missing plugin. This is a frequent obstacle when inheriting older suites or moving between environments.

Search the test plan and delete exactly the matched elements after reviewing a confirmation. This turns bulk maintenance, such as removing every obsolete listener, timer, or pre-processor, into one search and one controlled change instead of a manual pass through the tree.

BreakTest can also flag samplers and transactions that contain assertions or extractors. The markers make those elements easy to locate and expose the places where validation or extraction is still missing.

Bulk changes participate in the normal undo history. If a mass removal did not produce the intended result, Undo restores it instead of forcing you to reload the plan or rebuild deleted elements. In JMeter, search results could not be acted upon and accidental mass edits had no undo path.

BreakTest standardizes scripting on JSR223 with Groovy and removes BeanShell, BSF/JEXL2, Rhino JavaScript, and LogKit. BeanShell is unmaintained and slow; BSF has been deprecated for over a decade; Rhino predates modern JavaScript. None of these engines compile and cache scripts the way JSR223 with Groovy does, and they were a recurring cause of load-test performance problems attributable to the scripting engine itself rather than the system under test. Each also carried its own dependencies and security surface.

Porting is usually limited: most BeanShell snippets are a few lines, and AI Repair performs the conversion from a single instruction ("port all BeanShell to Groovy").

The RMI-based Remote Server mode is removed. Its design had structural problems: brittle connection setup, poor fit with firewalls and TLS, result aggregation that discarded detail, and a coordinating GUI that became the bottleneck of the test it was running. Removing it also removed a significant security surface from the desktop tool.

Distributed execution is handled by BreakTest Enterprise instead, with orchestrated load generators, streaming results, and complete raw data. The free tool concentrates on being the best single-machine scripting and execution environment.

The product uses BreakTest names across the visible runtime: BREAKTEST_HOME, BREAKTEST_OPTS, and BREAKTEST_LANGUAGE are the preferred environment variables, breaktest.* properties are used for configuration, the primary launcher is breaktest.jar, and BreakTest-owned artifacts are published under the nl.breakingit.breaktest Maven group. Distribution archives extract to stable top-level directories.

Compatibility names are retained where existing plans, scripts, and plugins depend on them, including the legacy launcher name for the time being. Existing automation keeps working while new setups can use the BreakTest names consistently.

BreakTest-specific code and materials are licensed under the BreakTest Community Source License 1.0. You can use BreakTest at no cost to test systems operated by your own organization, including internal development, quality assurance, and performance engineering work.

Using BreakTest to provide a testing service to third parties, operate a hosted or commercial platform, redistribute the product, or for another excluded commercial use requires written permission from Breaking IT. Contact [email protected] to discuss licensing for those uses.

Portions derived from Apache JMeter and included third-party components retain their respective licenses, notices, and attribution. Those licenses are included with the source and distribution.

This model keeps BreakTest free for the engineers and organizations using it on their own systems, while businesses building commercial services around BreakTest contribute to its continued development.

Common test plans from JMeter 5.6.3 open and run unchanged. HttpClient 4 jars remain in the distribution solely so plugins compiled against them keep loading, and legacy saved values are mapped to their new equivalents where a sensible mapping exists.

Two limitations apply. Plugins that hook removed internals, such as the old HTTP implementations, BeanShell, or RMI, require migration or replacement. BreakTest-specific JMX metadata (recording linkage, AI context, new controller settings) has no representation in older JMeter versions, so those parts do not round-trip backwards; the files remain valid XML and JMeter ignores the elements it does not recognize.