The questions engineers actually ask.

The CLI is free and runs entirely on your machine — no account, no signup, no telemetry. Capturing traffic, watching an endpoint, exporting sessions, and lobe explain (which calls Anthropic directly with your own key) all work without ever creating a Lobe account.

You only need an account when you want your sessions to persist in the hosted dashboard — for historical baselines, cross-session comparison, and sharing with teammates. That cloud sync is the paid line; nothing is gated behind a login until you ask us to store data for you.

Yes to HTTPS, and no — there is no certificate to install, ever.

Lobe is a reverse proxy, not an intercepting one. Your app or browser talks plain HTTP to Lobe on your own machine (127.0.0.1:7878 by default), and Lobe opens its own connection to your upstream. When the upstream is https://, Lobe performs that TLS handshake itself — and that handshake is exactly what the TLS phase in your timings measures.

Nothing is intercepted or decrypted in the middle: no CONNECT tunneling, no generated certificates, no CA to add to your keychain, no browser warnings. The hop between your client and the proxy stays on loopback (or your LAN, if you bind with --listen 0.0.0.0 to profile a mobile app).

Yes. When your upstream speaks HTTP/2, Lobe negotiates it automatically via ALPN (the protocol-negotiation step of the TLS handshake) — no flag to pass. Requests are multiplexed over a pooled connection, so warm requests skip DNS, TCP, and TLS entirely, exactly like a real browser or HTTP client would. Every captured request records which protocol was negotiated and whether the connection was new or reused, and both show up in the dashboard.

One honest detail: HTTP/2 applies to the hop between Lobe and your upstream. The loopback hop between your client and the proxy is HTTP/1.1 — it’s on your own machine, so it isn’t what you’re measuring.

Want to see it in action? Local dev servers speak plain HTTP/1.1 (HTTP/2 is negotiated during the TLS handshake), so point capture at any real HTTPS site: lobe capture https://www.cloudflare.com, then curl http://127.0.0.1:7878/ twice. The detail pane shows http2 as the negotiated protocol, and the second request skips DNS, TCP, and TLS entirely — that’s the pooled connection multiplexing at work.

DevTools only sees what the browser sends. Lobe sits in front of your server, so it times any client: a mobile app pointed at your laptop, curl, an integration test, another service, or your backend’s own outbound calls to a third-party API — traffic no browser tab will ever show you.

The other difference is memory. DevTools shows one page load and forgets it. Lobe keeps sessions: per-route p50/p95 aggregates, history across runs, drift detection when an endpoint slowly gets slower, and side-by-side comparison of two sessions to check whether a change actually helped.

And the two play well together — if you already have a network log from DevTools, export it as a HAR and drop it on the import page for the same phase-by-phase breakdown, no proxy setup required.

All of them. Lobe is a proxy, not an SDK — there is no library to add, no middleware to wire in, no per-language agent. If your backend speaks HTTP, Lobe can profile it: Rails, Django, Express, Spring, Go, Laravel, a Lambda behind a dev gateway, or a mobile app pointed at your laptop over LAN. Your code never knows Lobe is there.

Only what you want to measure. There are two modes. lobe capture proxies real traffic — you browse or exercise your app through 127.0.0.1:7878, and every request that flows through is recorded, so you profile exactly the paths you actually hit. If instead you just want to watch a single endpoint drift over time, lobe watch <url> probes one URL on an interval. Same phase decomposition either way; nothing you don’t send through the proxy is touched.

Because your traffic has to go through the proxy, and that means changing which URL you open. After lobe capture http://localhost:3000, browse http://127.0.0.1:7878 — not localhost:3000. Lobe never intercepts traffic behind your back: nothing is captured unless you deliberately send it through the door. If you keep using your app’s original URL, your browser talks straight to it and Lobe sees nothing — that’s the privacy model working as intended, not a bug.

