Build a local floating-point optimization workspace, verify its listener, and provide temporary remote browser access
Herbie analyzes floating-point expressions and searches for more accurate alternatives. This guide installs Herbie through its recommended Racket package workflow, provides an actionable source-installation path for contributors, starts and verifies the browser interface, and connects the verified listener to a Localtonet HTTP tunnel. Because the available Herbie guidance does not establish built-in authentication for the web interface, the remote-access portion is intended for temporary, non-sensitive use unless you have independently verified an appropriate access-control layer.
📋 What's in this guide
What Herbie does and where the web interface fits
Herbie is a numerical development tool that detects inaccurate floating-point expressions and searches for alternatives with improved accuracy. A representative transformation rewrites an expression such as sqrt(x + 1) - sqrt(x) into the mathematically equivalent form 1 / (sqrt(x + 1) + sqrt(x)). The rewritten form can avoid the loss of precision caused by subtracting nearby floating-point values.
This kind of analysis is useful when developing numerical software, reviewing formulas, exploring floating-point behavior, or preparing expressions for another implementation language. Herbie accepts expressions in FPCore, a format used by the FPBench ecosystem. It can be operated through a browser interface, an interactive shell, and additional documented modes such as batch, improve, and report.
The browser interface is the relevant endpoint for this guide because it runs as a local HTTP application. Installation, application startup, and remote access are still separate layers. Herbie must install correctly, remain running, and respond through a local browser before a tunnel is added. This separation gives you a known-good local baseline and makes failures much easier to locate.
web mode starts Herbie's browser interface for interactive use.
Herbie supports Windows, Linux, and macOS on both x86 and AArch64 architectures. This does not mean that every operating system uses the same Racket installation package or setup procedure. The Herbie package command is consistent across supported systems, but obtaining Racket and making its command-line tools available can differ.
As checked for this 2026 revision, the official Herbie site and repository identify Herbie 2.3 as the latest release. Version 2.3 has a redesigned core intended to improve output quality, robustness, and scalability. Its release information also describes the Rust-based Rival 3 engine, support for programs containing hundreds of operators, multiple return values using arrays, platforms for Python and Julia, and improved support for the experimental egglog backend.
That latest-version statement is time-sensitive. Check the official Herbie project site or repository before relying on 2.3 as the current release. The Rust requirement discussed later applies to the documented source workflow. The recommended Racket Package Archive command remains the normal path for readers who simply want to run Herbie.
Prerequisites and installation decisions
The recommended path begins with a working Racket installation. Download Racket from the official Racket download page and select the installer or distribution appropriate for your operating system and processor architecture. Avoid copying an installation command written for a different platform or Linux distribution.
Windows
Use the Windows download offered by the official Racket site and complete its installer. After installation, open a new PowerShell or Command Prompt window so the terminal can pick up any command-path changes. If racket is not recognized, confirm where Racket was installed and follow the path guidance supplied by the Racket installer or documentation.
macOS
Select the macOS download that matches your Mac's architecture. Complete the normal application installation, then open a fresh Terminal session. Herbie supports both x86 and AArch64, but the Racket package you choose should still match the hardware and operating-system version in use.
Linux
Use a Racket distribution method appropriate for your Linux system, following the options on the official download page or your distribution's maintained package guidance. Package names, versions, and installation commands vary, so this guide does not claim that one package-manager command works everywhere.
The Herbie project gives one explicit warning for contributors: avoid the Snap installer for Racket when preparing a source installation. Use another suitable Racket distribution method for that workflow.
Confirm command availability
Open the terminal in which you plan to install Herbie and check that Racket starts and reports its version:
racket --versionThen confirm that Racket's package-management command is available:
raco helpThe exact version text and help output depend on the installed Racket release. The important result is that both commands run rather than producing a shell-level “command not found” or “not recognized” error. If either command is unavailable, resolve the Racket installation or terminal path before installing Herbie.
Decide whether you need the recommended package installation or a source checkout:
| Requirement or choice | Recommended package install | Source install |
|---|---|---|
| Primary purpose | Running Herbie for normal analysis and browser use | Contributing to Herbie or working directly from its repository |
| Racket | Required | Racket 8.0 or later |
| Rust | No separate Rust prerequisite is stated for the recommended package command | Rust 1.87.0 or later |
| Source repository | Not required | The official Herbie repository |
| Herbie installation action | raco pkg install --auto herbie |
Download the repository and run make install from its root |
| Normal launch command | racket -l herbie |
racket -l herbie, with direct source execution also documented for developers |
For most readers, the Racket Package Archive path is the right starting point. It is the method recommended by the Herbie project and does not require you to maintain a repository checkout. Installing from source is not necessary merely because Herbie will run on your own machine or because you plan to open its browser interface.
Both installation paths run Herbie on your computer. Choose the source path when you need to inspect, modify, test, or contribute to the repository. Choose the package path for normal use.
Install Herbie from the Racket Package Archive
The recommended workflow has two documented actions: install Racket, then ask Racket's package manager to install Herbie. Run the package command under the same operating-system account that will normally launch the application.
Install and verify Racket
Obtain Racket from its official download page using the Windows, Linux, or macOS option appropriate for your system. In a new terminal, run racket --version and raco help to confirm that both command-line tools are available.
Install Herbie and its package dependencies
Run the official package command below. The --auto option allows Racket's package manager to install required package dependencies automatically.
raco pkg install --auto herbieLet the package manager finish before opening another Herbie process. If installation reports an error, preserve the complete terminal output. The first meaningful failure often identifies whether the problem involves Racket itself, package retrieval, dependency resolution, permissions, or another local prerequisite.
After installation, invoke Herbie through its documented Racket library entry point:
racket -l herbie
This verifies that Racket can locate and load the installed Herbie package. For the browser workflow, add the web mode as shown in the startup section. If the terminal says that racket or raco cannot be found, that remains a Racket installation or command-path issue. Resolve it before attempting remote access.
The upstream Herbie documentation should be consulted when behavior differs between releases. It supplements the workflow here with project-specific details, but you do not need to leave this guide to discover the required package command, startup command, or Localtonet configuration sequence.
Optional command-line shell check
Herbie also provides an interactive shell. Starting it can distinguish a general installation problem from a web-interface-specific startup problem:
racket -l herbie shellA successful launch displays a Herbie prompt. The shell accepts FPCore input. The repository documents this example:
(FPCore (x) (- (+ 1 x) x))
The input represents (1 + x) - x, and the documented optimized result is the constant 1. Exit the shell with Ctrl-D. Startup text can include the installed Herbie version and a generated seed, so do not treat version numbers or seeds shown in old examples as fixed output.
Install Herbie from source for development
Use the source workflow when you intend to contribute to Herbie, inspect or modify its implementation, or work directly from a repository checkout. The currently documented minimums are Racket 8.0 or later and Rust 1.87.0 or later.
A working Racket installation alone is not sufficient for the documented source workflow. Install Rust 1.87.0 or later as well. On Linux, avoid the Snap installer for Racket, as specifically advised by the Herbie project.
Check the installed toolchain versions before downloading or building:
racket --version
rustc --version
Confirm that the reported versions meet the source requirements. You will also need Git if you use the checkout command below and a working make implementation for the documented installation target.
Prepare the development prerequisites
Install Racket 8.0 or later and Rust 1.87.0 or later, then make both toolchains available in the terminal that will run the build. Prepare Git and Make if you will use the command-line checkout path.
Acquire the official Herbie repository
Clone github.com/herbie-fp/herbie and enter the checkout directory. If Git is unavailable, use the repository page's download option, extract the archive, and open a terminal in the extracted top-level directory containing the Makefile.
Run the documented installation target
From the repository's top-level directory, run make install. Keep the complete build output if installation does not finish successfully.
A concrete Git checkout path is:
git clone https://github.com/herbie-fp/herbie.git
cd herbie
make install
The first command acquires the repository. The final command is the Herbie project's documented source-installation action and must be run from the repository root. If you choose a different local checkout directory, enter that directory instead of herbie.
After installation succeeds, launch the installed package through the same Racket library entry point:
racket -l herbie
The project also documents running src/main.rkt directly for source-based development. The exact direct-execution context can depend on the checkout and working directory, so this guide does not add unverified flags or claim that direct source execution is required for normal browser use.
When troubleshooting a source build, first compare the installed Racket and Rust versions with the documented minimums. Then confirm that make install is being executed in the directory containing the repository's Makefile rather than in a parent directory or one of the source subdirectories. Resolve build failures before testing web mode.
Start Herbie's web interface and identify its listener
Start the documented browser interface with:
racket -l herbie webKeep this terminal open while using the interface. A locally hosted web process is available only while its process remains running. Closing the terminal, interrupting the command, ending the user session in a way that terminates its processes, or restarting the computer can stop Herbie.
The verified upstream material establishes the web command. It does not, in the evidence available for this revision, establish one fixed default hostname, bind address, port, or exact browser URL that should be copied into every installation. It also does not establish a universal command-line option for changing those values. For that reason, this guide does not assume localhost, 127.0.0.1, port 8000, or any other commonly used development endpoint.
Consult the current Herbie tutorial alongside the startup output from the installed version. The installed process is the final authority for the listener you must verify on your machine.
Capture the actual host and port
Start Herbie in a visible terminal and wait for its startup output to settle. Use the following evidence in order:
- If Herbie prints a complete browser URL, copy that exact URL.
- If Herbie opens a browser automatically, inspect the browser address bar and record its hostname and port.
- If Herbie prints a listening address and port separately, combine only those reported values into the local URL expected by that version.
- If no usable listener is displayed, review the current tutorial or documentation for the installed release rather than substituting a port from another application or old article.
Separate the URL into its local target components. For example, a URL generally contains a scheme, hostname, optional port, and path. Localtonet's HTTP tunnel target needs the local IP address or hostname and port of the service. Do not treat a page path as part of the port, and do not use the public Localtonet hostname as the local target.
Do not copy a Herbie port from an unrelated tutorial. A wrong port can produce a connection failure or direct the tunnel to a different local application. Record and verify the listener created by the Herbie process currently running on your machine.
Understand the bind address
A bind address determines which network interfaces accept connections. A loopback-only service is reachable from the same computer but generally not directly from another device on the LAN. A service bound to a broader interface can accept traffic arriving through that interface, subject to the operating system, firewall, and application behavior.
The Localtonet client should run on the Herbie computer or on another device that can reach the selected local target. If both processes run on the same machine, a loopback target can be suitable when it matches the listener Herbie reports. If Localtonet runs on another device, that device must be able to reach Herbie through a non-loopback local address and port.
The verified Herbie evidence used for this guide does not document a bind-address setting, so we do not provide an unsupported flag for changing it. If your architecture requires a different binding, consult the documentation or startup help for the installed Herbie release before making a change.
Verify Herbie locally before exposing it
Local verification creates a clean boundary between application problems and tunnel problems. If the interface does not work from the Herbie machine, a public tunnel cannot make the underlying service healthy.
Confirm that the Herbie process remains running
After starting racket -l herbie web, confirm that the command does not immediately exit with an error. Keep its terminal visible so startup messages and request errors remain available.
Capture the listener from current evidence
Copy the URL printed by Herbie, inspect the address of a browser opened by Herbie, or use the listening host and port explicitly reported by the installed version. If none is shown, consult the current Herbie tutorial for that release instead of guessing.
Open the exact local address
Use a browser on the same computer and enter the captured URL. Confirm that the hostname and port match the running process and that the page loads without a connection error.
Submit a normal Herbie interaction
Use the interface to submit a non-sensitive test expression and confirm that Herbie produces a result. Loading only the page shell does not prove that the complete application workflow is functioning.
Record the verified target
Record the local IP address or hostname and port that produced the successful response. Keep the Herbie process running. These are the values to enter as the Localtonet HTTP target.
If the page does not load locally, return to the Herbie terminal. Look for a package-loading failure, an occupied port, an immediate process exit, or another explicit diagnostic. Start the documented shell mode if you need to determine whether the core Herbie installation works independently of web mode.
If the shell starts but the web interface does not, focus on web startup, the reported listener, and local connectivity. If neither mode starts, focus on the package installation, Racket environment, or source build. Do not introduce Localtonet until the interface can complete an interaction through a local browser.
Record enough runtime information to reproduce the setup
For a repeatable development setup, record which operating-system account starts Herbie, which installation path was used, the installed Herbie version, the working local address, and how the process is restarted after a reboot. Do not record Localtonet authentication tokens, account credentials, private URLs, or other secrets in shared notes.
The project evidence supplied for this revision does not specify a service manager, container workflow, background-process setup, or automatic-start procedure. Those choices vary by operating system. Implement them only after confirming how your installed Herbie version behaves when launched non-interactively.
Connect the verified Herbie interface to Localtonet
Once Herbie works locally, an HTTP tunnel is the appropriate Localtonet tunnel family for its browser-based interface. Our client establishes an outbound connection to a Localtonet relay server and provides a public URL without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
The available Herbie evidence does not establish built-in authentication or authorization for this interface. A Localtonet public HTTPS URL provides the connection path and HTTPS address, but HTTPS alone does not decide who is authorized to use Herbie. Expose only non-sensitive test workloads, keep the tunnel active only while needed, and do not leave it public unless you have independently verified an appropriate access-control layer.
Creating a tunnel does not mean it is running. The Herbie process must still be listening, the selected Localtonet device must be connected, and the tunnel must be started. The public URL is usable only while the necessary application, client, and tunnel states remain active.
Use the current Localtonet HTTP tunnel documentation to confirm the dashboard presentation while following the sequence below. Relay server and region choices must come from the current dashboard. Do not copy a server code or region from a static tutorial.
Install and run the Localtonet client
Run our client on the Herbie computer or on another device that can reach Herbie's verified local address. Keep Herbie running while you configure and test the tunnel.
Authenticate or select the client device
Use the device-specific authentication token through the supported Localtonet workflow, then select that device for the tunnel. Never publish the token, include it in screenshots, commit it to a repository, or hardcode it in shared instructions.
Select an available relay server or region
Choose from the values currently shown by the dashboard. Availability can vary by plan, account, region, and product state, so this guide does not hardcode a server code.
Create the HTTP tunnel
Select the HTTP tunnel family and enter the exact local IP address or hostname and port verified in the previous section. For Process Type, use Random Sub Domain, Custom Sub Domain, or Custom Domain according to the options available for your current plan and dashboard configuration.
Start the tunnel and test its assigned URL
Use the Start button, then open the assigned public HTTPS address in a separate browser session. Submit only a non-sensitive test expression and watch the Herbie terminal while confirming that the request completes.
Stop or delete the tunnel after the session
Stop the tunnel as soon as remote access is no longer needed. Delete it if the configuration will not be reused. Stopping Herbie removes the working backend, but explicitly stopping the tunnel also records the intended public-access state.
A saved configuration is not enough. Herbie must be listening at the configured target, the selected Localtonet client must be connected, and the tunnel must be started. If any of these conditions is missing, the public URL will not provide a working Herbie session.
Random Sub Domain, Custom Sub Domain, and Custom Domain process types serve the same local HTTP content through a public HTTPS address. Option availability can vary by plan. This guide does not provide custom-domain DNS records because exact requirements must be checked against the current Localtonet documentation and the domain configuration presented in the dashboard.
Test from a separate browser session so you are clearly using the public URL rather than an already-open local tab. Confirm the displayed hostname, submit a harmless expression, and verify that Herbie receives the request. Do not assume that seeing an HTTPS lock indicator means the application is private or restricted to you.
If the public URL fails, keep Herbie running at the already verified local target. Check the selected Localtonet device, local host, local port, relay selection, client connection, and tunnel state one at a time. Avoid changing Herbie and Localtonet simultaneously because doing so removes the known-good baseline.
Security and routine operations
A public tunnel changes the reachability of the application. An interface that was previously available only from a development computer can receive requests through its public URL while the tunnel is active. Treat that change as an access-control decision, not merely as a connectivity convenience.
The Herbie documentation available for this revision does not establish built-in user authentication, authorization roles, session restrictions, or a supported application-level access-control mechanism for its browser interface. Do not assume those controls exist. The safe default is to use the public interface only for temporary, non-sensitive work and stop the tunnel immediately after the session.
HTTPS protects the connection to the public address, but it does not by itself determine who may use the application. Do not expose confidential expressions, unpublished research, proprietary formulas, credentials, customer data, or other sensitive material without a separately verified access-control design.
Define a safe operating boundary
- Use test expressions and other non-sensitive inputs for temporary remote sessions.
- Share the public URL only with intended participants, while recognizing that URL secrecy is not a substitute for authentication.
- Keep the Herbie terminal visible so application errors and unexpected requests can be noticed during testing.
- Run Herbie under an operating-system account with no more file or administrative access than necessary.
- Do not leave the tunnel running unattended unless an independently verified control protects the application.
- Stop the tunnel after use, then stop Herbie if the local application is no longer needed.
- Keep Racket, Herbie, Rust when applicable, the Localtonet client, and the operating system maintained through their supported update processes.
A practical start and stop routine
Use the same order each time:
- Start Herbie with
racket -l herbie web. - Capture its current listener and verify the local URL.
- Submit a non-sensitive local test expression.
- Start or confirm the Localtonet client on the selected device.
- Confirm that the saved tunnel still points to the verified host and port.
- Start the HTTP tunnel.
- Test the assigned public URL using a separate browser session.
- When finished, stop the tunnel first and then stop Herbie if it is no longer needed.
This sequence is especially useful after a reboot, Racket update, Herbie update, or network change. It verifies each layer in order and prevents a stopped application or changed listener from being mistaken for a tunnel failure.
Know which layer to inspect
| Observation | Likely layer | First check |
|---|---|---|
| Herbie does not start | Installation or runtime | Read the terminal error and verify Racket, Herbie, and source prerequisites where applicable |
| The local browser cannot connect | Herbie process or listener | Confirm the process is running and use the exact address reported by the installed version |
| The local page loads but analysis fails | Herbie application | Inspect the Herbie terminal and retry with a known non-sensitive test expression |
| Local access works but the public URL does not | Localtonet configuration or lifecycle | Check the selected device, target host and port, client connection, and tunnel state |
| Access stops after closing a terminal | Process lifecycle | Determine whether Herbie or the Localtonet client was terminated |
| The public URL remains reachable after work is complete | Operational cleanup | Stop or delete the tunnel rather than relying only on the backend process being unavailable |
Troubleshooting the complete workflow
raco or racket is not recognized
The terminal cannot find the Racket installation. Confirm that you obtained Racket for the current operating system and architecture, then open a new terminal after installation. Run racket --version and raco help. If either remains unavailable, follow the official Racket installation guidance for making its executables accessible from the terminal.
This is not a Herbie web-interface problem or a Localtonet problem. Do not proceed until the underlying Racket commands work.
The package installation fails
Review the complete output from:
raco pkg install --auto herbieAutomatic package dependency handling does not guarantee that every operating-system, permission, or network condition is satisfied. Preserve the first meaningful error instead of only the final summary. Confirm that the same user account can run Racket and that package retrieval is not being interrupted.
The source installation fails
Confirm that racket --version reports Racket 8.0 or later and rustc --version reports Rust 1.87.0 or later. On Linux, verify that Racket was not installed through Snap for this workflow. Then confirm that the terminal is in the cloned or extracted repository root containing the Makefile before running:
make installKeep the full build output. Do not attempt to repair a source-build failure by adding unverified flags from an unrelated project.
The Herbie shell works, but web mode does not
A working racket -l herbie shell command shows that Racket can load Herbie. Start racket -l herbie web again and inspect its output for a web-specific diagnostic. Check the current tutorial and documentation for the installed release if its behavior differs from this guide.
Do not assume a hostname or port simply because another Racket application or older Herbie installation used it.
Herbie appears to run, but no listener is obvious
Check whether Herbie opened a browser automatically. If it did, inspect the full address in that browser. Review the terminal from the beginning for a printed URL, hostname, or port. If the installed version does not display enough information, use the current upstream tutorial for that version.
The verified evidence establishes the startup command but not one fixed listener for all installations. Guessing can target the wrong local process, so listener discovery must be completed before Localtonet configuration.
The process runs, but the local browser cannot connect
Verify that the browser uses the exact address reported by Herbie. Check for transcription mistakes in the hostname and port, and make sure the terminal process has not exited. If Herbie printed a full URL, begin with that URL instead of reconstructing it manually.
If the Localtonet client will run on another machine, first establish whether that second machine can reach the target through the local network. An address such as a loopback listener belongs to the machine on which the application runs and is not automatically reachable from another computer.
The public URL cannot reach Herbie
Reopen the verified local URL from the Herbie computer. If it no longer works, repair or restart Herbie first. If it still works, check that the selected Localtonet client is connected, the HTTP tunnel is started, and the configured local IP address and port exactly match the known-good target.
Confirm that the client is running on the intended device. Localtonet authentication tokens identify specific devices. Selecting a connected device that cannot reach Herbie will still produce an unusable target.
The tunnel worked earlier but stopped later
Check the complete lifecycle. Herbie may have stopped, the Localtonet client may have disconnected, or the tunnel may have been stopped. A tunnel remains available only while the selected client is connected and the tunnel is running. A host reboot can also terminate Herbie unless you have separately configured and verified process management.
The public page loads but analysis fails
Repeat the same non-sensitive input through the local URL while the issue is present. If both paths fail, investigate Herbie and the input. If only the public path fails, preserve the browser symptoms and inspect the Herbie process for incoming requests or errors.
The available evidence does not establish Herbie's behavior behind every hostname or reverse-proxy arrangement. Do not invent origin, proxy, or header settings. Check the current Herbie guidance for the installed release if the application reports a host-related restriction.
A port copied from another guide does not work
Remove the copied value and return to the current Herbie process. Capture its printed URL, inspect the browser it opened, or use the listener guidance for the installed release. The reliable target is the address and port verified on your machine, not a value observed in another installation.
The public URL works, but it should no longer be available
Stop the tunnel from the Localtonet dashboard or supported client workflow. Do not rely only on closing the browser or stopping Herbie. A stopped backend prevents successful Herbie requests, but explicitly stopping or deleting the tunnel is the correct cleanup action for public reachability.
Frequently asked questions
What is the recommended way to install Herbie?
Install Racket from the official Racket download page, verify racket and raco in a terminal, then run raco pkg install --auto herbie. This is the installation path recommended by the Herbie project for normal use.
When should I install Herbie from source?
Use the source workflow when you need to contribute to Herbie, inspect or modify its code, or work directly from its repository. The documented source prerequisites are Racket 8.0 or later and Rust 1.87.0 or later. Clone or download the official repository, enter its root directory, and run make install.
How do I start Herbie's browser interface?
Run racket -l herbie web. Keep the terminal open and use the URL or listener information reported by the installed version. The verified evidence for this guide does not establish one fixed hostname, port, or exact URL for every installation.
Is Herbie 2.3 still the latest version?
The official Herbie site and repository identified 2.3 as the latest release when this article was checked in 2026. Release status can change, so confirm the current version on the official project site or repository before making version-specific decisions.
Which operating systems and processor architectures does Herbie support?
Herbie supports Windows, Linux, and macOS on x86 and AArch64. Racket acquisition differs by operating system. Linux contributors following the source workflow should avoid the Snap installer for Racket.
Does Herbie have a command-line interface?
Yes. Run racket -l herbie shell for the interactive shell. Herbie also documents batch, improve, and report modes, and its input format is FPCore.
Which Localtonet tunnel type should I use for Herbie?
Use an HTTP tunnel for Herbie's browser interface. Configure the local target with the exact IP address or hostname and port verified through your local browser. Do not use an assumed port from another installation.
Do I need router port forwarding or a public IP address?
No. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Is creating a Localtonet tunnel enough to make Herbie available?
No. Herbie must be running at the configured local target, the selected Localtonet device must be connected, and the tunnel must be started. Creating a saved configuration does not start it automatically.
Does the public HTTPS URL make Herbie private?
No. HTTPS protects the connection but does not itself authorize users. The available Herbie evidence does not establish built-in authentication for the web interface. Use non-sensitive workloads, keep exposure temporary, and stop the tunnel after use unless you have independently verified an appropriate access-control layer.
Can the Localtonet client run on a different computer?
Yes, provided that the client device can reach Herbie's local IP address and port. If Herbie listens only on a loopback address, another computer generally cannot use that loopback target. Running Herbie and the Localtonet client on the same machine is the simplest arrangement for a loopback-bound service.
Connect a verified Herbie workspace with Localtonet
Install Herbie, confirm its actual local listener, and test a non-sensitive expression before creating an HTTP tunnel. Keep public access temporary unless you have separately verified suitable authentication and authorization controls.
Get Started Free →
