@cat-factory/executor-harness 1.50.18 → 1.52.2

package/src/progress.ts

@@ -0,0 +1,232 @@
+import { isObject } from './claude-stream.js'
+import type { TodoProgress } from './pi.js'
+
+// The parent agent's own PLAN, as progress counts. This is one of the two redundant views a
+// pr-reviewer run produces (the other is the parallel-subagent dispatch view in
+// `subagents.ts`); {@link pickProgress} reconciles them.
+//
+// The Claude Code CLI exposes the plan through TWO different tool vocabularies, and which one
+// a run uses depends on the CLI build, not on anything the harness controls:
+//
+//  - `TodoWrite` — one call carrying the WHOLE list (`todos[]`), each entry with its own
+//    status. Every call is a complete snapshot, so the last one wins.
+//  - `TaskCreate` / `TaskUpdate` — an incremental, id-keyed task list. `TaskCreate` appends a
+//    task and the CLI assigns its id in the tool RESULT; `TaskUpdate` moves one task by id.
+//
+// Both are live in the shipped schema (`sdk-tools.d.ts` in `@anthropic-ai/claude-code` declares
+// `TodoWriteInput` AND `TaskCreateInput`/`TaskUpdateInput`), so the harness tracks both rather
+// than betting on one. Reading only `TodoWrite` is what pinned a CLI 2.1.x pr-review at 0%:
+// the run planned entirely through `TaskCreate`/`TaskUpdate` and the harness saw nothing.
+//
+// Everything here is best-effort and defensive: an unknown status, a missing id, or a result
+// string the CLI reworded degrades to "no progress from this signal" rather than throwing. The
+// tool vocabulary is not a stable contract, so this module may only ever ADD signal.
+
+/** Statuses a plan entry can carry; anything unrecognised is treated as not-yet-started. */
+export function normalizeStatus(status: unknown): 'pending' | 'in_progress' | 'completed' {
+  if (status === 'completed') return 'completed'
+  if (status === 'in_progress') return 'in_progress'
+  return 'pending'
+}
+
+/** Roll a label+status list up into the counts the board renders. Shared by every plan shape. */
+export function toProgress(items: { label: string; status: ReturnType<typeof normalizeStatus> }[]) {
+  return {
+    completed: items.filter((i) => i.status === 'completed').length,
+    inProgress: items.filter((i) => i.status === 'in_progress').length,
+    total: items.length,
+    items,
+  }
+}
+
+/** Map a `TodoWrite` call's `todos` array onto subtask counts. Each call is a full snapshot. */
+export function todosToProgress(todos: unknown): TodoProgress | undefined {
+  if (!Array.isArray(todos)) return undefined
+  return toProgress(
+    todos.filter(isObject).map((t) => ({
+      label: typeof t.content === 'string' ? t.content : String(t.content ?? ''),
+      status: normalizeStatus(t.status),
+    })),
+  )
+}
+
+/**
+ * The id the CLI assigned to a just-created task, read from `TaskCreate`'s tool RESULT.
+ *
+ * `TaskCreate`'s INPUT carries only `{subject, description}` — the id is minted by the CLI and
+ * comes back on the result, so pairing a later `TaskUpdate({taskId})` to the task it created
+ * requires reading the result text. The CLI's shipped `TaskCreateOutput` is
+ * `{task: {id, subject}}`, but the parent stream's `tool_result` block carries the rendered
+ * STRING (`"Task #1 created successfully: <subject>"`), so both shapes are accepted.
+ */
+export function parseCreatedTaskId(content: unknown): string | undefined {
+  if (isObject(content)) {
+    const task = isObject(content.task) ? content.task : undefined
+    const id = task?.id
+    if (typeof id === 'string' && id.trim()) return id.trim()
+    if (typeof id === 'number') return String(id)
+  }
+  const text =
+    typeof content === 'string'
+      ? content
+      : Array.isArray(content)
+        ? content
+            .filter(isObject)
+            .map((b) => (typeof b.text === 'string' ? b.text : ''))
+            .join('\n')
+        : ''
+  return /\bTask\s+#(\d+)\b/i.exec(text)?.[1]
+}
+
+interface PlannedTask {
+  id: string
+  label: string
+  status: ReturnType<typeof normalizeStatus>
+}
+
+/**
+ * Tracks the parent's incremental `TaskCreate` / `TaskUpdate` plan.
+ *
+ * A `TaskCreate` is registered as pending against its tool_use id, then bound to the CLI-assigned
+ * task id when its result arrives; `TaskUpdate` moves the bound task. A create whose result is
+ * never seen (or whose id can't be parsed) still counts toward `total` under a synthetic key, so
+ * the plan size stays honest even when the pairing fails — it simply can never advance.
+ *
+ * `deleted` tombstones are dropped from the list entirely (matching `TodoWrite`'s live-tasks-only
+ * shape), so a task the agent abandons doesn't hold the bar back forever.
+ */
+export interface TaskPlanTracker {
+  /** Feed an `assistant` message's content blocks: registers creates + applies updates. */
+  onAssistant(content: unknown[]): void
+  /** Feed a `user` message's content blocks: binds each create to its CLI-assigned task id. */
+  onUser(content: unknown[]): void
+  /** The plan as progress counts, or undefined when nothing has been planned yet. */
+  progress(): TodoProgress | undefined
+}
+
+export function createTaskPlanTracker(): TaskPlanTracker {
+  // Insertion-ordered so `items` render in plan order.
+  const tasks = new Map<string, PlannedTask>()
+  // tool_use id of an unresolved `TaskCreate` -> the synthetic key it was filed under, so the
+  // task can be re-keyed to its real id once the result lands.
+  const pendingCreates = new Map<string, string>()
+  // Updates that arrived before their target was bound (the CLI can interleave), replayed on bind.
+  const orphanUpdates = new Map<string, Partial<PlannedTask>>()
+  // `deleted` tombstones for a task id whose create has not bound yet, replayed on bind — else a
+  // delete that races ahead of its create leaves the task in the plan forever.
+  const pendingDeletes = new Set<string>()
+
+  const apply = (task: PlannedTask, patch: Partial<PlannedTask>): void => {
+    if (patch.label) task.label = patch.label
+    if (patch.status) task.status = patch.status
+  }
+
+  // Drop a tombstoned task. When it isn't present yet (its create hasn't bound), remember the
+  // tombstone so the bind drops it rather than leaving it stuck in the plan forever.
+  const markDeleted = (taskId: string): void => {
+    if (!tasks.delete(taskId)) pendingDeletes.add(taskId)
+    orphanUpdates.delete(taskId)
+  }
+
+  return {
+    onAssistant(content) {
+      if (!Array.isArray(content)) return
+      for (const block of content) {
+        if (!isObject(block) || block.type !== 'tool_use') continue
+        const input = isObject(block.input) ? block.input : {}
+        if (block.name === 'TaskCreate') {
+          const toolUseId = typeof block.id === 'string' ? block.id : undefined
+          if (!toolUseId || pendingCreates.has(toolUseId)) continue
+          const label =
+            (typeof input.subject === 'string' && input.subject.trim()) ||
+            (typeof input.description === 'string' && input.description.trim()) ||
+            `Task ${tasks.size + 1}`
+          const key = `pending:${toolUseId}`
+          tasks.set(key, { id: key, label, status: 'pending' })
+          pendingCreates.set(toolUseId, key)
+        } else if (block.name === 'TaskUpdate') {
+          const taskId = typeof input.taskId === 'string' ? input.taskId : undefined
+          if (!taskId) continue
+          const patch: Partial<PlannedTask> = {}
+          if (typeof input.subject === 'string' && input.subject.trim())
+            patch.label = input.subject.trim()
+          if (input.status === 'deleted') {
+            // `deleted` is a tombstone, not a status — drop the task from the live list.
+            markDeleted(taskId)
+            continue
+          }
+          if (input.status !== undefined) patch.status = normalizeStatus(input.status)
+          const task = tasks.get(taskId)
+          if (task) apply(task, patch)
+          else orphanUpdates.set(taskId, { ...orphanUpdates.get(taskId), ...patch })
+        }
+      }
+    },
+    onUser(content) {
+      if (!Array.isArray(content)) return
+      for (const block of content) {
+        if (!isObject(block) || block.type !== 'tool_result') continue
+        const toolUseId = typeof block.tool_use_id === 'string' ? block.tool_use_id : undefined
+        const key = toolUseId ? pendingCreates.get(toolUseId) : undefined
+        if (!key) continue
+        const taskId = parseCreatedTaskId(block.content)
+        pendingCreates.delete(toolUseId!)
+        const task = tasks.get(key)
+        // No parsable id ⇒ leave it filed under its synthetic key: it still counts toward the
+        // plan total, it just can never be advanced by a later `TaskUpdate`. A parsed id that
+        // already names a live task (a duplicate / misparse) is also left under the synthetic key
+        // rather than overwriting that task — the rebuild below would otherwise drop a row and
+        // undercount `total`.
+        if (!taskId || !task || taskId === key || tasks.has(taskId)) continue
+        // Re-key in place. Rebuilding the map preserves insertion order, which `items` relies on.
+        const entries = [...tasks.entries()]
+        tasks.clear()
+        for (const [k, v] of entries) {
+          if (k !== key) tasks.set(k, v)
+          else tasks.set(taskId, { ...v, id: taskId })
+        }
+        // A tombstone that raced ahead of this bind drops the task now that it exists.
+        if (pendingDeletes.delete(taskId)) {
+          tasks.delete(taskId)
+          orphanUpdates.delete(taskId)
+          continue
+        }
+        const pendingPatch = orphanUpdates.get(taskId)
+        if (pendingPatch) {
+          const bound = tasks.get(taskId)
+          if (bound) apply(bound, pendingPatch)
+          orphanUpdates.delete(taskId)
+        }
+      }
+    },
+    progress() {
+      if (tasks.size === 0) return undefined
+      return toProgress([...tasks.values()].map((t) => ({ label: t.label, status: t.status })))
+    },
+  }
+}
+
+/**
+ * Reconcile the redundant views of the same work into the one to surface (ADR 0027 Defect B).
+ * A pr-reviewer run has BOTH a parent plan (`TodoWrite` or `TaskCreate`/`TaskUpdate`) and the
+ * `SliceTracker`'s subagent-dispatch view. The sequential shape advances the plan; the parallel
+ * shape advances ONLY the slice tracker (the reviewer writes its plan once and the parallel
+ * subagents report in-flight/complete). Neither alone covers both shapes, and gating the slice
+ * tracker off whenever a plan exists (the original behaviour) pinned parallel runs at 0%.
+ *
+ * So prefer whichever view is further along: more `completed`, then more `inProgress` (an
+ * all-pending plan must not beat live in-flight slices), then more `total` (the richer view — a
+ * plan can carry an extra "aggregate" entry), else the plan. Pure + total; returns whichever
+ * single input is present when only one is.
+ */
+export function pickProgress(
+  todo: TodoProgress | undefined,
+  slice: TodoProgress | undefined,
+): TodoProgress | undefined {
+  if (!todo) return slice
+  if (!slice) return todo
+  if (slice.completed !== todo.completed) return slice.completed > todo.completed ? slice : todo
+  if (slice.inProgress !== todo.inProgress) return slice.inProgress > todo.inProgress ? slice : todo
+  if (slice.total !== todo.total) return slice.total > todo.total ? slice : todo
+  return todo
+}

