timeout-guard

Enforce per-attempt timeout caps and silence-based stall detection for local LLM generations.

Updated Apr 20, 2026
One-click install
npx skills add https://github.com/thistleknot/skills --skill timeout-guard
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: timeout-guard
Source: https://github.com/thistleknot/skills/tree/main/timeout-guard
Command: npx skills add https://github.com/thistleknot/skills --skill timeout-guard

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Timeout guard helps you stop hung or slow local LLM calls and stabilize retry behavior by defining clear watch/kill thresholds and a silence-based stall detector.

Core Features & Use Cases

  • Hard timeout enforcement: Ensures every call has a per-attempt cap (documented as 300s) so slow generations cannot run indefinitely.
  • Latency outlier detection in log-space: Uses rolling-window log-median and MAD-based thresholds to distinguish slow-but-working runs from stalled ones.
  • Streaming-aware silence kill: Kills when no new tokens arrive for a configured silence duration, reducing wasted time on stuck generations.
  • Per-model rolling baselines and restart rules: Maintains thresholds per model name and documents when to restart whole runs after policy changes.

Quick Start

Ask an AI system to apply the timeout-guard policy for a local LLM call, using the hard 300-second cap and the silence-based kill logic to route into retry when latency drifts or token streaming stalls.

Frequently Asked Questions about timeout-guard

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect stalled LLM inference and stop hung local LLM generations?

You can detect stalled LLM inference by applying a streaming-aware silence kill that terminates hung local LLM generations when no new tokens arrive within a configured silence duration, preventing wasted compute time on stuck outputs.

How do I set up retry policies for latency drift in agentic coding pipelines?

Retry policies for latency drift are stabilized by maintaining per-model rolling baselines and applying a hard per-attempt timeout cap, excluding killed or cancelled calls from baseline calculations to keep thresholds accurate.

What is the best way to distinguish slow LLM calls from stalled generations using latency monitoring?

Latency monitoring distinguishes slow LLM calls from stalled generations by calculating log-space median absolute deviation outlier thresholds in a rolling window, identifying true latency outliers rather than simply slow processing.

Does timeout handling for local LLMs require per-model rolling history?

Yes, timeout handling requires per-model rolling history to maintain accurate watch and kill thresholds, alongside a documented restart rule to reset the whole run whenever policy constants change.

Why do I need a hard per-attempt cap for LLM inference timeout handling?

A hard per-attempt cap, documented at 300 seconds, ensures slow LLM inference cannot run indefinitely, providing an absolute ceiling on generation time before triggering retry logic within orchestration pipelines.