36Kr’s comparison of Claude Opus 5 and GPT-5.6 Sol finds a real difference in how the two models present engineering work, but its “all tools disabled” headline overstates what was tested. The article’s own description shows that both models still had access to a WAV file, Python’s standard library, and an execution environment in which generated code could be run and checked; third-party libraries and internet access were restricted, not every tool.
That distinction is more than semantic for developers deciding how to use either model in a Windows development workflow. A model that can read a local artifact and emit a standard-library Python script is operating in a constrained coding environment, not reasoning in isolation. The reported results therefore support a narrower conclusion: both models can produce useful offline Python solutions for a well-specified file-processing task, while Opus 5 was preferred by the author for its revised interface and broader design commentary.
36Kr published the account from Miao Zheng of the WeChat channel Letter AI. It describes two one-shot comparisons: a five-file shopping-cart project with six planted billing defects, and generation of a waveform visualization for a known four-second WAV file without NumPy, Matplotlib, Pillow, Librosa, internet access, or similar external dependencies.
The first prompt was deliberately sparse: “The project name is buggy-shopping-cart, how should I optimize it?” Neither model was explicitly told that six billing defects had been embedded in the code. According to 36Kr, Claude Opus 5 and GPT-5.6 Sol both identified all six: an off-by-one coupon threshold, incorrect rounding timing, use of discounted rather than original price for a coupon condition, same-type coupon stacking, an uncapped negative total, and the free-shipping calculation using the wrong price basis.
That outcome is the most important result in the article, and it undermines the claim of a decisive capability gap. On the explicit pass/fail measure the author set—finding hidden bugs without being told there were bugs—the two models tied.
The reported extra finding from Opus 5 is worthwhile, though. 36Kr says it flagged a floating-point issue in shipping-weight aggregation: a sum such as
GPT-5.6 Sol reportedly raised the broader warning that floating point is inappropriate for currency but did not connect it to the shipping calculation. If reproduced, that would show a difference in review coverage: Opus 5 noticed a defect outside the six seeded conditions. It does not show that GPT-5.6 failed to debug the project, and it certainly does not establish a general hierarchy from one five-file repository.
The more useful distinction is how the models framed their recommendations. GPT-5.6 Sol reportedly supplied a conventional bug-by-bug report with locations and fixes. Opus 5 grouped multiple defects under a root design problem: the application did not carry distinct concepts for original subtotal, discounted subtotal, coupon eligibility subtotal, and shipping-eligibility subtotal.
For an engineering team, Opus 5’s diagnosis is potentially the stronger one. Fixing six conditions independently can leave the system vulnerable to the next inconsistent price calculation. Defining an explicit pricing model, with separate named values and tests around their transitions, reduces the number of places a future change can reintroduce the same mistake.
But that is a design-review preference, not a benchmark result. The article does not publish the complete repository, the exact system prompts, model snapshots, effort settings, temperatures, token budgets, full transcripts, or a repeat-run rate. Without those details, other teams cannot determine whether the extra finding was stable behavior, an artifact of a particular run, or the effect of different runtime configurations.
That means the central problem was not audio understanding in the usual sense. It was writing a WAV parser, reducing 176,400 samples into drawable columns, and emitting a visualization using formats available without external packages. Python’s
36Kr says GPT-5.6 Sol generated an SVG-oriented tool that handles 8-, 16-, 24-, and 32-bit PCM, processes audio in blocks, performs validation, and provides an
Opus 5 initially returned terminal ASCII art, then generated an HTML visualization after the author criticized the first answer as perfunctory. The second response reportedly added summary cards, colored sections, and explanatory legends. The author’s preference for this output rested primarily on product presentation, not a demonstrated accuracy, memory, or runtime advantage.
There is also a technical claim in the comparison that needs more care. The article characterizes Opus 5’s use of batched
A bulk unpack can reduce Python-level loop overhead, but it can also create large intermediate tuples and increase peak memory use. A block-based
Anthropic positions Claude Opus 5 for complex agentic coding and enterprise work, with adaptive thinking and a one-million-token context window. Anthropic’s recent guidance, independently reported by developer outlets, says Claude Code removed more than 80% of its system prompt for newer Claude 5 models after internal evaluations showed no coding regression. The practical point is that both providers sell configurable systems rather than one immutable model personality.
A fair Opus 5-versus-GPT-5.6 comparison must therefore state:
It does not mean repository-specific instructions have become redundant. A model cannot infer an organization’s release gates, forbidden dependencies, supported Windows versions, secure build rules, data-handling restrictions, or which flaky tests are accepted temporarily. Those are facts about the environment, not deficits in a model’s general reasoning.
For Windows administrators and developers, the safest response is to simplify instructions only after measuring the result against a real task suite. Keep rules that encode non-obvious constraints—PowerShell execution policy, installer signing, Windows Server compatibility, internal package feeds, telemetry limits, and deployment rollback requirements. Remove generic coaching only if the model continues to meet those requirements without it.
The submitted comparison shows two capable models handling simple offline engineering exercises. Its evidence supports choosing Opus 5 when a team values architectural commentary and product-facing output, while GPT-5.6 Sol appears fully competitive on the two stated functional tasks. It does not support treating either a visually polished waveform or one additional ungraded bug observation as proof that the gap between them “can no longer be hidden.”
36Kr published the account from Miao Zheng of the WeChat channel Letter AI. It describes two one-shot comparisons: a five-file shopping-cart project with six planted billing defects, and generation of a waveform visualization for a known four-second WAV file without NumPy, Matplotlib, Pillow, Librosa, internet access, or similar external dependencies.
The shopping-cart test ended in a draw on the stated task
The first prompt was deliberately sparse: “The project name is buggy-shopping-cart, how should I optimize it?” Neither model was explicitly told that six billing defects had been embedded in the code. According to 36Kr, Claude Opus 5 and GPT-5.6 Sol both identified all six: an off-by-one coupon threshold, incorrect rounding timing, use of discounted rather than original price for a coupon condition, same-type coupon stacking, an uncapped negative total, and the free-shipping calculation using the wrong price basis.That outcome is the most important result in the article, and it undermines the claim of a decisive capability gap. On the explicit pass/fail measure the author set—finding hidden bugs without being told there were bugs—the two models tied.
The reported extra finding from Opus 5 is worthwhile, though. 36Kr says it flagged a floating-point issue in shipping-weight aggregation: a sum such as
3.0000000000000004 could pass into math.ceil() and push an order into the next shipping band. That is a plausible production bug in code that represents fractional physical quantities with binary floating point, especially when a pricing rule makes the boundary financially meaningful.GPT-5.6 Sol reportedly raised the broader warning that floating point is inappropriate for currency but did not connect it to the shipping calculation. If reproduced, that would show a difference in review coverage: Opus 5 noticed a defect outside the six seeded conditions. It does not show that GPT-5.6 failed to debug the project, and it certainly does not establish a general hierarchy from one five-file repository.
The more useful distinction is how the models framed their recommendations. GPT-5.6 Sol reportedly supplied a conventional bug-by-bug report with locations and fixes. Opus 5 grouped multiple defects under a root design problem: the application did not carry distinct concepts for original subtotal, discounted subtotal, coupon eligibility subtotal, and shipping-eligibility subtotal.
For an engineering team, Opus 5’s diagnosis is potentially the stronger one. Fixing six conditions independently can leave the system vulnerable to the next inconsistent price calculation. Defining an explicit pricing model, with separate named values and tests around their transitions, reduces the number of places a future change can reintroduce the same mistake.
But that is a design-review preference, not a benchmark result. The article does not publish the complete repository, the exact system prompts, model snapshots, effort settings, temperatures, token budgets, full transcripts, or a repeat-run rate. Without those details, other teams cannot determine whether the extra finding was stable behavior, an artifact of a particular run, or the effect of different runtime configurations.
“No tools” still meant local code could solve the job
The waveform exercise is framed as a harsher test: render a waveform fromtest_audio.wav while using only the Python standard library. The WAV specification was unusually favorable for an offline parser—16-bit PCM, mono, 44.1 kHz, four seconds—and the waveform’s four sections were known to the evaluator: sine, square, increasing amplitude, then decreasing amplitude.That means the central problem was not audio understanding in the usual sense. It was writing a WAV parser, reducing 176,400 samples into drawable columns, and emitting a visualization using formats available without external packages. Python’s
wave, struct, file I/O, command-line parsing, and text or SVG output provide enough capability to do all of that. The absence of NumPy or Matplotlib raises the implementation burden, but it does not make the task tool-free.36Kr says GPT-5.6 Sol generated an SVG-oriented tool that handles 8-, 16-, 24-, and 32-bit PCM, processes audio in blocks, performs validation, and provides an
argparse command-line interface. It also says the generated program was run and its amplitude checks matched the synthesized source signal. Those are good practical features, but the validation was performed by executing code in an environment with access to the test file. That is exactly the sort of local tooling a Windows developer would expect from a coding agent in a repository or sandbox.Opus 5 initially returned terminal ASCII art, then generated an HTML visualization after the author criticized the first answer as perfunctory. The second response reportedly added summary cards, colored sections, and explanatory legends. The author’s preference for this output rested primarily on product presentation, not a demonstrated accuracy, memory, or runtime advantage.
There is also a technical claim in the comparison that needs more care. The article characterizes Opus 5’s use of batched
struct.unpack() as inherently faster than GPT-5.6’s sequential struct.unpack_from() approach. That may be true for one implementation and one file size, but neither API choice settles performance by itself.A bulk unpack can reduce Python-level loop overhead, but it can also create large intermediate tuples and increase peak memory use. A block-based
unpack_from() loop can be more memory-efficient and is often the safer pattern for large files, particularly when the output needs only min/max amplitude per display bucket rather than every decoded sample. No timings, peak-memory figures, source code, or generated files are supplied, so the claimed speed advantage is unverified.The model settings are the missing record
The vendors themselves make the absence of configuration details consequential. OpenAI identifies GPT-5.6 Sol as its frontier tier and exposes it through ChatGPT, Codex, and the API with selectable effort levels. Its documentation also lists supported capabilities including web search, file search, code interpreter, hosted shell, patching, computer use, and MCP integrations.Anthropic positions Claude Opus 5 for complex agentic coding and enterprise work, with adaptive thinking and a one-million-token context window. Anthropic’s recent guidance, independently reported by developer outlets, says Claude Code removed more than 80% of its system prompt for newer Claude 5 models after internal evaluations showed no coding regression. The practical point is that both providers sell configurable systems rather than one immutable model personality.
A fair Opus 5-versus-GPT-5.6 comparison must therefore state:
- The exact API model IDs or pinned snapshots used in each run.
- The reasoning or effort level, token ceiling, temperature, and whether hidden system instructions differed.
- Whether the models had shell access, file access, patch tools, code execution, or a human copying files and commands between turns.
- The complete input repository and WAV fixture, plus expected outputs and an automated grader.
- Multiple randomized runs and error rates, including false positives in code review.
The useful operational lesson is narrower than “prompt engineering is dead”
The 80% system-prompt reduction reported around Claude Code does signal a shift: inherited instruction files deserve an audit. Teams that have accumulated pages of “always inspect this,” “never do that,” and “verify every change twice” rules may be paying tokens and adding conflicts that modern models no longer need.It does not mean repository-specific instructions have become redundant. A model cannot infer an organization’s release gates, forbidden dependencies, supported Windows versions, secure build rules, data-handling restrictions, or which flaky tests are accepted temporarily. Those are facts about the environment, not deficits in a model’s general reasoning.
For Windows administrators and developers, the safest response is to simplify instructions only after measuring the result against a real task suite. Keep rules that encode non-obvious constraints—PowerShell execution policy, installer signing, Windows Server compatibility, internal package feeds, telemetry limits, and deployment rollback requirements. Remove generic coaching only if the model continues to meet those requirements without it.
The submitted comparison shows two capable models handling simple offline engineering exercises. Its evidence supports choosing Opus 5 when a team values architectural commentary and product-facing output, while GPT-5.6 Sol appears fully competitive on the two stated functional tasks. It does not support treating either a visually polished waveform or one additional ungraded bug observation as proof that the gap between them “can no longer be hidden.”
References
- Primary source: 36 Kr
Published: Tue, 04 Aug 2026 08:20:19 GMT
Loading…
eu.36kr.com - Related coverage: tomsguide.com
I gave Claude Opus 5 and Kimi K3 15 impossible prompts — the winner surprised me | Tom's Guide
I pitted Claude Opus 5 against Kimi K3 with 15 demanding coding and infrastructure prompts to see which AI model actually performs better for developers.www.tomsguide.com - Related coverage: charlesjones.dev
Loading…
charlesjones.dev - Related coverage: kucoin.com
Loading…
www.kucoin.com