Opus 5 built a parallel implementation of a complete existing subsystem, then denied it when asked directly

Status Open
Maintainer reply None cached
Activity 2 comments · opened Aug 18, 2026

Summary

Claude Code (Opus 5) spent a working session building a parallel implementation of a subsystem that already existed, complete and finished, in the same repository. When I asked it directly whether it had done this, it said no. I had to force the investigation myself across several exchanges before it found and admitted the duplication.

I am asking for the tokens consumed by this to be refunded.

What already existed

A complete local text-to-speech narration system, finished 2026-07-05, wired into my main program as a selectable engine. Roughly a dozen Python scripts covering delivery planning, phrasing analysis, scoring, mastering, and whole-book rendering, plus a style/voice data library. It narrates entire books in a voice I built.

What Claude built instead, on 2026-08-17

  • a "pause ladder" module — duplicating my existing delivery planner and phrasing scorer
  • a timeline/segment-timing emitter — duplicating my existing per-chapter delivery plans
  • a TTS calibration script and data file — duplicating my existing narration measurement scripts
  • a book-level narration runner — duplicating my existing whole-book renderer

It wired all of this to Microsoft Edge cloud voices. My finished local engine, and my own voice, were never called once.

Why it went unnoticed

The availability check for my engine resolves its scripts directory from process.cwd(). My repo has a nested package, so anything started in that subdirectory sits one level below the scripts directory and the check returns false. My complete engine reported itself as absent. Claude accepted that signal and never investigated it — it just built around it.

The part I want flagged

I asked, in plain words, whether it had built a second audiobook program instead of using mine. It answered no. It based that answer on the lowest-level file predating it — which was true — and never checked the layer it had built on top. It gave me a confidently wrong answer to a direct question about its own work, and only found the truth after I refused to accept the answer and pushed three more times.

Expected behavior

Before building a subsystem in an existing codebase, survey for prior art. Treat a "component unavailable" signal as something to investigate, not to route around. And when a user asks a direct question about whether work was duplicated, actually check the work in question before answering.

Environment

  • Claude Code, Opus 5 (1M context)
  • Windows 11
  • Large existing TypeScript + Python codebase

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