package/src/runner.ts

@@ -1,6 +1,6 @@
 import { redactSecrets } from './redact.js'
 import type { FollowUpLine } from './follow-ups.js'
-import type { TodoProgress, ToolSpan } from './pi.js'
+import type { HarnessCallMetric, TodoProgress, ToolSpan } from './pi.js'
 import { log, type Logger } from './logger.js'
 import {
   type FailureCause,
@@ -30,6 +30,19 @@ export interface RunOptions {
   onSpan?: (span: ToolSpan) => void
   /** Receives the forward-looking follow-up / question items the Coder streamed since the last poll. */
   onFollowUp?: (items: FollowUpLine[]) => void
+  /**
+   * Receives each per-call telemetry row the moment the agent's CLI stream yields it, so a
+   * run's model calls reach `llm_call_metrics` WHILE it runs rather than only in its terminal
+   * result. The registry stamps the call's job-scoped {@link HarnessCallMetric.seq} and buffers
+   * it for the next poll to drain.
+   *
+   * Call this for every metric you also put on the result — the SAME object, not a copy: the
+   * stamped `seq` is what lets the backend recognise the terminal write of an already-recorded
+   * call and skip it. A run that dies mid-flight (the container is evicted, the harness process
+   * is OOM-killed) never produces a terminal result, so without this its entire token spend and
+   * every prompt/response body are lost — exactly the run an operator most needs to inspect.
+   */
+  onCallMetric?: (call: HarnessCallMetric) => void
   /**
    * Mark the coarse lifecycle phase the handler has entered (`clone` / `agent` / `push` / …).
    * Drives the stuck-run breadcrumb: an inactivity kill reports WHICH phase was hung, and the
@@ -114,6 +127,17 @@ export interface JobView<TResult extends JobResultBase = JobResultBase> {
    * surfaces the first one (and only on a follow-ups-enabled coding run).
    */
   followUps?: FollowUpLine[]
+  /**
+   * Per-model-call telemetry the agent's CLI stream yielded SINCE THE LAST POLL
+   * (drain-on-read, exactly like {@link spans}). The backend records these into
+   * `llm_call_metrics` as they arrive, so a run's token spend and prompt/response bodies are
+   * queryable while it is still running — and survive it dying before it can produce a
+   * terminal result. Each carries a job-scoped `seq` so the terminal
+   * {@link JobResultBase} list can re-offer the same calls without duplicating rows.
+   * Absent until the agent's first model call (and on the proxy-metered Pi harness, whose
+   * calls the LLM proxy meters directly).
+   */
+  callMetrics?: HarnessCallMetric[]
   /**
    * ADR 0026 D4: set when the cold-start watchdog fired — the job produced NO activity
    * within {@link RunnerLimits.coldStartMs} of starting, a likely onboarding/auth wedge.
@@ -136,6 +160,13 @@ interface JobEntry<TResult extends JobResultBase> extends JobView<TResult> {
   spanBuffer: ToolSpan[]
   /** Follow-up items buffered since the last drain (see {@link JobView.followUps}). */
   followUpBuffer: FollowUpLine[]
+  /** Call telemetry buffered since the last drain (see {@link JobView.callMetrics}). */
+  callMetricBuffer: HarnessCallMetric[]
+  /**
+   * Next job-scoped {@link HarnessCallMetric.seq} to stamp. Monotonic for the life of the job
+   * (never reset by a drain), so a call's row id stays unique across every poll window.
+   */
+  callMetricSeq: number
   /** Abort the in-flight run (see {@link JobRegistry.abortAll}); set while running only. */
   abort?: (reason: string) => void
 }
@@ -192,6 +223,8 @@ function toView<TResult extends JobResultBase>(entry: JobEntry<TResult>): JobVie
     promise: _promise,
     spanBuffer: _spanBuffer,
     followUpBuffer: _followUpBuffer,
+    callMetricBuffer: _callMetricBuffer,
+    callMetricSeq: _callMetricSeq,
     abort: _abort,
     ...view
   } = entry
