explaingit

robzolkos/pi-lifeline

32TypeScript

TLDR

pi-lifeline is an extension for Pi, a command-line agent platform.

Mindmap

A visual breakdown will appear here once this repo is fully enriched.

In plain English

pi-lifeline is an extension for Pi, a command-line agent platform. It is built around a specific scenario: you have a small or local AI model running an automated research loop, where it edits code, runs an experiment, logs the result, and tries again. When that loop gets stuck, pi-lifeline lets the small model phone a friend, meaning ask a larger, more capable model for advice on what to try next. The extension adds three things to Pi. A new tool called phone_a_friend takes a question, optional context, and a mode (ideas, critique, debug, or next_experiment) and routes it to a stronger advisor model that returns strategic suggestions rather than code. A slash command /lifeline shows the current configuration, thresholds, and how many advisor calls have been used this session. A trigger system watches log_experiment results and decides when calling the advisor is worth the money. The defaults are conservative on purpose. Out of the box the extension only triggers after three consecutive failed experiments or six runs with no improvement, with a minimum of five runs between calls and a hard cap of ten calls per session. The default action is to nudge, which means it asks the agent to call phone_a_friend rather than calling silently, so the cost is visible. Setting the action to ask flips it into fully automatic mode. Installation is done with pi install npm:pi-lifeline followed by /reload. A /lifeline init wizard writes a starter config to ~/.pi/agent/pi-lifeline.json where you can pick the advisor provider (for example OpenAI or Google), the advisor model, the thinking level, token limits, and the trigger thresholds. Environment variables are also accepted, and a PI_LIFELINE_FAKE_RESPONSE variable lets you smoke-test the extension without spending tokens on a real model. The README finishes with a five-step validation plan: static type-check, unit tests for the trigger policy, a fake-advisor smoke test, an autoresearch fixture smoke test that feeds in a small JSONL log to confirm the trigger fires, and a real-advisor smoke test using a cheap model. The design notes stress that the small model stays in charge of edits and experiments; the strong model is only ever consulted for strategy.

Open on GitHub → Explain another repo

Generated 2026-05-21 · Model: sonnet-4-6 · Verify against the repo before relying on details.