Hona/strobe
Developer ToolsA pre-release profiler that measures web, Electron, Bun/Node or any process and reports bottleneck evidence.
What it does
Strobe is a performance measurement tool for web pages, Electron apps, Bun/Node processes, and arbitrary native processes. It records CPU, I/O, GPU, frame timing, and other OS-level metrics on one shared clock, then produces a verdict backed by recorded evidence rather than guesses. Metrics a platform cannot measure defensibly are refused with an explanation instead of being reported as zero. The tool consists of a CLI, a per-user daemon, an MCP server, and a built-in skill for opencode, so both humans and coding agents can query the same recordings using identical commands and JSON output. Targets are configured per application using a strobe.json file that describes how to build, serve, or launch the app in isolation.
Supported platforms are Windows x64, macOS (arm64/x64), and Linux (x64/arm64). The project is explicitly marked pre-release, so the design is documented in SPEC.md while the implemented surface is listed in skill/SKILL.md and strobe --help.
Quick start
Strobe is installed per project so that every contributor runs the same version. First add it as a development dependency, then initialize the machine once with the up command, which installs the engine, daemon, MCP, and skill:
bun add -d @hona/strobe
bunx strobe up
After initialization, common operations include comparing a branch against a base, recording a running app, and querying a recording:
strobe bench perf/timeline.bench.ts --base origin/dev --head .
strobe record app:desktop --for 10s
strobe query rec_3f9a hotspots --by package
strobe report experiment exp_8c21 --open
Benchmarks are written as small TypeScript files that declare targets and cases, similar to BenchmarkDotNet. A case defines a primary metric such as frames.presented.p95 and a run function that performs phases of interaction against the page see the benchmark example. Running the bench file produces comparative results and handles for drilling into the measured data.
Platform permissions
Several measurements require OS-level permissions that Strobe does not request automatically. On macOS, driving a native app or placing its window requires Accessibility permission, and reading frames or pixels requires Screen Recording; both apply to the app that Strobe runs under (Terminal, the agent's app, or a remote shell daemon), which strobe status identifies. On Linux, native stacks need kernel.perf_event_paranoid set to 2 or lower, or CAP_PERFMON, and driving native apps needs the session's accessibility bus (at-spi2-core).
The supported metrics vary by platform. For example, per-thread CPU wake counts are available on Windows and Linux but only per-process on macOS; GPU VRAM measurement is refused on macOS unified memory and unsupported for NVIDIA proprietary drivers on Linux; native window measurement on Windows uses Win32 while Linux relies on X11, meaning native Wayland windows are invisible to other apps.
Other constraints
Strobe is pre-release software, so command behavior and coverage may change. The repository does not currently declare a license, which matters for commercial or redistribution use. When recording web pages, the tool expects project-local configuration so it knows how to serve or launch the app; without that configuration the app must already be running and addressable. Measurements that depend on refined OS counters (cycle counters, Mach time, ETW events) may require elevated permissions as described above.
HotRepo's take
Strobe was recorded on the HotRepo new-project list for Rust on 2026-11-04, entering at 102 stars with 4 forks and a one-hour window adding 2 stars. That is a very early snapshot with no daily all-language rank recorded, so the numbers describe an early-stage project rather than a trend. The technically notable claim is the refusal policy: unsupported metrics are reported as errors with reasons instead of zeros, which should make the agent-facing MCP output more trustworthy for automated benchmarking than a naive profiler. Whether the implementation matches the design will depend on the pre-release surface documented in skill/SKILL.md, which the README defers to for what is actually built.
Written by AI from the project's README, updated . The project's own docs are the source of truth.