@@ -237,6 +270,8 @@ export class JobRegistry<TJob = unknown, TResult extends JobResultBase = JobResu
       promise: Promise.resolve(),
       spanBuffer: [],
       followUpBuffer: [],
+      callMetricBuffer: [],
+      callMetricSeq: 0,
     }
     this.jobs.set(id, entry)
     entry.promise = this.drive(entry, job)
@@ -244,9 +279,10 @@ export class JobRegistry<TJob = unknown, TResult extends JobResultBase = JobResu
   }
 
   /**
-   * Poll the job — and DRAIN its tool-span buffer (drain-on-read). The GET /jobs/{id}
-   * handler is the sole caller, so each poll returns the spans accumulated since the
-   * previous poll and clears them, bounding the harness buffer to one poll interval.
+   * Poll the job — and DRAIN its observability buffers (drain-on-read). The GET /jobs/{id}
+   * handler is the sole caller, so each poll returns the spans / follow-ups / call metrics
+   * accumulated since the previous poll and clears them, bounding the harness buffers to one
+   * poll interval.
    */
   get(id: string): JobView<TResult> | undefined {
     const entry = this.jobs.get(id)
@@ -260,6 +296,10 @@ export class JobRegistry<TJob = unknown, TResult extends JobResultBase = JobResu
       view.followUps = entry.followUpBuffer
       entry.followUpBuffer = []
     }
