peek vs Jam.dev
Both record rich context from your real browser. The delta is the consumer: peek hands your AI coding agent forensic read access to debug what already happened; Jam hands a human engineer a shareable bug report.
This page exists for the person searching “jam.dev alternative” or “local-only bug capture” or “MCP browser extension.” No FUD — Jam.dev is a well-built product. The two tools overlap in tech but target different workflows. The sections below say when each one fits.
At a glance
| peek | Jam.dev | |
|---|---|---|
| Primary consumer | An AI coding agent (Claude Code, Cursor, Cline, Windsurf, Continue, Zed) querying via MCP. | A human engineer reviewing a bug report sent by QA / a PM / a designer. |
| Output format | MCP tools returning JSON (console errors, network failures, DOM-at-timestamp, full event slices). The session lives in a local SQLite DB. | A “Jam” — a hosted URL with rendered video + DOM + console + network for a human viewer. |
| Where data lives | Local: ~/.peek/sessions.db. Never leaves your machine. | Vendor cloud (jam.dev). Required for the shareable URL workflow. |
| Signup | None. Install the CLI + extension and go. | Required (Jam account) to host and share captures. |
| Cost | Free. Apache 2.0. | Free tier with limits; paid tiers for teams. |
| Workflow shape | You're already talking to your AI agent. You ask “what's in my latest session?” The agent calls list_sessions, get_session_console_errors, etc. and answers. | You hit the Jam button, narrate a bug, click stop, paste the URL into Slack. The recipient signs in and reviews the rendered capture. |
| Capture trigger | Per-origin host permission. Off by default for every site. Enable from the side panel. | Click the Jam extension button to start, click again to stop. |
| Replay UX | None in the extension — AI agents query the data structurally. (Optional peek sessions export --format html writes a tracelane-style file for human viewing.) | Purpose-built reviewer UI: video timeline, DOM inspector, console pane, network pane, commenting. |
| Network capture | Yes (rrweb + optional CDP “Deep capture” for response bodies). | Yes. |
| Console capture | Yes (level + stack + URL). | Yes. |
| Write-back | The MCP surface defines execute_action (click / input / navigate) gated by per-action authorization + an audit log. The permission model and audit log ship today; the cross-process bridge that delivers actions to the live browser is in development (read-only until it lands). Off by default; not a sharing feature. | Read-only by design — Jam is a capture-and-share product, not a remote-control tool. |
| Privacy boundary | Your machine. Sessions, audit log, native messaging host all local. | Vendor cloud (Jam's infrastructure). Vendor SOC2 + their data-handling policy. |
| MCP-native | Yes — this is the entire design goal. | No. Jam is a browser-extension + cloud product; AI-agent integration isn't its target. |
| Maturity | Pre-1.0 (alpha). Available on the Chrome Web Store; can also be loaded unpacked for development. | Mature commercial product with significant team adoption. |
When peek is the right choice
- The primary thing you do with browser context is talk to your AI agent about it — you want Claude Code / Cursor / Cline to read what's on the page when you describe a problem.
- You're under local-only constraints — regulated industry, sensitive customer data, contractual requirement that “recordings of our app don't leave employee machines.”
- You want the option of write-back (an AI agent that can click and type for you on the live tab) with explicit per-action authorization. peek's permission model is built for this; Jam doesn't address it.
- You're OSS-first and don't want a vendor in the audit log for your bug data.
When Jam.dev is the right choice
- Your primary workflow is handoff: someone captures a bug; someone else fixes it. The capturer (QA, PM, designer, support) is often not the fixer (engineer). Jam's hosted URL collapses that into one link.
- You want a polished hosted reviewer UX out of the box — commenting, sharing, video scrubbing, organization-level capture libraries.
- The data crossing into vendor cloud is acceptable to your security review.
- You don't (yet) have an AI-coding-agent workflow that benefits from MCP — Jam's value prop is human-to-human.
Can you use both?
Yes. They don't conflict. Use Jam for “here's a bug, please fix” handoffs to a teammate, and peek for “here's what's in my browser, Claude, please help me work this out.” Different workflows, no overlap in storage or replay.
What about Sentry Session Replay or LogRocket?
Different category. Both Sentry Session Replay and LogRocket record production traffic from end-users — the captures are about incidents your users hit, not about bugs you're actively poking. peek is a developer-side tool: nothing records until you explicitly enable it on a specific site, and the captures live on your machine, not in a product data warehouse. If you need production-incident replay, Sentry / LogRocket are the right shape. Peek does not compete in that category.
Why this page exists
Comparison pages capture search intent that the competitor's own marketing page deliberately won't. If you arrived here from “jam.dev alternative,” the honest answer is: it depends on whether your primary consumer of the capture is an AI agent or a human. peek is purpose-built for the first; Jam is purpose-built for the second.
Found something inaccurate above? Open a PR on this page — the goal is accuracy, not advocacy.