An RTX 6000 Pro with 96 GB of VRAM, a qwen3.8:27b LLM in FP8, and a full 262,144-token context window: codehamr's test on porting 2.1 MB of C to HTML/three.js is brutal by design. The source file is roughly 600,000 tokens, more than twice the available window, so the agent has to explore the code and decide what matters. With a single prompt and no follow-ups, the results show that the cloud model Opus 5 finished in 21 minutes with 1,759 lines and an 'okay' port; the two local qwen3.8:27b variants, under different harnesses, produced 949 and 1,056 lines in 4 hours 18 minutes and 1 hour 40 minutes, both 'bad'. In the accompanying video, the original C precedes the three ports.

This is not a ranking of model merit. It's a single-run experiment, with a thin prompt and no human iteration. But it shifts attention to a point that pure inference benchmarks often miss: the wall clock of a self-hosted agent does not match token generation speed. The GPU hours documented here are not explained by the lines produced: 949 lines in over four hours translate to a very low average output, but we don't know how many intermediate tokens the agent generated to explore the file, how many model calls the harness made, or how much overhead context management introduced.

The most interesting detail is that the same weights under two different harnesses led to the same broken port. The 'hermes' harness, with more machinery, took more than twice as long as the 'codehamr' harness to reach a similar result. This suggests that orchestration overhead can dominate operating cost when the prompt does not give the model a navigation strategy. In a self-hosted enterprise context, this has direct TCO implications: it is not enough to compare cost per token; you need to measure cost per completed task, including GPU time wasted on low-value intermediate reasoning.

There is a structural asymmetry with the cloud: Opus 5, as a managed service, benefits from an optimized harness and likely from load balancing that reduces idle time. The local setup described uses vLLM with FP8 KV cache and maximum context: a serious configuration, but on a single GPU. The gap of 21 minutes versus 4 hours is not just a question of model capability; it is the result of how the agent uses context, how many times it rereads portions of the file, and how well the local pipeline can parallelize requests.

For those watching on-premise deployment, the test signals that the maturity of a local LLM should not be judged only by the quality of short-prompt answers. Measuring agentic behavior on long tasks, with code navigation tools and context window management, becomes essential. The choice of harness and prompt design becomes as much part of the infrastructure as the GPU. On AI-RADAR, the /llm-onpremise section gathers analytical frameworks to evaluate these trade-offs.

The author's final question — where do those hours go? — remains open. But the fact that a verbose harness did not rescue a thin prompt is a clue: compute time does not automatically turn into better output. In local deployments, that is an expensive lesson.