+    if (entry.callMetricBuffer.length > 0) {
+      view.callMetrics = entry.callMetricBuffer
+      entry.callMetricBuffer = []
+    }
     return view
   }
 
@@ -374,6 +414,13 @@ export class JobRegistry<TJob = unknown, TResult extends JobResultBase = JobResu
         onFollowUp: (items) => {
           entry.followUpBuffer.push(...items)
         },
+        onCallMetric: (call) => {
+          // Stamp the job-scoped sequence on the metric OBJECT: the handler keeps the same
+          // instance for its terminal result, so both channels carry the same `seq` and the
+          // backend mints one stable row id per call.
+          call.seq = entry.callMetricSeq++
+          entry.callMetricBuffer.push(call)
+        },
         onPhase: (next) => markPhase(next),
         log: jobLog,
       })

package/src/subagents.ts

@@ -3,7 +3,7 @@ import { createReadStream, type Dirent } from 'node:fs'
 import { basename, join } from 'node:path'
 import { claudeAssistantContent, claudeCallUsage, isObject, redactBody } from './claude-stream.js'
 import type { Logger } from './logger.js'
-import type { HarnessCallMetric, TodoProgress } from './pi.js'
+import { publishCallMetric, type HarnessCallMetric, type TodoProgress } from './pi.js'
 
 // ADR 0026 D2.1 + D3, corrected by ADR 0027. When the Claude Code CLI reviews a large PR
 // it fans the work out across parallel `Task` subagents. Two things then go dark to the