One thing to know if you point Lobe at an external website rather than your own app: the first page flows through fine, but any link or asset written as an absolute URL (https://example.com/…) sends your browser back to the real site, silently bypassing the proxy. Your own app doesn’t have this problem — local apps use relative URLs, which is why Lobe is built for profiling your upstream.

On its own, neither Lobe nor any proxy can tell — from outside your server, TTFB is one opaque number. But there’s a standard, language-agnostic way to open it up: the Server-Timing response header. Emit it — one middleware line in any framework, e.g. Server-Timing: db;dur=190, render;dur=40 — and Lobe reads it at capture time and splits the TTFB bar into your app’s own segments (db, render, …), with any remainder shown as unattributed app time.

That turns “probably a slow query” from a guess into a measurement, and it stays agentless — no SDK, works in any language. Rails emits Server-Timing automatically in development, so Rails apps get the split for free. Copy-paste snippets for Express, Django, Spring, and more are in Server-Timing header examples.

It adds a little — and Lobe tells you exactly how much, so you never have to wonder. Every session measures the proxy’s own added latency per request (the wall-clock time spent inside Lobe minus the upstream round-trip) and reports the median right in the capture summary, e.g. proxy +0.05ms.

In practice that’s microseconds against upstream milliseconds — noise — but you don’t have to take our word for it. The overhead is a number on the screen, so you can trust the phase timings reflect your upstream, not us.

Run lobe probe <url> --concurrency 50. It holds 50 requests in flight while pushing a few hundred through, each with the full DNS/TCP/TLS/TTFB/download decomposition, and reports the latency distribution — p50/p95 per phase — instead of a single number. Pass a sweep like --concurrency 1,5,10,25,50 and it charts TTFB p50/p95 against each level, so the concurrency where your service falls over is visible as a cliff, not a hunch.

The payoff is cohort detection: when a bounded resource saturates — the classic case is a DB connection pool of 10 at concurrency 50 — TTFB splits into a fast cohort (got a connection) and a slow cohort (queued). Lobe detects that bimodal split and prints it, e.g. fast 43ms ×81 (54%) / slow 604ms ×69 (46%), which tells you what kind of bottleneck you have, not just that one exists.

Two guardrails worth knowing: it’s a latency-under-contention diagnostic, not a throughput benchmark — it deliberately doesn’t report requests/second (that’s k6/wrk territory). And bursts default to GET; flooding a mutating endpoint requires an explicit --allow-unsafe, because concurrent POSTs execute real mutations.

There’s no hard cap on the concurrency level, but past a few hundred your own machine becomes the bottleneck — each in-flight request is a real connection, so you’ll hit your OS’s open-file limit and start measuring your laptop instead of your server. Failed connects are counted and excluded from the percentiles, never silently mixed in. A sweep up to 50–100 is where pool problems live; if you need thousands, you want a load-testing tool. And like everything else in the CLI, burst results stay on your machine — they’re printed and discarded, never stored or uploaded.

Yes. Drop a .har onto the import page and you get the same phase-by-phase session view as a live capture — DNS, TCP, TLS, TTFB, and download — with no proxy setup and no account required. HAR is the common export format for browser network logs, so if you already have one, you’re a single drag-and-drop away from a full Lobe session.

Parsing happens entirely in your browser; the file never uploads. Saving that imported session to your dashboard — so it joins your history and can be compared against other runs — is a Pro feature.

Yes — that’s what the dashboard’s Compare view is for. Pick a baseline and a current session and Lobe computes the deltas that matter: p95 total, per-route regressions, new hosts and third-party dependencies, redirect and connection-reuse shifts.

It also draws an overlaid waterfall — the two sessions’ median request shapes on a shared axis — so you can see which phase moved. A TTFB regression shows up as a visibly wider TTFB segment on the current bar, not just a +42ms number. It answers “did this deploy make things slower, and where?” at a glance.

No lock-in. Any capture or watch session exports to a portable JSON file — press e in the TUI — that you can archive, share with a teammate, replay offline, or feed straight into lobe explain.

Your captures are yours. On the free tier they never leave your disk unless you explicitly upload them, and even then the export file is always there as your own copy.

An aggregated summary of the session — never the raw capture. Specifically: request methods, paths, and hosts as captured (including query strings, if your URLs carry them), status-code counts, per-route timing percentiles, per-phase medians, and error messages. It does not send request or response headers, and it does not send bodies — the proxy’s captured payloads never leave your machine.

The request goes directly from your machine to the Anthropic API using your own key — Lobe’s servers are never in the path, and nothing is retained by us. If you never run lobe explain, nothing is sent to anyone. See the privacy policy for the full picture.

Two pieces: a GitHub App and one step in your CI workflow.

First, install the Lobe Prognosis GitHub App on the repos you want covered. Then add one step to your GitHub Actions workflow: run your integration or smoke tests through lobe capture --upload --pr. Repo, branch, and commit SHA are picked up automatically from the Actions environment, and the session uploads to your team workspace.

The bot grades each upload two ways: against the baseline your main branch established, and against the SLA thresholds you define per route group in lobe.yml (p95 TTFB, p99 total, error rate). The first run on your default branch sets the baseline; every PR after that gets a real comparison.

What you see on the PR: a single comment with the verdict — posted once, then updated in place on every push — plus a “Lobe Prognosis” check run on the commit. It goes red ✗ when a critical scenario breaches, and if you mark the check required in branch protection, that breach blocks the merge.

Already have SLOs declared somewhere else? The bot reads datadog-slos.yml or pagerduty-services.json from your repo root as import shortcuts, so you don’t have to rewrite them.

Full setup — workflow YAML, token minting, and config reference — is in the PR bot docs.

No. The CLI has no telemetry and local sessions stay local. Data leaves your machine in exactly two cases, both explicit: you run lobe explain (a summary goes to Anthropic with your key, as described above), or you upload a session to your dashboard with --upload / u after lobe login.