Get started

Quickstart

Install via your CLI, login, and ask your agent a question. Your entire network will be visible in under a minute. Let’s get started.

  1. Install yeet

    One command installs the CLI and the yeetd daemon on a Linux host and starts the daemon:

    curl -fsSL https://yeet.cx | sh

    yeet runs on Linux. On macOS or Windows, run it in Docker. Or Manual install.

  2. Sign the host in

    Signing in ties the host to your account. It prints a link to open in your browser:

    yeet login

  3. Explore your network

    Open your coding agent on the host (Claude Code, Codex, etc). Start with yeet graph dump, which shows everything yeet can read on the host, then ask about the network. For example:

    yeet's system graph answers questions about the machine: yeet graph dump prints the schema (what you can ask), yeet graph query '<query>' returns the data.

    Report on CPU, memory, swap, disk, network, processes, listening ports and outbound connections, and point out anything that looks out of place. Say what kind of machine this appears to be (laptop, VM, server, container host) and judge "normal" by that.

    Done means: every finding names the process, port or number it's based on, and anything you couldn't check is listed as unchecked. Explain the results in plain language.

  4. Start building

    Ask about an app, a bug, or any network traffic. Turn it into a dashboard or a local web app in your browser.

    A great place to start is with a tool from our library. HTTP Scope shows the live web requests going in and out of a machine. Here’s the prompt:

    Set up httpscope (https://github.com/yeet-src/httpscope) on this Linux machine. Its README has a "Have an agent set it up" prompt: follow it.

    Work out where I'll open the page from (this machine, or another computer through SSH or a VM's port forwarding) and make sure it's reachable there. Give me the exact address to type. If localhost might resolve to IPv6 and reach something else, give the 127.0.0.1 form.

    npm install and make bpf run code from the repo; if your permissions block them, tell me the exact command to run myself.

    Done means: the page loads for me and shows real HTTP traffic. If the machine is quiet, send a couple of harmless requests of your own (not to my services) to prove it. Explain what I'm looking at in plain language.

    2-minute build time

  5. Keep it running

    yeet can run as a service that restarts on its own, posts to Slack when something trips, or exports metrics to Prometheus and Grafana. Try one of these:

    See which containers talk to each other

    Use yeet (https://yeet.cx; install with curl -fsSL https://yeet.cx | sh if missing, never with sudo) to measure which containers on this machine talk to each other and which go out to the internet: who talks to whom, on which port, and how many bytes, as a live rate and as totals over a time range. Measure it in the kernel with eBPF, so it works without changing the containers.

    Find out which container runtime is in use (Docker, Podman, containerd/nerdctl, rootless or not). If there are no containers, start a small demo app with realistic traffic: a frontend, an API, a cache, a background worker, some of them calling public websites.

    Export the numbers to Prometheus and build a Grafana dashboard with: a map of who talks to whom, a table of conversations, internet destinations per container, and traffic over time.If Prometheus and Grafana already run here or are reachable, find them. Check before you assume where they run (for example, a Prometheus in a container can't reach the host's 127.0.0.1). If you can't add a scrape target to the existing Prometheus, run your own and add it to Grafana as a new data source.If there's no Grafana, run Prometheus and Grafana locally.Import the dashboard yourself.

    Done means: every panel's query returns data when run through Grafana itself, and you give me a link that opens the dashboard. Keep the monitoring running after a reboot (use yeet service if it fits). Explain the results in plain language.

    Check if Jellyfin really transcodes on your GPU

    Use yeet (https://yeet.cx; install with curl -fsSL https://yeet.cx | sh if missing, never with sudo) to find out whether Jellyfin is really transcoding on the GPU, not just configured to. Measure it in the kernel with eBPF.

    Show every transcode as one of: fully on GPU, mixed (part GPU, part CPU), or software. Flag transcodes that asked for the GPU but fell back to the CPU. For each, show CPU use, how fast it reads the movie file (total, and the part that came from disk rather than memory cache) and how long it ran. Keep a history of finished transcodes.

    Find out the setup yourself:Which GPU this machine has (Intel QSV/VAAPI, NVIDIA NVENC, AMD), if any. If there is none, say so up front, and also show clearly labelled SIMULATED GPU and mixed transcodes, kept apart from real data, so the dashboard can still be seen.Whether Jellyfin runs here (natively or in a container). If it doesn't, set up a demo Jellyfin with test videos and pretend viewers that force transcodes.

    Build a standalone web page for this (not Grafana), reachable from wherever I'll open it. Give me the exact address.

    Done means: the page shows real transcodes with verdicts, and you've checked the CPU and read-speed numbers against something independent (the video's bitrate, or Jellyfin's transcode log). Tell me plainly what you could and couldn't verify on this hardware. Keep it running after a reboot (use yeet service if it fits).