Skip to content

Run the clip-picking calls of a round at once - #26

Merged
davior merged 1 commit into
mainfrom
claude/trusting-ramanujan-54etzj
Oct 28, 2026
Merged

davior merged 1 commit into
mainfrom
claude/trusting-ramanujan-54etzj

Conversation

@davior

@davior davior commented Oct 28, 2026

Copy link
Copy Markdown
Owner

Why

#25 added a separate clip-picking pass, but its model calls ran one after another. That covered every window of a long video, and every video the assistant asked about in the same round. With several candidate videos, those calls were most of a request's wait.

What changes

  • find_clips is split into plan and finish.
    • plan_clips does the checks, fetches the transcript and takes the budget, and returns a ClipJob holding its prompts.
    • finish_clip_jobs makes the calls for any number of jobs on a thread pool and gives each job's answer back in order.
    • find_clips on its own is plan plus finish, so the windows of a single long video also run at once.
  • The loop collects every find_clips call in a model reply, runs all their picker calls together, and answers every tool call in its original order. Other tools still run in place and in order, so a search earlier in the same reply is still seen.
  • ASSISTANT_CLIP_PICK_CONCURRENCY (default 4) caps how many picker calls run at once. Each one is a request to the user's own provider, so this also sets how hard one request leans on their rate limit.
  • Budget: it is taken when a job is planned, so calls made together in one round can't overspend ASSISTANT_MAX_CLIP_PICKS.
  • Failures stay per video. A provider error on one video becomes that call's error, telling the assistant to use read_transcript. The other videos' answers still stand, and only successful answers are cached.
  • Spend recording is serialised with a lock, because the request's running cost is read, added to and written back.

Testing

  • pytest -q: 723 passed. New tests:
    • picker calls of one round demonstrably overlap (a barrier only passes if two run together),
    • no more calls run at once than allowed,
    • one video's provider failure doesn't affect the others or get cached,
    • a whole loop round with mixed tool calls answers in order, with two picker calls and the invalid one as an error.
  • The concurrency tests passed on 8 repeated runs.
  • npm test && npm run build: 187 passed and the build succeeds (no frontend changes).

Generated by Claude Code

find_clips now plans its job (checks, transcript, budget) where it is
called, and the loop makes every picker call the round asked for together,
across videos and across the windows of a long one, up to
ASSISTANT_CLIP_PICK_CONCURRENCY (4) at a time. One after another they were
most of the wait when several videos were weighed.

The budget is taken when a job is planned, so the calls of one round can't
together overspend it. One video's provider failure is that call's error;
the others' answers still stand. Spend is recorded under a lock, since the
turn's running total is read and written back.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V1geD2rbaPtRa9JcN8sZH8
@davior
davior marked this pull request as ready for review October 28, 2026 14:42
@davior
davior merged commit c6eaf37 into main Oct 28, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants