Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Workers burn ~29% of tool calls polling pipeline/CI status; add a single blocking wait (and optional park)

Open
  • Is something wrong?
#7,331 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github, shell
Domain
ci-cd, devtools, performance

Research direction

Start by reading the generated ship brief and tracing the pipeline wait/status path, the forge checks path, and Firstmate's existing park path referenced in the issue. Decide how one blocking call should handle gates, outcomes, timeouts, and wakeups; the issue calls out missed or delayed events as a constraint. Done means measuring tool calls and harness CPU before and after and confirming waiting workers use only a handful of calls and sit near idle CPU.

Written by the indexing model from the issue text.

Description

ready-for-pr

Workers spend a large share of their turns just checking whether the pipeline or CI has finished.

Once a ship worker hands its branch to the validation pipeline, or waits on CI, it typically loops: check status, wait a bit, check again. On one host over a week, 24,742 of 86,595 tool calls in worker sessions (29%) were no-mistakes status or wait commands. Another 3,290 were gh pr checks or run polls, and 1,895 were explicit waits. Each of those is a model turn: it costs quota, adds context, and keeps the agent's harness busy. A waiting Codex harness measured 0.09 to 0.15 of a core, against about 0.02 when idle, so about 1.4 cores across 19 agents were spent on waiting. Pipeline and CI steps routinely take 30 minutes to several hours, so this adds up.

What I'd like built: let a worker wait for a pipeline or CI outcome with a single blocking call, and wake only when there is something to do.

  • Provide (or document) one supported wait primitive that blocks until the run reaches a gate, an outcome or a timeout, and returns a compact summary. For example, a Firstmate helper wrapping the pipeline's own wait/status, or the forge's checks API, with backoff.
  • Make the generated ship brief tell workers to use that one call instead of polling loops, and to end their turn while waiting where the harness supports being woken.
  • Optionally, add a park policy: an agent whose task has only been waiting on the pipeline or CI past a threshold is parked, then resumed on the outcome. That frees its harness and memory (agent trees were 550 to 900 MiB each). Firstmate already has a park path that could be reused.
  • Measure tool calls and harness CPU per waiting agent before and after.

Done when: a worker waiting on validation or CI makes a handful of calls instead of dozens, waiting agents sit near idle CPU, and no gate or outcome is missed or delayed compared with today.

Technical context
  • Host: 16 vCPU, about 16 to 19 concurrent agents (mostly Codex and Claude workers), no-mistakes pipeline for ship tasks, GitHub forge.
  • 7-day count from interactive worker session logs: 86,595 tool calls; 24,742 (29%) contain no-mistakes ; 3,290 are gh pr checks or run polls; 1,895 are wait/sleep calls.
  • Waiting harness CPU: 0.09 to 0.15 core for a waiting Codex harness vs about 0.02 idle (≈ 1.44 cores across 19 agents).
  • Agent process trees: 550 to 900 MiB each, of which MCP servers are 330 to 710 MiB.
  • Pipeline step durations (7 days): CI step median 66.8 min (p90 361 min); review averages 3.9 rounds; time tracked tasks spent waiting on the pipeline was about 15% of task time, plus about 4% in the CI queue.
Dominant language
Shell
Stars
8k
Forks
2.6k
Avg merge
1d 22h
Merged PRs (30d)
99

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from kunchenguid/firstmate

All issues in kunchenguid/firstmate

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.