@cxi-lmai/ci-agent-platform 3.2.2 → 4.0.0

package/README.md

@@ -42,7 +42,7 @@ checks the result. The input is a spec, the output is code. Details in
 - [The full cycle](#the-full-cycle)
 - [Repository layout](#repository-layout)
 - [Install](#install)
-  - [Harness: Claude Code or omp + OpenRouter](#harness-claude-code-or-omp-openrouter)
+  - [Harness and model provider](#harness-and-model-provider)
   - [What it costs](#what-it-costs)
   - [Upgrading and removing](#upgrading-and-removing)
 - [The issue-to-code loop (details)](https://gitlab.com/cxi-lmai/ci-agent-platform/-/blob/main/docs/issue-to-code.md)
@@ -104,9 +104,10 @@ Two things are worth having before you start, though neither blocks the install.
 A `CLAUDE.md` at the repository root: most agents read it as the project's
 rulebook, and without one the reviewers work from `pipeline-config.md` alone. And
 CI credentials for whichever platform you use, which the wizard walks you
-through at the end. Any one of `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN` or
-`CLAUDE_CODE_OAUTH_TOKEN` authenticates the agents, so a Claude subscription
-works without buying API credit.
+through at the end. By default one `OPENROUTER_API_KEY` authenticates every
+agent. With `PIPE_PROVIDER=anthropic`, any one of `ANTHROPIC_API_KEY`,
+`ANTHROPIC_AUTH_TOKEN` or `CLAUDE_CODE_OAUTH_TOKEN` does instead, so a Claude
+subscription works without buying API credit.
 
 The first command is plain Node with no model in it. It refuses to run outside
 a git repository, detects your platform from the git remote (without ever
@@ -131,18 +132,33 @@ rest:
 > `--experimental-github` to answer that in advance, or `--force` to proceed
 > past a prior install it cannot account for.
 
-### Harness: Claude Code or omp + OpenRouter
-
-The pipeline runs on Claude Code by default (`PIPE_HARNESS=claude`, the
-`claude` CLI, authenticated with `ANTHROPIC_API_KEY`). Set
-`PIPE_HARNESS=omp` to run on [Oh My Pi](https://openrouter.ai/apps/oh-my-pi)
-through [OpenRouter](https://openrouter.ai) instead: one `OPENROUTER_API_KEY`
-authenticates every job, and `PIPE_MODEL_TRIAGE`/`_CODE`/`_REVIEW` accept any
-OpenRouter model id, not just Anthropic's. The two are mutually exclusive per
-project. Set the credential and the `PIPE_HARNESS` value for the harness you
-picked, not both. Claude-harness model usage is billed by Anthropic, while
-omp-harness model usage is billed by OpenRouter. GitLab only for now; GitHub
-Actions omp support is not shipped yet.
+### Harness and model provider
+
+The pipeline runs on Claude Code (`PIPE_HARNESS=claude`, the `claude` CLI)
+with its model calls routed through [OpenRouter](https://openrouter.ai)
+(`PIPE_PROVIDER=openrouter`): one `OPENROUTER_API_KEY` authenticates every
+job, and usage is billed by OpenRouter. The runner points Claude Code's
+`ANTHROPIC_BASE_URL` at OpenRouter's Anthropic-compatible endpoint, so nothing
+in the agents or skills changes. Set `PIPE_PROVIDER=anthropic` to call
+Anthropic directly with `ANTHROPIC_API_KEY` instead. Set the credential for the
+provider you picked, not both.
+
+| Role | Variable | Default model |
+|---|---|---|
+| coding (coder, test-fix, test writers) | `PIPE_MODEL_CODE`, agent tier `opus` | Claude Opus 5.5 |
+| review, docs, planning | `PIPE_MODEL_REVIEW`, agent tier `sonnet` | Claude Sonnet 5.5 |
+| triage, postmortem | `PIPE_MODEL_TRIAGE`, agent tier `haiku` | Claude Haiku 4.5 |
+
+Subagents name a tier in their frontmatter, and the runner maps each tier to
+the provider's model id through `ANTHROPIC_DEFAULT_OPUS_MODEL`,
+`_SONNET_MODEL` and `_HAIKU_MODEL`. Set any of those, or a `PIPE_MODEL_*`
+variable, as a CI variable to pick another model. On OpenRouter that can be
+any OpenRouter model id, not just Anthropic's.
+
+The older [Oh My Pi](https://openrouter.ai/apps/oh-my-pi) harness
+(`PIPE_HARNESS=omp`, OpenRouter only, GitLab only) is still shipped for
+projects that already run it, but it is no longer what the install wizard
+offers.
 
 `omp` is a Bun program, so the GitLab template's `before_script` installs
 `bun` next to it (`npm install -g bun`) — the default `node:22-bookworm` image

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cxi-lmai/ci-agent-platform",
-  "version": "3.2.2",
+  "version": "4.0.0",
   "description": "Autonomous dev pipeline on plain GitLab CI or GitHub Actions, driven by Claude Code. A labeled issue goes in, an open merge request comes out.",
   "keywords": [
     "claude",

package/payload/agents/agent-architect.md

@@ -2,7 +2,7 @@
 name: agent-architect
 description: Weekly agent-improvement lab. Reads recently merged MRs/PRs, review comments, and stuck-MR postmortems, then proposes improvements to .claude/agents/*.md files as actionable platform issues (auto-filed with the pipeline's ready label). Output is a structured markdown report consumed by the CI script. Never auto-applies changes to CLAUDE.md or .claude/settings.json.
 tools: Glob, Grep, LS, Read
-model: claude-sonnet-5
+model: sonnet
 ---
 
 You are the Agent Lab for this project's autonomous development pipeline.

package/payload/agents/code-reviewer.md

@@ -2,7 +2,7 @@
 name: code-reviewer
 description: Reviews code for bugs, logic errors, security vulnerabilities, code quality issues, and adherence to project conventions, using confidence-based filtering to report only high-priority issues that truly matter
 tools: Glob, Grep, LS, Read, Write, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
-model: claude-sonnet-5
+model: sonnet
 color: red
 ---
 

package/payload/agents/codebase-auditor.md

@@ -2,7 +2,7 @@
 name: codebase-auditor
 description: Periodic codebase auditor. Reads project conventions and docs, reads recently merged MR/PR file changes, and produces a focused report of critical convention violations and genuinely new undocumented patterns. Uses confidence-based filtering to report only issues that truly matter.
 tools: Glob, Grep, LS, Read
-model: claude-sonnet-5
+model: sonnet
 ---
 
 You are the codebase auditor. You produce a periodic report of critical convention violations and genuinely new, reusable patterns worth documenting.

package/payload/agents/coder.md

@@ -2,7 +2,7 @@
 name: coder
 description: Autonomous implementation agent. Given an issue description, explores existing patterns, implements the feature or fix, writes tests, runs the build in a self-correcting loop (up to 3 retries), and commits. Never pushes.
 tools: Agent, Bash, Edit, Glob, Grep, LS, MultiEdit, NotebookRead, Read, TodoWrite, WebFetch, WebSearch, Write, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
-model: claude-sonnet-5
+model: opus
 ---
 
 You are the autonomous coder agent for this project.

package/payload/agents/decomposer.md

@@ -1,7 +1,7 @@
 ---
 name: decomposer
 description: Decomposes a too-large issue into a dependency-ordered chain of spec-compliant sub-issues. Returns structured JSON with confidence verdict, reason, and fully authored sub-issue bodies ready for creation on the project platform.
-model: claude-sonnet-5
+model: sonnet
 ---
 
 You are the decomposer for the autonomous development pipeline.

package/payload/agents/docs-sync.md

@@ -2,7 +2,7 @@
 name: docs-sync
 description: Checks whether MR/PR code changes require updates to project docs, CLAUDE.md, or .claude/memory/. On autonomous MRs it applies the updates directly; on human MRs it reports the gaps for a comment.
 tools: Glob, Grep, LS, Read, Write, Edit
-model: claude-sonnet-5
+model: sonnet
 color: blue
 ---
 

package/payload/agents/e2e-test-writer.md

@@ -1,7 +1,7 @@
 ---
 name: e2e-test-writer
 description: Generates a single end-to-end (E2E) test spec file for a frontend issue, following the project's configured E2E framework, test directory, fixtures, test-data prefix, cleanup rules, and tags
-model: claude-sonnet-5
+model: opus
 ---
 
 You are an end-to-end (E2E) test writer. Given an issue, you produce one E2E test spec file that follows the project's configured E2E framework and conventions.

package/payload/agents/orchestrator.md

@@ -14,7 +14,7 @@ Your task: analyze an issue and classify it for autonomous implementation by the
 
 ## Scope Constraint
 
-A single coder agent session handles approximately **15 files / 600 lines of change** (default, see Capacities in the pipeline config). The coder uses the Sonnet model. Issues that touch many unrelated subsystems or require large architectural refactors exceed this limit and must be decomposed.
+A single coder agent session handles approximately **15 files / 600 lines of change** (default, see Capacities in the pipeline config). The coder uses the Opus model. Issues that touch many unrelated subsystems or require large architectural refactors exceed this limit and must be decomposed.
 
 ## Decision Criteria
 

package/payload/agents/performance-reviewer.md

@@ -2,7 +2,7 @@
 name: performance-reviewer
 description: Reviews changed data-access and hot-path code for confirmed scalability regressions such as repeated I/O, unbounded work, excessive loading, and missing batching or pagination
 tools: Glob, Grep, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput
-model: claude-sonnet-5
+model: sonnet
 color: yellow
 ---
 

package/payload/agents/release-mr.md

@@ -2,7 +2,7 @@
 name: release-mr
 description: Creates a release MR/PR from the integration branch to the production branch with a structured description listing changes, migrations, env changes, and a deploy checklist. Use when the user wants to prepare a release or merge the integration branch into production.
 tools: Bash, Glob, Grep, Read, TodoWrite
-model: claude-sonnet-5
+model: sonnet
 ---
 
 You are the release MR/PR agent. Your job is to analyze everything that changed on the integration branch since the last release to the production branch, then create (or update) a well-structured release request.

package/payload/agents/security-reviewer.md

@@ -2,7 +2,7 @@
 name: security-reviewer
 description: Reviews code for security vulnerabilities (authentication bypass, authorization flaws, injection, tenant/data isolation leaks, CSRF misconfiguration, sensitive data exposure) using confidence-based filtering to report only confirmed issues
 tools: Glob, Grep, LS, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput
-model: claude-sonnet-5
+model: sonnet
 color: red
 ---
 

package/payload/agents/test-fix.md

@@ -2,7 +2,7 @@
 name: test-fix
 description: Fixes failing tests in pipeline merge requests. Reads failing test files and their production source classes, determines root cause, fixes implementation or test as needed, verifies compilation, and commits. Never pushes.
 tools: Agent, Bash, Edit, Glob, Grep, LS, MultiEdit, NotebookRead, Read, TodoWrite, Write
-model: claude-sonnet-5
+model: opus
 ---
 
 You are the test-fix agent. Your job is to fix failing tests in a merge request, not to rewrite features.

package/payload/agents/test-writer.md

@@ -2,7 +2,7 @@
 name: test-writer
 description: Generates integration and unit tests that increase coverage for new or changed code, following the project's documented testing patterns, with a self-correcting compilation loop
 tools: Agent, Bash, Edit, Glob, Grep, LS, MultiEdit, NotebookRead, Read, TodoWrite, Write
-model: claude-sonnet-5
+model: opus
 color: green
 ---
 

package/payload/agents-omp/agent-architect.md

@@ -2,7 +2,7 @@
 name: agent-architect
 description: Weekly agent-improvement lab. Reads recently merged MRs/PRs, review comments, and stuck-MR postmortems, then proposes improvements to .claude/agents/*.md files as actionable platform issues (auto-filed with the pipeline's ready label). Output is a structured markdown report consumed by the CI script. Never auto-applies changes to CLAUDE.md or .claude/settings.json.
 tools: glob, grep, read
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the Agent Lab for this project's autonomous development pipeline.

package/payload/agents-omp/code-reviewer.md

@@ -2,7 +2,7 @@
 name: code-reviewer
 description: Reviews code for bugs, logic errors, security vulnerabilities, code quality issues, and adherence to project conventions, using confidence-based filtering to report only high-priority issues that truly matter
 tools: glob, grep, read, write, todo, web_search, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are an expert code reviewer specializing in modern software development across multiple languages and frameworks. Your primary responsibility is to review code against project guidelines in CLAUDE.md with high precision to minimize false positives.

package/payload/agents-omp/codebase-auditor.md

@@ -2,7 +2,7 @@
 name: codebase-auditor
 description: Periodic codebase auditor. Reads project conventions and docs, reads recently merged MR/PR file changes, and produces a focused report of critical convention violations and genuinely new undocumented patterns. Uses confidence-based filtering to report only issues that truly matter.
 tools: glob, grep, read
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the codebase auditor. You produce a periodic report of critical convention violations and genuinely new, reusable patterns worth documenting.

package/payload/agents-omp/coder.md

@@ -3,7 +3,7 @@ name: coder
 description: Autonomous implementation agent. Given an issue description, explores existing patterns, implements the feature or fix, writes tests, runs the build in a self-correcting loop (up to 3 retries), and commits. Never pushes.
 tools: task, bash, edit, glob, grep, read, todo, web_search, write, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
 spawns: test-writer, docs-sync
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-opus-5.5
 ---
 
 You are the autonomous coder agent for this project.

package/payload/agents-omp/decomposer.md

@@ -1,7 +1,7 @@
 ---
 name: decomposer
 description: Decomposes a too-large issue into a dependency-ordered chain of spec-compliant sub-issues. Returns structured JSON with confidence verdict, reason, and fully authored sub-issue bodies ready for creation on the project platform.
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the decomposer for the autonomous development pipeline.

package/payload/agents-omp/docs-sync.md

@@ -2,7 +2,7 @@
 name: docs-sync
 description: Checks whether MR/PR code changes require updates to project docs, CLAUDE.md, or .claude/memory/. On autonomous MRs it applies the updates directly; on human MRs it reports the gaps for a comment.
 tools: glob, grep, read, write, edit
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the documentation sync agent.

package/payload/agents-omp/e2e-test-writer.md

@@ -1,7 +1,7 @@
 ---
 name: e2e-test-writer
 description: Generates a single end-to-end (E2E) test spec file for a frontend issue, following the project's configured E2E framework, test directory, fixtures, test-data prefix, cleanup rules, and tags
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-opus-5.5
 ---
 
 You are an end-to-end (E2E) test writer. Given an issue, you produce one E2E test spec file that follows the project's configured E2E framework and conventions.

package/payload/agents-omp/orchestrator.md

@@ -14,7 +14,7 @@ Your task: analyze an issue and classify it for autonomous implementation by the
 
 ## Scope Constraint
 
-A single coder agent session handles approximately **15 files / 600 lines of change** (default, see Capacities in the pipeline config). The coder uses the Sonnet model. Issues that touch many unrelated subsystems or require large architectural refactors exceed this limit and must be decomposed.
+A single coder agent session handles approximately **15 files / 600 lines of change** (default, see Capacities in the pipeline config). The coder uses the Opus model. Issues that touch many unrelated subsystems or require large architectural refactors exceed this limit and must be decomposed.
 
 ## Decision Criteria
 

package/payload/agents-omp/performance-reviewer.md

@@ -2,7 +2,7 @@
 name: performance-reviewer
 description: Reviews changed data-access and hot-path code for confirmed scalability regressions such as repeated I/O, unbounded work, excessive loading, and missing batching or pagination
 tools: glob, grep, read, todo, web_search
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are a performance reviewer. Work with the language, framework, storage

package/payload/agents-omp/release-mr.md

@@ -2,7 +2,7 @@
 name: release-mr
 description: Creates a release MR/PR from the integration branch to the production branch with a structured description listing changes, migrations, env changes, and a deploy checklist. Use when the user wants to prepare a release or merge the integration branch into production.
 tools: bash, glob, grep, read, todo
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are the release MR/PR agent. Your job is to analyze everything that changed on the integration branch since the last release to the production branch, then create (or update) a well-structured release request.

package/payload/agents-omp/security-reviewer.md

@@ -2,7 +2,7 @@
 name: security-reviewer
 description: Reviews code for security vulnerabilities (authentication bypass, authorization flaws, injection, tenant/data isolation leaks, CSRF misconfiguration, sensitive data exposure) using confidence-based filtering to report only confirmed issues
 tools: glob, grep, read, todo, web_search
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-sonnet-5.5
 ---
 
 You are an expert security reviewer. Your primary responsibility is to identify security vulnerabilities with high precision. False positives waste developer time and erode trust in the review process.

package/payload/agents-omp/test-fix.md

@@ -2,7 +2,7 @@
 name: test-fix
 description: Fixes failing tests in pipeline merge requests. Reads failing test files and their production source classes, determines root cause, fixes implementation or test as needed, verifies compilation, and commits. Never pushes.
 tools: task, bash, edit, glob, grep, read, todo, write
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-opus-5.5
 ---
 
 You are the test-fix agent. Your job is to fix failing tests in a merge request, not to rewrite features.

package/payload/agents-omp/test-writer.md

@@ -2,7 +2,7 @@
 name: test-writer
 description: Generates integration and unit tests that increase coverage for new or changed code, following the project's documented testing patterns, with a self-correcting compilation loop
 tools: task, bash, edit, glob, grep, read, todo, write
-model: openrouter/anthropic/claude-sonnet-5
+model: openrouter/anthropic/claude-opus-5.5
 ---
 
 You are the test-writer agent. Your job is to write tests that increase coverage for new or changed code.

package/payload/ci-templates/claude-pipeline.gitlab-ci.yml

@@ -16,8 +16,9 @@
 # This template only reads its results (see the test-fix job's `needs:`).
 #
 # Override any PIPE_ variable in your own variables: block. Secrets
-# (ANTHROPIC_API_KEY, PIPE_BOT_TOKEN) are set as masked CI variables, never
-# here. Do NOT re-declare a secret in a job's variables: block as a same-name
+# (OPENROUTER_API_KEY, or ANTHROPIC_API_KEY with PIPE_PROVIDER=anthropic, and
+# PIPE_BOT_TOKEN) are set as masked CI variables, never here. Do NOT
+# re-declare a secret in a job's variables: block as a same-name
 # self-reference (FOO: "$FOO"): on GitLab it resolves to an empty string and
 # shadows the real project variable (pilot 2 finding, P6). Project variables
 # reach every job automatically. The GitHub workflows are different: there the
@@ -50,6 +51,7 @@ variables:
   # It is kept here as an explicit, harmless override.
   PIPE_PLATFORM: "gitlab"
   PIPE_HARNESS: "claude"                # "claude" (default, Claude Code CLI) or "omp" (Oh My Pi + OpenRouter)
+  PIPE_PROVIDER: "openrouter"           # Claude Code model provider: "openrouter" (default, OPENROUTER_API_KEY) or "anthropic" (ANTHROPIC_API_KEY)
   PIPE_CONFIG_PATH: ".claude/pipeline-config.md"
   PIPE_CONTEXT_DIR: "build/pipeline"
 
@@ -167,8 +169,11 @@ variables:
   # --- Caps + models ---------------------------------------------------------
   PIPE_FIX_LOOP_CAP: "2"
   # Main-loop models are passed as --model by the active harness. Defaults live
-  # in `pipeline-common.sh` under `scripts/lib/`. Users may explicitly set any
-  # PIPE_MODEL_* project CI variable. Subagents retain their frontmatter models.
+  # in `pipeline-common.sh` under `scripts/lib/` and follow PIPE_HARNESS and
+  # PIPE_PROVIDER (Opus 5.5 codes, Sonnet 5.5 reviews, Haiku 4.5 triages).
+  # Users may explicitly set any PIPE_MODEL_* project CI variable. Subagents
+  # retain their frontmatter tiers (opus/sonnet/haiku), which Claude Code
+  # resolves through ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU}_MODEL.
   PIPE_AGENT_ENV_ALLOWLIST: ""          # credential-like env names the agent-run build must receive (comma-separated; prefer empty)
 
   # --- Result files (defaults live under PIPE_CONTEXT_DIR) --------------------

package/payload/ci-templates/github/README.md

@@ -40,7 +40,7 @@ few names differ. The runner scripts in `../scripts/` are shared: they read
       - uses: actions/checkout@v4
         with: { ref: ${{ github.event.pull_request.head.ref }}, fetch-depth: 0, token: ${{ secrets.PIPE_BOT_TOKEN }} }
       - run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
-      - env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}, GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN }} }
+      - env: { OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}, ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}, GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN }} }
         run: bash "$PIPE_SCRIPTS_DIR/test-fix.sh"
   ```
 - **Fork PRs.** `workflow_run.pull_requests` is empty for PRs from forks (a

package/payload/ci-templates/github/claude-issue-pipeline.yml

@@ -21,7 +21,8 @@
 # Configuration:
 #   - Repository/org VARIABLES: PIPE_TARGET_BRANCH, PIPE_LABEL_* , PIPE_CODER_CAP,
 #     PIPE_SPEC_TEMPLATE_PATH, PIPE_GIT_NAME, PIPE_GIT_EMAIL, etc.
-#   - SECRETS: ANTHROPIC_API_KEY, PIPE_BOT_TOKEN (a bot PAT with issues +
+#   - SECRETS: OPENROUTER_API_KEY (or ANTHROPIC_API_KEY with the PIPE_PROVIDER
+#     variable set to anthropic), PIPE_BOT_TOKEN (a bot PAT with issues +
 #     contents + pull-requests + actions write). The bot PAT is required so the
 #     coder's push and the orchestrate -> code dispatch re-trigger workflows;
 #     the default GITHUB_TOKEN cannot.
@@ -73,8 +74,9 @@ env:
   PIPE_SPEC_TEMPLATE_PATH: ${{ vars.PIPE_SPEC_TEMPLATE_PATH || '.github/ISSUE_TEMPLATE/spec.md' }}
   PIPE_GIT_NAME: ${{ vars.PIPE_GIT_NAME || 'Pipeline Bot' }}
   PIPE_GIT_EMAIL: ${{ vars.PIPE_GIT_EMAIL || 'bot@pipeline.ci' }}
-  PIPE_MODEL_TRIAGE: ${{ vars.PIPE_MODEL_TRIAGE || 'haiku' }}
-  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE || 'claude-sonnet-5' }}
+  PIPE_PROVIDER: ${{ vars.PIPE_PROVIDER || 'openrouter' }}
+  PIPE_MODEL_TRIAGE: ${{ vars.PIPE_MODEL_TRIAGE }}
+  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE }}
   PIPE_AGENT_ENV_ALLOWLIST: ${{ vars.PIPE_AGENT_ENV_ALLOWLIST || '' }}
   # Runtime mapping onto the PIPE_ names the scripts read.
   PIPE_REPO: ${{ github.repository }}
@@ -99,6 +101,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run orchestrate
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN }}
         run: bash "$PIPE_SCRIPTS_DIR/orchestrate.sh"
@@ -127,6 +130,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run code
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN }}
           CODER_ISSUE: ${{ github.event.inputs.coder_issue }}

package/payload/ci-templates/github/claude-pipeline.yml

@@ -9,7 +9,8 @@
 #   - Repository/org VARIABLES (Settings > Variables): PIPE_TARGET_BRANCH,
 #     PIPE_LABEL_WIP, PIPE_LABEL_STUCK, PIPE_BOT_USER, PIPE_VERIFY_CMD, etc.
 #     Any PIPE_ variable overrides the defaults baked into the scripts.
-#   - SECRETS (Settings > Secrets): ANTHROPIC_API_KEY, and PIPE_BOT_TOKEN
+#   - SECRETS (Settings > Secrets): OPENROUTER_API_KEY (or ANTHROPIC_API_KEY
+#     with the PIPE_PROVIDER variable set to anthropic), and PIPE_BOT_TOKEN
 #     (a bot Personal Access Token). The default GITHUB_TOKEN cannot re-trigger
 #     workflows on its own push, so the fix loop needs a PAT to re-run review.
 #   - Vendor the ci-agent-platform repository's ci-templates/scripts/ into your
@@ -44,8 +45,9 @@ env:
   PIPE_COMMIT_REVIEWFIX: ${{ vars.PIPE_COMMIT_REVIEWFIX || 'Fix review findings' }}
   PIPE_GIT_NAME: ${{ vars.PIPE_GIT_NAME || 'Pipeline Bot' }}
   PIPE_GIT_EMAIL: ${{ vars.PIPE_GIT_EMAIL || 'bot@pipeline.ci' }}
-  PIPE_MODEL_REVIEW: ${{ vars.PIPE_MODEL_REVIEW || 'claude-sonnet-5' }}
-  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE || 'claude-sonnet-5' }}
+  PIPE_PROVIDER: ${{ vars.PIPE_PROVIDER || 'openrouter' }}
+  PIPE_MODEL_REVIEW: ${{ vars.PIPE_MODEL_REVIEW }}
+  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE }}
   PIPE_AGENT_ENV_ALLOWLIST: ${{ vars.PIPE_AGENT_ENV_ALLOWLIST || '' }}
   # Runtime mapping onto the PIPE_ names the scripts read.
   PIPE_REPO: ${{ github.repository }}
@@ -86,6 +88,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run review
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN || secrets.GITHUB_TOKEN }}
           PIPE_NO_GATE: "1"            # the gate step below owns the exit code
@@ -128,6 +131,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run review-fix
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN || secrets.GITHUB_TOKEN }}
           REVIEW_HAS_BUGS: "true"

package/payload/ci-templates/github/claude-test-fix.yml

@@ -49,7 +49,8 @@ env:
   PIPE_COMMIT_COVERAGE: ${{ vars.PIPE_COMMIT_COVERAGE || 'Add coverage tests' }}
   PIPE_GIT_NAME: ${{ vars.PIPE_GIT_NAME || 'Pipeline Bot' }}
   PIPE_GIT_EMAIL: ${{ vars.PIPE_GIT_EMAIL || 'bot@pipeline.ci' }}
-  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE || 'claude-sonnet-5' }}
+  PIPE_PROVIDER: ${{ vars.PIPE_PROVIDER || 'openrouter' }}
+  PIPE_MODEL_CODE: ${{ vars.PIPE_MODEL_CODE }}
   PIPE_AGENT_ENV_ALLOWLIST: ${{ vars.PIPE_AGENT_ENV_ALLOWLIST || '' }}
   PIPE_TEST_ARTIFACT: ${{ vars.PIPE_TEST_ARTIFACT || 'test-reports' }}
   PIPE_REPO: ${{ github.repository }}
@@ -91,6 +92,7 @@ jobs:
         run: command -v claude >/dev/null 2>&1 || npm install -g @anthropic-ai/claude-code
       - name: Run test-fix
         env:
+          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
           GH_TOKEN: ${{ secrets.PIPE_BOT_TOKEN || secrets.GITHUB_TOKEN }}
           PIPE_MR_IID: ${{ steps.pr.outputs.number }}

package/payload/ci-templates/scripts/lib/pipeline-common.sh

@@ -33,16 +33,24 @@ pipe_defaults() {
   : "${PIPE_CODER_CAP:=3}"
   : "${PIPE_ISSUE_SCAN:=20}"
   : "${PIPE_HARNESS:=claude}"
-  # Model defaults track the active harness. Each PIPE_MODEL_* variable remains
-  # explicitly overridable.
+  # Where the Claude Code harness sends its model calls: OpenRouter (default,
+  # one OPENROUTER_API_KEY) or Anthropic directly. omp always uses OpenRouter.
+  : "${PIPE_PROVIDER:=openrouter}"
+  # Model defaults track the active harness and provider: Opus codes, Sonnet
+  # reviews, Haiku triages. Each PIPE_MODEL_* variable remains explicitly
+  # overridable.
   if [ "$PIPE_HARNESS" = "omp" ]; then
     : "${PIPE_MODEL_TRIAGE:=openrouter/anthropic/claude-haiku-4.5}"
-    : "${PIPE_MODEL_CODE:=openrouter/anthropic/claude-sonnet-5}"
-    : "${PIPE_MODEL_REVIEW:=openrouter/anthropic/claude-sonnet-5}"
+    : "${PIPE_MODEL_CODE:=openrouter/anthropic/claude-opus-5.5}"
+    : "${PIPE_MODEL_REVIEW:=openrouter/anthropic/claude-sonnet-5.5}"
+  elif [ "$PIPE_PROVIDER" = "anthropic" ]; then
+    : "${PIPE_MODEL_TRIAGE:=claude-haiku-4-5}"
+    : "${PIPE_MODEL_CODE:=claude-opus-5-5}"
+    : "${PIPE_MODEL_REVIEW:=claude-sonnet-5-5}"
   else
-    : "${PIPE_MODEL_TRIAGE:=haiku}"
-    : "${PIPE_MODEL_CODE:=claude-sonnet-5}"
-    : "${PIPE_MODEL_REVIEW:=claude-sonnet-5}"
+    : "${PIPE_MODEL_TRIAGE:=anthropic/claude-haiku-4.5}"
+    : "${PIPE_MODEL_CODE:=anthropic/claude-opus-5.5}"
+    : "${PIPE_MODEL_REVIEW:=anthropic/claude-sonnet-5.5}"
   fi
   : "${PIPE_COMMIT_TESTFIX:=Fix test errors}"
   : "${PIPE_COMMIT_REVIEWFIX:=Fix review findings}"
@@ -135,7 +143,7 @@ pipe_defaults() {
     PIPE_METRICS_COMMIT_REPO PIPE_METRICS_REVIEW_AGENTS PIPE_METRICS_DEFECT_REVERT \
     PIPE_METRICS_DEFECT_REGRESSION PIPE_METRICS_DEFECT_REINTRODUCE \
     PIPE_METRICS_SNAPSHOT_DATE PIPE_METRICS_RAW_DIR PIPE_METRICS_MRS_FILE \
-    PIPE_HARNESS PIPE_MODEL_TRIAGE PIPE_MODEL_CODE PIPE_MODEL_REVIEW
+    PIPE_HARNESS PIPE_PROVIDER PIPE_MODEL_TRIAGE PIPE_MODEL_CODE PIPE_MODEL_REVIEW
 }
 
 pipe_log() { echo "[pipeline] $*"; }
@@ -222,14 +230,23 @@ pipe_agent_secret_var() {
   allow=" ${allow//,/ } "
   # Preserve only the active harness's built-in model credentials. Credentials
   # for the inactive harness fall through to the generic secret-name check.
+  # Claude Code on OpenRouter authenticates through ANTHROPIC_AUTH_TOKEN, which
+  # pipe_claude_provider_env copies from OPENROUTER_API_KEY, so the original
+  # (and any Anthropic OAuth token that could outrank it) is scrubbed.
   case "${PIPE_HARNESS:-claude}" in
     omp)
       [ "$name" = "OPENROUTER_API_KEY" ] && return 1
       ;;
     *)
-      case "$name" in
-        ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN|CLAUDE_CODE_OAUTH_TOKEN) return 1 ;;
-      esac
+      if [ "${PIPE_PROVIDER:-openrouter}" = "anthropic" ]; then
+        case "$name" in
+          ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN|CLAUDE_CODE_OAUTH_TOKEN) return 1 ;;
+        esac
+      else
+        case "$name" in
+          ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN) return 1 ;;
+        esac
+      fi
       ;;
   esac
   [[ "$allow" == *" $name "* ]] && return 1
@@ -272,6 +289,38 @@ pipe_require_harness() {
   fi
 }
 
+# --- Claude Code model provider ---------------------------------------------
+# OpenRouter serves the Anthropic Messages API at https://openrouter.ai/api, so
+# pointing ANTHROPIC_BASE_URL there and passing the OpenRouter key as
+# ANTHROPIC_AUTH_TOKEN routes every Claude Code call, subagents included,
+# through OpenRouter. ANTHROPIC_API_KEY must be present but empty: Claude Code
+# sends a non-empty one as a direct-Anthropic x-api-key.
+#
+# Agent frontmatter names model tiers (opus/sonnet/haiku), never concrete ids,
+# so one agent set serves both providers. ANTHROPIC_DEFAULT_*_MODEL pins each
+# tier to the provider's id for the current model; a project may override any.
+
+pipe_claude_provider_env() {
+  if [ "${PIPE_PROVIDER:-openrouter}" = "anthropic" ]; then
+    : "${ANTHROPIC_DEFAULT_OPUS_MODEL:=claude-opus-5-5}"
+    : "${ANTHROPIC_DEFAULT_SONNET_MODEL:=claude-sonnet-5-5}"
+    : "${ANTHROPIC_DEFAULT_HAIKU_MODEL:=claude-haiku-4-5}"
+  else
+    if [ -z "${OPENROUTER_API_KEY:-}" ]; then
+      pipe_log "FATAL: PIPE_PROVIDER=openrouter needs OPENROUTER_API_KEY as a masked CI variable or secret; set PIPE_PROVIDER=anthropic to run on ANTHROPIC_API_KEY instead"
+      exit 1
+    fi
+    : "${ANTHROPIC_BASE_URL:=https://openrouter.ai/api}"
+    ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY"
+    ANTHROPIC_API_KEY=""
+    : "${ANTHROPIC_DEFAULT_OPUS_MODEL:=anthropic/claude-opus-5.5}"
+    : "${ANTHROPIC_DEFAULT_SONNET_MODEL:=anthropic/claude-sonnet-5.5}"
+    : "${ANTHROPIC_DEFAULT_HAIKU_MODEL:=anthropic/claude-haiku-4.5}"
+    export ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN ANTHROPIC_API_KEY
+  fi
+  export ANTHROPIC_DEFAULT_OPUS_MODEL ANTHROPIC_DEFAULT_SONNET_MODEL ANTHROPIC_DEFAULT_HAIKU_MODEL
+}
+
 pipe_run_claude() {
   # $1 = agent label for metrics, $2 = skill invocation (e.g. "/review-mr"),
   # $3 = allowed tools (optional), $4 = model for the main loop (optional,
@@ -284,6 +333,7 @@ pipe_run_claude() {
   # checks that variable, or calls pipe_require_agent_ran below.
   local label="$1" skill="$2" tools="${3:-Agent,Read,Write,Edit,Glob,Grep,Bash}" model="${4:-}"
   pipe_require_harness claude
+  pipe_claude_provider_env
   local stdin_file; stdin_file=$(mktemp)
   cat > "$stdin_file" || true
   PIPE_AGENT_RC=0

package/payload/ci-templates/scripts/lib/usage-capture-omp.sh

@@ -1,18 +1,37 @@
 # shellcheck shell=bash
 # Source-only library. Wraps an `omp --mode json` invocation, sums usage/cost
-# from the agent_end event's message transcript, writes a metrics record, and
-# surfaces the assistant text on stdout — the omp equivalent of
+# across the whole spawn tree the invocation paid for, writes a metrics record,
+# and surfaces the assistant text on stdout — the omp equivalent of
 # usage-capture.sh's capture_claude. Same function contract, same metrics
-# record shape (bar the harness-specific exit-code key), different event
-# parsing because omp's schema differs from Claude's stream-json.
+# record shape (bar the harness-specific exit-code and completeness keys),
+# different event parsing because omp's schema differs from Claude's
+# stream-json.
 #
-# Schema verified live against a real omp install (18.0.6): the final
-# "agent_end" line carries {"type":"agent_end","messages":[...],
+# Schema verified against omp 18.1.21 (minimum supported; the nested
+# `extractedToolData.task` carrier below does not exist in older lines): the
+# final "agent_end" line carries {"type":"agent_end","messages":[...],
 # "isTerminal":true}. Each assistant message in `messages[]` carries its own
 # `usage` object (per-message, not session-cumulative) and top-level
 # `model`/`provider`/`duration` fields. See
 # docs/superpowers/specs/2026-08-26-omp-openrouter-harness-design.md section 3
-# for the full verification record.
+# for the original verification record and docs/metrics.md for the aggregation
+# semantics.
+#
+# Subagents run as child sessions, so their model calls are never parent
+# assistant messages. omp exposes them one level at a time instead:
+#
+#   - a blocking `task` call's tool result carries `details.usage`, the merge
+#     of `details.results[].usage`, each of which counts only that child's own
+#     assistant messages;
+#   - that child's own `task` calls arrive under
+#     `details.results[].extractedToolData.task[]` as the same shape again
+#     (omp registers a subprocess handler for the tool), so the tree recurses
+#     with every level counted exactly once;
+#   - an async spawn exposes no usage at all: the delivery message carries
+#     jobs, not tokens. Such children are counted as unmeasured and the record
+#     marks itself incomplete rather than passing a parent-only figure off as
+#     the total. The CI config overlay in pipeline-common.sh keeps task
+#     execution blocking precisely so this stays the exceptional case.
 #
 # Usage:   capture_omp <agent_name> -- <args to pass to `omp`...>
 # Stdin:   forwarded to `omp` stdin
@@ -21,6 +40,62 @@
 
 set -u
 
+# Aggregates one `agent_end` object into a tab-separated row:
+# input, output, cacheWrite, cacheRead, cost, parent duration, subagent cost,
+# measured subagents, unmeasured subagents, model. The model is deliberately
+# last: it is the one field that can be empty (a run killed before its first
+# assistant turn), and tab is an IFS *whitespace* character, so `read` would
+# collapse an empty leading column and shift every number one place left.
+# Kept to jq 1.6 features (Debian stable ships 1.6; see metrics-snapshot.sh),
+# and assigned from a plain quoted string rather than a `cat` heredoc: sourcing
+# this library must not need a single external binary, because callers run it
+# with a deliberately minimal PATH.
+_OMP_USAGE_JQ='
+def usum(f): map(f // 0) | add // 0;
+# One `task` tool result, recursing into the nested calls its children made.
+def level:
+  ([.results[]? | select(.usage != null) | .usage]) as $own
+  | (if ($own | length) > 0 then $own
+     elif (.usage != null) then [.usage]
+     else [] end) as $usage
+  | (if ($own | length) > 0 then ($own | length)
+     elif (.usage != null) then 1
+     else 0 end) as $measured
+  # Count every agent the call spawned, measured or not. An async spawn
+  # settles with no result row at all, so the progress list is the only place
+  # it appears — including when it has a measured sibling, which must not mask
+  # it. A sync child that failed before its first request has a row but no
+  # usage, and is counted by the same subtraction.
+  | ([.results[]?] | length) as $result_rows
+  | ([.progress[]?] | length) as $progress_rows
+  | (if $progress_rows > $result_rows then $progress_rows else $result_rows end) as $spawned
+  | (if $spawned > $measured then ($spawned - $measured) else 0 end) as $gaps
+  | ([.results[]? | (.extractedToolData.task // [])[]? | level]) as $nested
+  | {
+      input:      (($usage | usum(.input))      + ($nested | usum(.input))),
+      output:     (($usage | usum(.output))     + ($nested | usum(.output))),
+      cacheWrite: (($usage | usum(.cacheWrite)) + ($nested | usum(.cacheWrite))),
+      cacheRead:  (($usage | usum(.cacheRead))  + ($nested | usum(.cacheRead))),
+      cost:       (($usage | usum(.cost.total)) + ($nested | usum(.cost))),
+      measured:   ($measured    + ($nested | usum(.measured))),
+      unmeasured: ($gaps + ($nested | usum(.unmeasured)))
+    };
+([.messages[]? | select(.role == "assistant")]) as $parent
+| ([.messages[]? | select(.role == "toolResult" and .toolName == "task") | .details | level]) as $subs
+| [
+    (($parent | usum(.usage.input))      + ($subs | usum(.input))),
+    (($parent | usum(.usage.output))     + ($subs | usum(.output))),
+    (($parent | usum(.usage.cacheWrite)) + ($subs | usum(.cacheWrite))),
+    (($parent | usum(.usage.cacheRead))  + ($subs | usum(.cacheRead))),
+    (($parent | usum(.usage.cost.total)) + ($subs | usum(.cost))),
+    ($parent | usum(.duration)),
+    ($subs | usum(.cost)),
+    ($subs | usum(.measured)),
+    ($subs | usum(.unmeasured)),
+    ([$parent[] | ((.provider // "") + "/" + (.model // ""))] | last // "")
+  ] | @tsv
+'
+
 capture_omp() {
   local agent="$1"; shift
   [ "${1:-}" = "--" ] && shift
@@ -51,23 +126,32 @@ capture_omp() {
 
   # Extract the final agent_end event (last line that begins with
   # {"type":"agent_end"). Its usage is per-message (one API call each), not
-  # pre-aggregated like Claude's single "result" event, so sum it ourselves.
+  # pre-aggregated like Claude's single "result" event, and subagent usage sits
+  # in the `task` tool results, so aggregate the tree ourselves
+  # (see _OMP_USAGE_JQ above).
   local result_line
   result_line=$(grep '^{"type":"agent_end"' "$stream_file" | tail -1 || true)
 
-  local model input output cache_c cache_r cost duration
-  if [ -n "$result_line" ]; then
-    model=$(echo "$result_line" | jq -r '[.messages[]? | select(.role=="assistant") | ((.provider // "") + "/" + (.model // ""))] | last // ""')
-    input=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.input // 0] | add // 0')
-    output=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.output // 0] | add // 0')
-    cache_c=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.cacheWrite // 0] | add // 0')
-    cache_r=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.cacheRead // 0] | add // 0')
-    cost=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.cost.total // 0] | add // 0')
-    duration=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .duration // 0] | add // 0')
+  local model input output cache_c cache_r cost duration sub_cost measured unmeasured
+  local row=""
+  [ -n "$result_line" ] && row=$(echo "$result_line" | jq -r "$_OMP_USAGE_JQ" 2>/dev/null || true)
+  if [ -n "$row" ]; then
+    IFS=$'\t' read -r input output cache_c cache_r cost duration sub_cost measured unmeasured model \
+      <<< "$row"
   else
+    # No parsable agent_end (crash, killed run): the parent's own wall time is
+    # the only thing known, and nothing can be claimed about subagents.
     model=""; input=0; output=0; cache_c=0; cache_r=0; cost=0; duration=$wall_ms
+    sub_cost=0; measured=0; unmeasured=0
   fi
   [ -n "${PIPE_CAPTURE_MODEL:-}" ] && [ -z "$model" ] && model="$PIPE_CAPTURE_MODEL"
+  # Partial the moment any spawned agent's usage was not exposed: the totals
+  # above then cover less than the OpenRouter account was charged for. A run
+  # with no parsable agent_end is the extreme case — not even the parent's own
+  # tokens are known — so its zeros must not read as a settled bill either.
+  local complete=true
+  [ -z "$row" ] && complete=false
+  [ "$unmeasured" -gt 0 ] && complete=false
 
   # Recover the user-facing text (concatenate all assistant text blocks) so
   # downstream consumers that read `omp -p`'s stdout still work.
@@ -75,10 +159,11 @@ capture_omp() {
     | jq -r 'select(.message.role=="assistant") | .message.content[]? | select(.type=="text") | .text' \
     || true
 
-  # Write metrics record. Same field names as capture_claude's record; only
-  # the harness-specific exit-code key differs (omp_exit_code vs
-  # claude_exit_code), by the same convention the two capture_* files
-  # already use for their own harness-labelled fields.
+  # Write metrics record. Same field names as capture_claude's record; the
+  # harness-specific exit-code key differs (omp_exit_code vs
+  # claude_exit_code), by the same convention the two capture_* files already
+  # use for their own harness-labelled fields, and the usage_* /subagent_*
+  # keys describe a scope Claude Code's single `result` event does not have.
   local record_stamp record_file
   record_stamp=$(date +%s%N)
   record_file="$metrics_dir/${job_name}-${job_id}-${record_stamp}.json"
@@ -100,6 +185,10 @@ capture_omp() {
     --argjson duration "$duration" \
     --argjson wall_ms "$wall_ms" \
     --argjson exit_code "$exit_code" \
+    --argjson sub_cost "$sub_cost" \
+    --argjson measured "$measured" \
+    --argjson unmeasured "$unmeasured" \
+    --argjson complete "$complete" \
     '{
       ts: $ts, agent: $agent, event: $event, model: $model,
       pipeline_id: $pipeline_id, job_id: $job_id, job_name: $job_name,
@@ -107,7 +196,10 @@ capture_omp() {
       input_tokens: $input, output_tokens: $output,
       cache_creation_tokens: $cache_c, cache_read_tokens: $cache_r,
       total_cost_usd: $cost, duration_ms: $duration, wall_ms: $wall_ms,
-      omp_exit_code: $exit_code
+      omp_exit_code: $exit_code,
+      usage_scope: "tree", usage_complete: $complete,
+      subagents_measured: $measured, subagents_unmeasured: $unmeasured,
+      subagent_cost_usd: $sub_cost
     }' > "$record_file"
 
   # If the agent failed, forward stderr so debugging still works, and keep a

package/payload/ci-templates/scripts/lib/usage-capture.sh

@@ -42,9 +42,11 @@ capture_claude() {
   end_ns=$(date +%s%N)
   local wall_ms=$(( (end_ns - start_ns) / 1000000 ))
 
-  # Extract the result event (last line that begins with {"type":"result")
+  # Extract the last result event. Match on the parsed type, not a line prefix:
+  # Claude Code 2.1 no longer emits "type" as the first key, and a prefix grep
+  # silently recorded every run as zero usage. fromjson? skips non-JSON lines.
   local result_line
-  result_line=$(grep '^{"type":"result"' "$stream_file" | tail -1 || true)
+  result_line=$(jq -cR 'fromjson? | select(.type? == "result")' "$stream_file" 2>/dev/null | tail -1 || true)
 
   local model input output cache_c cache_r cost duration
   if [ -n "$result_line" ]; then
@@ -67,9 +69,8 @@ capture_claude() {
 
   # Recover the user-facing text (concatenate all assistant text blocks) so
   # downstream consumers that read `claude`'s stdout still work.
-  grep '^{"type":"assistant"' "$stream_file" \
-    | jq -r '.message.content[]? | select(.type=="text") | .text' \
-    || true
+  jq -rR 'fromjson? | select(.type? == "assistant") | .message.content[]? | select(.type=="text") | .text' \
+    "$stream_file" 2>/dev/null || true
 
   # Write metrics record
   local record_stamp record_file

package/payload/skills/init-pipeline-config/SKILL.md

@@ -37,7 +37,7 @@ Source paths: `<root>` below means the first candidate that actually contains `t
 
 Do not hand the user a homework list. Walk them through it:
 
-1. Start with one confirmation of the detected basics: "The pipeline will target branch `<detected>` on `<platform>`. Correct?" Detected values are proposals to confirm, never open questions. When the detected platform is GitLab, ask in the same message which harness to run: Claude Code (default, needs `ANTHROPIC_API_KEY`) or omp + OpenRouter (needs `OPENROUTER_API_KEY` and accepts any OpenRouter model). Record the answer as `PIPE_HARNESS` (`claude` or `omp`). When the detected platform is GitHub, record `PIPE_HARNESS=claude`, state that omp and OpenRouter support is not shipped for GitHub yet, and do not offer omp as an option.
+1. Start with one confirmation of the detected basics: "The pipeline will target branch `<detected>` on `<platform>`. Correct?" Detected values are proposals to confirm, never open questions. Ask in the same message where Claude Code gets its models: OpenRouter (default, needs `OPENROUTER_API_KEY`) or Anthropic directly (needs `ANTHROPIC_API_KEY`). Record the answer as `PIPE_PROVIDER` (`openrouter` or `anthropic`) and `PIPE_HARNESS=claude`. Do not offer the omp harness; it stays available on GitLab for a project that asks for it by name (`PIPE_HARNESS=omp`, `OPENROUTER_API_KEY`), and is not shipped for GitHub.
 2. Split the remaining `TODO`s into two groups. **Defaultable:** the repo gives a defensible answer (coverage tooling absent means the policy is `not used`, Domain Check candidates read from the code, standard paths). Apply these without asking and keep them for the summary in step 4. **Genuinely open:** the repo gives no signal at all (a convention nobody wrote down, a check only a human knows about). Only these earn a question. Branch naming is not a question: with no repository convention use `<issue-iid>-<kebab-title>`, which is exactly what the runner accepts.
 3. Ask one scheduling question because frequency is a project policy, not a detectable technical fact: should the issue loop stay manual/disabled, run nightly on selected days, or use a custom cron? Recommend manual/disabled until both smoke tests pass. For a schedule, record days, local time, and time zone. Convert to UTC only for GitHub Actions; GitLab stores the chosen cron time zone. Then ask the other genuinely open items one concrete question at a time, in config order, each with a suggested default when possible. In a typical repo this is one to three questions total. Do not ask for the bot account username: the runner resolves it from the token at runtime (`platform_resolve_bot_user`); the account itself gets created with the token in phase 4. Apply each answer to the config immediately; the user never edits the file by hand during this phase.
 4. Close with one review summary of everything that was set: detected, defaulted, and answered, with the applied Domain Checks listed item by item. Invite the user to add, remove, or change anything; apply the edits. This summary is the safety net that lets steps 2-3 default aggressively.
@@ -50,7 +50,7 @@ Do this yourself; it is mechanical. The human only approves the diff. When the `
 **GitLab** (detected in phase 1):
 
 1. Create `.claude-pipeline/` and copy `<root>/ci-templates/claude-pipeline.gitlab-ci.yml` and `<root>/ci-templates/scripts/` into it.
-2. Edit the project `.gitlab-ci.yml`: ensure the stages the template needs (`orchestrate, code, test, review`), add the `include:` of the vendored template, and add the non-secret `PIPE_*` values from the config that differ from the template defaults (typically `PIPE_VERIFY_CMD`, `PIPE_TEST_REPORT_GLOB`) as top-level `variables:`. Always write `PIPE_TARGET_BRANCH` with the branch detected in phase 1, as a literal: a nested `$CI_DEFAULT_BRANCH` is not expanded inside `rules:` comparisons and would silently disable every MR job (E2E finding N-3). You know the values since phase 1; wiring them now keeps phase 4 free of commits. Do not touch the project's own jobs without asking. When phase 2 chose `omp`, add `PIPE_HARNESS: "omp"` to that same `variables:` block (the template default is `claude`).
+2. Edit the project `.gitlab-ci.yml`: ensure the stages the template needs (`orchestrate, code, test, review`), add the `include:` of the vendored template, and add the non-secret `PIPE_*` values from the config that differ from the template defaults (typically `PIPE_VERIFY_CMD`, `PIPE_TEST_REPORT_GLOB`) as top-level `variables:`. Always write `PIPE_TARGET_BRANCH` with the branch detected in phase 1, as a literal: a nested `$CI_DEFAULT_BRANCH` is not expanded inside `rules:` comparisons and would silently disable every MR job (E2E finding N-3). You know the values since phase 1; wiring them now keeps phase 4 free of commits. Do not touch the project's own jobs without asking. When phase 2 chose `anthropic`, add `PIPE_PROVIDER: "anthropic"` to that same `variables:` block (the template default is `openrouter`). When the project asked for omp, add `PIPE_HARNESS: "omp"` there instead (the template default is `claude`).
 3. Check the project's own test job: when neither its `rules:` nor a `workflow:` block makes it run in `merge_request_event` pipelines, the template's `test-fix` job can never fire (its `needs: test` finds no test job in the MR pipeline, E2E finding N-4). Tell the user and offer a concrete diff that adds the missing rule. Apply it only after they agree.
 4. Copy `<root>/templates/spec-issue.template.md` to `.gitlab/issue_templates/Spec.md` (or the path the user chose in phase 2). When that file already exists, show the diff and ask before replacing it. An issue template is project-owned content, and the ground rule above covers the config and the CI file by name, so this one has to be said explicitly.
 
@@ -75,7 +75,7 @@ Never take the values. And never dump the whole checklist at once: this phase is
 
 The steps, in this order (GitLab has 7, GitHub 6, number the counter accordingly):
 
-1. The model credential for the platform and chosen harness. For GitHub, guide only `ANTHROPIC_API_KEY` (https://console.anthropic.com/settings/keys) as a repository secret. For GitLab with Claude Code, guide `ANTHROPIC_API_KEY` as a masked CI variable. For GitLab with omp, guide `OPENROUTER_API_KEY` (https://openrouter.ai/settings/keys) as a masked CI variable. GitLab model credentials must not be protected when MR pipelines run from unprotected branches.
+1. The model credential for the chosen provider. For OpenRouter (the default, and always for omp), guide `OPENROUTER_API_KEY` (https://openrouter.ai/settings/keys). For `PIPE_PROVIDER=anthropic`, guide `ANTHROPIC_API_KEY` (https://console.anthropic.com/settings/keys), and on GitHub also the repository variable `PIPE_PROVIDER=anthropic`. On GitHub the credential is a repository secret, on GitLab a masked CI variable. GitLab model credentials must not be protected when MR pipelines run from unprotected branches.
 2. `PIPE_BOT_TOKEN`: GitLab project access token with `api` + `write_repository`, masked and hidden but not protected when ordinary unprotected feature branches need MR review/fix jobs; GitHub PAT with issues, contents, pull-requests and Actions write. Explain that protected GitLab variables work only when the project's protected-MR conditions are satisfied.
 3. GitLab only: `PIPE_TRIGGER_TOKEN` (Settings > CI/CD > Pipeline trigger tokens) for the orchestrate-to-code dispatch.
 4. The non-secret `PIPE_*` variables that differ from the defaults: these were already wired into the CI file in phase 3, so this step is normally a one-line "already wired, skipping". Only when something changed during phase 4 edit the CI file again (part of the walkthrough, no extra approval beyond showing the diff).
@@ -91,6 +91,6 @@ The smoke tests are the last step and the wizard drives them. The review smoke r
 
 1. Announce it in one line and prepare it: a branch named by the phase 2 convention, one small harmless change, an MR/PR against the target branch carrying the wip label. Then ask the one question of this phase: confirm the push plus MR/PR creation (ground rule: never push silently). One yes covers both. On GitLab without `glab`, create the MR with git push options (`git push -o merge_request.create -o merge_request.target=<target> -o merge_request.label=<wip label> origin <branch>`), no token or CLI needed. When no `merge_request_event` pipeline appears within about a minute of the MR existing, create it yourself with `POST /projects/:id/merge_requests/:iid/pipelines` (the bot token is set by phase 4). On GitHub without `gh`, push and print the compare URL for the user to open the PR.
 2. Check the run yourself with a single status query (`glab ci status` / `gh run list` for the run), or one short bounded wait, then report. Do not launch a blind polling loop that blocks for many minutes. If the jobs have not started or finished yet, say so and give the user the one command to re-check, rather than waiting them out. Scheduled pipelines and crons are best-effort and can lag by minutes, so an unstarted scheduled run is expected, not a failure. Expect, once it runs: the `review` job runs, a review comment from the bot account appears on the MR/PR, `review.env` and a metrics JSON land in `$PIPE_CONTEXT_DIR`. Report the result with a link to the MR/PR and the bot comment.
-3. On failure, read the job log yourself and say what is wrong and what to change. The common causes are a missing credential for the selected harness (`ANTHROPIC_API_KEY` or `OPENROUTER_API_KEY`), a `PIPE_BOT_TOKEN` without comment/write scope, and an explicitly set `PIPE_BOT_USER` not matching the token's account (leave it unset; the runner resolves it from the token).
+3. On failure, read the job log yourself and say what is wrong and what to change. The common causes are a missing credential for the selected provider (`OPENROUTER_API_KEY`, or `ANTHROPIC_API_KEY` with `PIPE_PROVIDER=anthropic`), a `PIPE_BOT_TOKEN` without comment/write scope, and an explicitly set `PIPE_BOT_USER` not matching the token's account (leave it unset; the runner resolves it from the token).
 4. After the review smoke test passes, offer a separate end-to-end issue-loop smoke test. This is the only test that proves issue -> triage -> code -> MR/PR rather than only the review half, so it is worth running. Run it only after explicit approval, then watch it through MR/PR creation. Steps: create one small issue whose full spec sits in the issue DESCRIPTION following `spec-issue.template.md` (a spec pasted into a comment does not count, the pipeline reads the spec from the description), apply the ready label, then start orchestrate IMMEDIATELY with a manual run rather than a schedule. On GitLab that is Run pipeline on the target branch with variable `PIPE_ORCHESTRATE=1` (pipeline source `web`, which the orchestrate rule already allows), on GitHub the `workflow_dispatch` of the issue pipeline. Do not set up a cron schedule for this test. A cron is only for ongoing autonomy later and adds minutes of best-effort delay, while the manual run starts within seconds. It spends another triage plus coder run, pushes a feature branch, and opens an MR/PR.
 5. Close with the final recap, one table: every setting that matters (target branch, branch convention, labels, verify command, report path, image, caps, models, schedule), its value, and its origin (detected / default / answered). Under the table, state what was committed and pushed, both smoke-test results (or `not run`), and whether the issue schedule is active or manual. End with a clear "done": the user must never have to ask what state the repo is in.