Rockachopa/Timmy-time-dashboard
1
0
Fork 2
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

[loop] Fix Hermes timeout — fire-and-forget delegation, never block on Kimi #229

New Issue
Closed
opened 2026-03-15 17:45:29 +00:00 by hermes · 1 comment
hermes commented 2026-03-15 17:45:29 +00:00
Collaborator
Copy Link

Problem

Cycles 53 and 54 both timed out (exit code 142 = SIGALRM at 20 min) because Hermes dispatched work to Kimi then burned the entire cycle budget on sleep 30 && tmux capture-pane polling loops.

Root Cause

The loop prompt instructs Hermes to:

  1. Dispatch to Kimi
  2. Poll Kimi's tmux pane every 30-60 seconds
  3. Wait until Kimi finishes
  4. Extract the result

This blocks Hermes for the full duration of Kimi's work. If Kimi takes >20 min, Hermes times out and the cycle is wasted.

Fix

With the new Gitea-based delegation (#225, #226):

  • Hermes assigns the issue and moves on immediately
  • Hermes does its own work in the same cycle
  • Hermes checks for Kimi PRs as part of its cycle start (Phase 1)
  • Zero blocking, zero polling

In the Loop Prompt

Add to Phase 1 (start of cycle):

Check for open PRs from kimi:
  GET /repos/.../pulls?state=open&poster=kimi
For each: review, merge if tests pass, or request changes.

Remove:

  • All tmux send-keys dispatch to Kimi
  • All sleep/poll loops
  • All tmux capture-pane checks

Expected Impact

  • Cycles should complete in 5-15 min instead of timing out at 20
  • Hermes does its own work while Kimi works independently
  • Both agents productive simultaneously
## Problem Cycles 53 and 54 both timed out (exit code 142 = SIGALRM at 20 min) because Hermes dispatched work to Kimi then burned the entire cycle budget on `sleep 30 && tmux capture-pane` polling loops. ## Root Cause The loop prompt instructs Hermes to: 1. Dispatch to Kimi 2. Poll Kimi's tmux pane every 30-60 seconds 3. Wait until Kimi finishes 4. Extract the result This blocks Hermes for the full duration of Kimi's work. If Kimi takes >20 min, Hermes times out and the cycle is wasted. ## Fix With the new Gitea-based delegation (#225, #226): - Hermes assigns the issue and moves on immediately - Hermes does its own work in the same cycle - Hermes checks for Kimi PRs as part of its cycle start (Phase 1) - Zero blocking, zero polling ## In the Loop Prompt Add to Phase 1 (start of cycle): ``` Check for open PRs from kimi: GET /repos/.../pulls?state=open&poster=kimi For each: review, merge if tests pass, or request changes. ``` Remove: - All tmux send-keys dispatch to Kimi - All sleep/poll loops - All tmux capture-pane checks ## Expected Impact - Cycles should complete in 5-15 min instead of timing out at 20 - Hermes does its own work while Kimi works independently - Both agents productive simultaneously
hermes commented 2026-03-15 18:04:41 +00:00
Author
Collaborator
Copy Link

Resolved. The old tmux-polling model is gone.

With kimi-loop.sh (#228), Hermes delegates by assigning issues via Gitea API and moves on immediately. No tmux polling, no blocking, no timeouts. Fire-and-forget delegation is now the default workflow. Closing.

Resolved. The old tmux-polling model is gone. With `kimi-loop.sh` (#228), Hermes delegates by assigning issues via Gitea API and moves on immediately. No tmux polling, no blocking, no timeouts. Fire-and-forget delegation is now the default workflow. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
222-epic
Workshop: Timmy as Presence (Epic #222)
 actionable
Has a concrete code/config task extracted
 assigned-claude
Issue currently assigned to Claude agent — do not assign to another agent
 assigned-gemini
Issue currently assigned to Gemini agent — do not assign to another agent
 assigned-groq
assigned-kimi
Issue currently assigned to Kimi agent — do not assign to another agent
 assigned-manus
Issue currently assigned to Manus agent — do not assign to another agent
 claude-ready
consolidation
Part of a consolidation epic
 deprioritized
Keep open but not blocking P0 work
 deprioritized
Keep open but not blocking P0 work
 duplicate
Duplicate of another issue
 gemini-review
Auto-generated by Gemini, needs relevance review
 groq-ready
harness
Core product: agent framework, heartbeat, inference, memory
 heartbeat
Harness: Agent heartbeat loop
 inference
Harness: Inference and model routing
 infrastructure
Supporting stage: dashboard, CI/CD, deployment, DNS
 kimi-ready
Scoped and ready for Kimi to pick up
 memory-session
Harness: Memory and session crystallization
 morrowind
Harness: Morrowind embodiment
 needs-design
Needs architectural design before implementation
 needs-extraction
Philosophy with unextracted engineering work
 p0-critical
Priority 0: Must fix now
 p1-important
Priority 1: Important, next sprint
 p2-backlog
Priority 2: Backlog, do when time permits
 philosophy
Philosophical foundation — informs architecture decisions
 rejected-direction
Closed: rejected or superseded direction
 seed:know-purpose
Three Seeds: KNOW YOUR PURPOSE
 seed:serve-real
Three Seeds: SERVE THE REAL
 seed:tell-truth
Three Seeds: TELL THE TRUTH
 sovereignty
Harness: Sovereignty stack
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Timmy claude grok groq kimi manus perplexity Rockachopa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Rockachopa/Timmy-time-dashboard#229
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?