@@ -19,10 +19,10 @@ import type { HarnessCallMetric, TodoProgress } from './pi.js'
 // subagent parallelism:
 //
 //  - {@link createSliceTracker} derives the slice plan + per-slice progress from the
-//    PARENT stream alone — the `Task` tool_use dispatch and its terminal tool_result
+//    PARENT stream alone — the subagent-dispatch tool_use and its terminal tool_result
 //    DO appear there (only the subagent's intermediate turns don't), so slices/progress
-//    need no file watching (D2.1). {@link pickProgress} reconciles it with any parent
-//    TodoWrite plan (ADR 0027 Defect B);
+//    need no file watching (D2.1). `pickProgress` (./progress.ts) reconciles it with the
+//    parent's own plan (ADR 0027 Defect B);
 //  - {@link startSubagentWatcher} tails the `subagents/*.jsonl` transcripts for the
 //    heartbeat (any new bytes ⇒ `onActivity`) and sums each subagent turn's usage into
 //    the run's telemetry (D3).
@@ -42,17 +42,32 @@ import type { HarnessCallMetric, TodoProgress } from './pi.js'
 // Slice / progress tracking off the PARENT stream (D2.1)
 // ---------------------------------------------------------------------------
 
+/**
+ * The tool names the Claude Code CLI dispatches a parallel subagent under. `Agent` is what the
+ * shipped schema declares (`AgentInput` in `sdk-tools.d.ts`, carrying `description` / `prompt` /
+ * `subagent_type`); `Task` is the older name for the same dispatch. Both are matched because the
+ * harness runs against whatever CLI the image happens to bundle, and matching only the old name
+ * is what left a CLI 2.1.x pr-review reporting no slices at all.
+ *
+ * Note the asymmetry: keeping the legacy `Task` here is the one place a CLI rename could produce a
+ * FALSE signal rather than merely no signal — if a future build were to name a plain task-list
+ * tool `Task`, its writes would be counted as in-flight slices. We accept that because no shipped
+ * build does (the incremental plan tool is `TaskCreate`/`TaskUpdate`, tracked separately in
+ * `progress.ts`), and dropping legacy coverage is the more likely regression.
+ */
+const SUBAGENT_TOOL_NAMES = new Set(['Agent', 'Task'])
+
 interface TrackedSlice {
-  /** The `Task` tool_use id, used to pair the terminal tool_result. */
+  /** The dispatch's tool_use id, used to pair the terminal tool_result. */
   toolUseId: string
   /** The subagent's description (`Review <slice> slice`), rendered as the progress label. */
   description: string
   done: boolean
 }
 
