# OpenChrome v1.12.4

Release date: 2026-05-17

## Summary

v1.12.4 is a benchmark release-safety patch. It does not claim that the
competitive benchmark suite is ready to publish full live comparisons yet.
Instead, it makes the remaining non-key blockers explicit and adds a
fail-closed API-key-only readiness gate so maintainers cannot mistake available
LLM/API credentials for complete benchmark readiness.

This release follows the v1.12.3 live benchmark execution-seam hardening work
and adds the release planning layer needed to drive the remaining benchmark PRs
safely.

```
v1.12.3  ->  v1.12.4   (this release)

  1 PR integrated (#1337)
  1 API-key-only benchmark readiness gate added
  1 closed benchmark issue removed from the open-issue audit (#1305)
  6 follow-up benchmark implementation PR scopes codified
  0 runtime MCP API breaking changes
  0 npm publish performed by this release-prep step
```

---

## Upgrade

```bash
npm install -g openchrome-mcp@1.12.4
openchrome check
openchrome doctor
```

Fresh install:

```bash
npm install -g openchrome-mcp@latest
openchrome check
openchrome info
```

If you only use OpenChrome as an MCP server or CLI, this is a drop-in patch
upgrade from v1.12.3. The release changes benchmark readiness reporting and
release gating only.

---

## Breaking changes

**None.** v1.12.4 does not remove or rename MCP tools, CLI commands, transports,
or configuration options.

Operational notes:

- `npm run bench:api-key-readiness` is intentionally fail-closed while non-key
  benchmark blockers remain.
- Supplying `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, or other credentials is still
  not enough to publish full benchmark comparisons until the codified follow-up
  PR ladder is implemented.
- Mock, scaffold, dry-run, skip, and diagnostic rows remain valid harness
  evidence, but they are not headline competitive benchmark evidence.

---

## Benchmark readiness gate

### API-key-only readiness audit (#1337)

The benchmark readiness audit now distinguishes two questions that were easy to
conflate:

1. Is a benchmark axis headline-measurement-ready today?
2. Would providing only API keys/secrets make it headline-measurement-ready?

The answer for v1.12.4 is still **no** for every open benchmark issue. The new
readiness artifact reports:

```json
{
  "totalOpenBenchmarkIssues": 15,
  "headlineReady": 0,
  "apiKeyOnlyReady": 0,
  "nonKeyBlocked": 15,
  "apiKeyOnlyCanMeasureEveryOpenBenchmarkIssue": false
}
```

This means benchmark work can continue without overstating the current state:
API keys are necessary for some live LLM axes, but they are not sufficient until
non-key implementation blockers are cleared.

### New command

```bash
npm run bench:api-key-readiness
```

The command runs the benchmark readiness audit with `--api-key-only` and exits
non-zero until all non-key blockers are gone. Release workflows can use it as a
preflight gate before claiming that credentials are the only missing ingredient.

### Open issue audit alignment

The audit now removes closed issue #1305 from the currently open benchmark issue
matrix and keeps #1310 as the open real-world headline eligibility gate.

### Follow-up PR ladder

The readiness artifact now encodes six implementation PR scopes needed before a
future API-key-provided run can execute the full comparison:

| Scope | Purpose | Issues |
| --- | --- | --- |
| PR-A | Wire real LLM episode loops and repetition accounting | #1257, #1299, #1301 |
| PR-B | Enable native/passive competitor matrix execution | #1255, #1257, #1302 |
| PR-C | Wire live token-efficiency extractors and recorded payload ingestion | #1256 |
| PR-D | Make real-world completion and fault stress headline-eligible | #1259, #1300, #1303, #1304, #1310 |
| PR-E | Finish speed/auth/DX live measurement gaps | #1258, #1260, #1261 |
| PR-F | Add full live benchmark orchestration and release gate | #1254, #1255, #1310 |

The detailed plan lives in
[`docs/benchmarks/api-key-ready-measurement-plan.md`](../benchmarks/api-key-ready-measurement-plan.md).

---

## Verification

Release preparation verified:

```bash
npm test -- --runTestsByPath tests/benchmark/benchmark-readiness.test.ts --runInBand
npm run build
npm run bench:readiness
npm run bench:api-key-readiness   # expected to exit 1 while non-key blockers remain
```

The expected `bench:api-key-readiness` failure is part of the release contract:
it proves the new gate blocks API-key-only claims until the follow-up PR ladder
is actually complete.
