| name | pi-demo-grid |
| description | Use when launching a tmux grid of concurrent localpi Pi demo sessions for live demonstrations, load demos, screen-filling demo walls, side-by-side model output comparisons, or when recording such a demo to video. Triggers include requests to demo localpi, open many Pi demo panes, launch concurrent demo requests, create a tmux demo grid, run localpi --demo at a target concurrency, or record a demo grid in Ghostty. |
Pi Demo Grid
Overview
localpi has two native subcommands for demo walls:
localpi grid launches a balanced tmux session containing many concurrent
localpi --demo panes.
localpi record opens a themed Ghostty window attached to a tmux session
and records it to an mp4 (X11 only).
Use them instead of ad hoc tmux scripting so pane creation, layout, safety
gates, and recording are deterministic. This skill is intentionally
conservative: first show the launch plan, then start only when the user has
explicitly asked to run it.
Workflow
-
Resolve the target concurrency.
- If the user gives a number, use it.
- If the user asks for a demo without a number, default to the maximum currently available concurrency for the selected backend.
- Discover that number from the running provider or localpi status before launching. For vLLM, use the running server's configured
--max-num-seqs.
- "Maximum available concurrency" means the backend's configured request/sequence capacity, not an invented machine-wide estimate.
- If the backend capacity cannot be discovered, do not guess. Show what is known and ask for the target concurrency.
- Concurrency must be a positive integer.
-
Resolve the localpi demo command.
- Prefer an explicit command when the user provides one.
- Otherwise build
localpi --demo plus any user-provided localpi flags.