-/** Tracks parallel `Task` subagents seen on the parent stream to derive slice progress. */
+/** Tracks parallel subagents seen on the parent stream to derive slice progress. */
 export interface SliceTracker {
-  /** Feed an `assistant` message's content blocks: registers any `Task` dispatches. */
+  /** Feed an `assistant` message's content blocks: registers any subagent dispatches. */
   onAssistant(content: unknown[]): void
   /** Feed a `user` message's content blocks: marks the paired subagent(s) complete. */
   onUser(content: unknown[]): void
@@ -60,8 +75,8 @@ export interface SliceTracker {
   hasSlices(): boolean
   /**
    * Progress derived from the dispatched subagents (completed / in-flight / total),
-   * or undefined when none have been dispatched. Reconciled with any parent TodoWrite
-   * plan by {@link pickProgress} — it is NOT gated off by the presence of a todo plan
+   * or undefined when none have been dispatched. Reconciled with the parent's own plan
+   * by `pickProgress` (./progress.ts) — it is NOT gated off by the presence of a plan
    * (that gate was ADR 0027 Defect B: the pr-reviewer prompt writes the plan ONCE at
    * grouping time and never marks it done, which used to permanently mask this signal).
    */
@@ -76,7 +91,8 @@ export function createSliceTracker(): SliceTracker {
     onAssistant(content) {
       if (!Array.isArray(content)) return
       for (const block of content) {
-        if (!isObject(block) || block.type !== 'tool_use' || block.name !== 'Task') continue
+        if (!isObject(block) || block.type !== 'tool_use') continue
+        if (typeof block.name !== 'string' || !SUBAGENT_TOOL_NAMES.has(block.name)) continue
         const id = typeof block.id === 'string' ? block.id : undefined
         if (!id || slices.has(id)) continue
         const input = isObject(block.input) ? block.input : {}
@@ -116,31 +132,6 @@ export function createSliceTracker(): SliceTracker {
   }
 }
 
-/**
- * Reconcile the two redundant views of the same slice work into the one to surface
- * (ADR 0027 Defect B). A pr-reviewer run has BOTH a parent `TodoWrite` plan (the slices,
- * written once at grouping time) and the {@link SliceTracker}'s `Task`-dispatch view. The
- * sequential shape advances the todo plan; the parallel-subagent shape advances ONLY the
- * slice tracker (the CLI writes the plan once and never marks it done, while the parallel
- * `Task`s report in-flight/complete). Neither alone covers both shapes, and gating the
- * slice tracker OFF whenever a todo plan exists (the old behaviour) pinned parallel runs
- * at 0%. So prefer whichever view is further along: more `completed`, then more
- * `inProgress` (an all-pending todo plan must not beat live in-flight slices), then more
- * `total` (the richer view — the todo plan can carry an extra "aggregate" entry), else the
- * todo plan. Pure + total; returns whichever single input is present when only one is.
- */
-export function pickProgress(
-  todo: TodoProgress | undefined,
-  slice: TodoProgress | undefined,
-): TodoProgress | undefined {
-  if (!todo) return slice
-  if (!slice) return todo
-  if (slice.completed !== todo.completed) return slice.completed > todo.completed ? slice : todo
-  if (slice.inProgress !== todo.inProgress) return slice.inProgress > todo.inProgress ? slice : todo
-  if (slice.total !== todo.total) return slice.total > todo.total ? slice : todo
-  return todo
-}
-
 // ---------------------------------------------------------------------------
 // Subagent transcript watcher (heartbeat + usage) (D3)
 // ---------------------------------------------------------------------------
@@ -155,6 +146,13 @@ export interface SubagentWatcherOptions {
   secrets?: string[]
   /** Fallback model id stamped on a subagent call whose transcript omits one. */
   model?: string
+  /**
+   * Streams each lifted subagent call to the live telemetry drain (the run's `RunOptions`
+   * hook). Subagent work is exactly where a long review spends most of its tokens, and it is
+   * the phase the parent stream goes quiet for — so without this a run killed mid-fan-out
+   * reports nothing at all.
+   */
+  onCallMetric?: (call: HarnessCallMetric) => void
   /** Poll cadence (ms); overridable for tests. */
   intervalMs?: number
   log?: Logger
@@ -244,23 +242,27 @@ export function startSubagentWatcher(root: string, opts: SubagentWatcherOptions)
     if (u.inputTokens === 0 && u.outputTokens === 0) return
     const content = Array.isArray(message.content) ? message.content : []
     const { text, reasoning } = claudeAssistantContent(content)
-    calls.push({
-      ...(typeof message.model === 'string'
-        ? { model: message.model }
-        : opts.model
-          ? { model: opts.model }
-          : {}),
-      // The subagent's own transcript isn't a re-sendable prompt chain, so we don't
-      // reconstruct the request side (kept empty); the response + tokens are faithful.
-      promptText: '',
-      messageCount: 0,
-      responseText: redactBody(text, secrets),
-      reasoningText: redactBody(reasoning, secrets),
-      inputTokens: u.inputTokens,
-      cachedInputTokens: u.cachedInputTokens,
-      outputTokens: u.outputTokens,
-      finishReason: typeof message.stop_reason === 'string' ? message.stop_reason : null,
-    })
+    publishCallMetric(
+      calls,
+      {
+        ...(typeof message.model === 'string'
+          ? { model: message.model }
+          : opts.model
+            ? { model: opts.model }
+            : {}),
+        // The subagent's own transcript isn't a re-sendable prompt chain, so we don't
+        // reconstruct the request side (kept empty); the response + tokens are faithful.
+        promptText: '',
+        messageCount: 0,
+        responseText: redactBody(text, secrets),
+        reasoningText: redactBody(reasoning, secrets),
+        inputTokens: u.inputTokens,
+        cachedInputTokens: u.cachedInputTokens,
+        outputTokens: u.outputTokens,
+        finishReason: typeof message.stop_reason === 'string' ? message.stop_reason : null,
+      },
+      opts.onCallMetric,
+    )
     usage.inputTokens += u.inputTokens
     usage.outputTokens += u.outputTokens
   }