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).

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.

A proxy can’t see inside your server, so on its own 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.

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.

You install the Lobe Prognosis GitHub App on the repos you want covered, then run your integration or smoke tests through lobe capture --upload --pr in GitHub Actions — repo, branch, and commit SHA are picked up automatically from the Actions environment. The session uploads to your team workspace, and the bot grades it 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). It then posts — and updates — a single comment on the PR with the verdict, plus a “Lobe Prognosis” check run on the commit: red ✗ when a critical scenario breaches, and merge-blocking if you mark the check required in branch protection. The first run on your default branch sets the baseline; every PR after that gets a real comparison.

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.