저는 LM Studio에서 Qwen을 사용하여 SOL 벤치마크를 수행했고, Hermes를 사용하여 Tetris 벤치마크를 구축했습니다. 결론을 말씀드리자면, ThinkingCap은 추론 토큰 (reasoning tokens)을 훨씬 적게 사용했지만, 별도의 사고 블록 (thinking blocks)을 적게 사용하지는 않았습니다. 또한 Unsloth는 더 빠름에도 불구하고 실질적으로 더 나은 Tetris 구현 결과물을 만들어냈습니다.

지표 (Metric) | Unsloth (qwen3.6-27b-mtp@q6_k) | ThinkingCap (thinkingcap-qwen3.6-27b-mtp)

승자 | Task prompt → final report | 8m 55s | 6m 54s (ThinkingCap — 22.7% 더 빠름)
Prompt → first implementation | write 2m 05s | 1m 16s (ThinkingCap)
Assistant API calls | 34 | 56 (Unsloth — 도구 사용의 변동(tool churn)이 훨씬 적음)
Tool calls | 33 | 54 (Unsloth)
Input tokens | 1.64M | 3.00M (Unsloth)
Output tokens | 26,301 | 18,643 (ThinkingCap — 29.1% 적음)
Reasoning tokens | 11,256 | 4,205 (ThinkingCap — 62.6% 적음)
Stored reasoning/thinking blocks | 32 | 48 (Unsloth — 블록 수가 더 적음)

Thinking-cap의 주장: 확인됨, 하지만 오직 토큰 측면에서만 그렇습니다.
세션 DB에는 reasoning_tokens가 직접 기록됩니다:
Unsloth: 11,256
ThinkingCap: 4,205
따라서 ThinkingCap은 7,051개의 추론 토큰을 덜 사용했습니다. 이는 Unsloth 전체의 37.4%에 불과합니다. 하지만 만약 "사고 블록 (thinking blocks)"이 저장된 추론 내용을 포함하는 별개의 어시스턴트 턴 (assistant turns)을 의미한다면, 결과는 반대가 됩니다:
Unsloth: 32개 블록
ThinkingCap: 48개 블록

즉, ThinkingCap은 전반적으로 생각을 덜 했지만, 그 생각을 더 많은 턴에 걸쳐 파편화했습니다. 또한 입력 토큰을 83% 더 많이 사용했고 도구 호출 (tool calls)을 63% 더 많이 수행했는데, 이는 주로 한 번의 호출당 하나의 테스트만 수행하는 매우 수다스럽고 얕은 테스트 접근 방식 때문이었습니다.

코드 품질 감사 (Code-quality audit)
🥇 Unsloth: 더 나은 기능적 결과물을 보여주었으나, 완벽하지는 않음
Artifact: /home/snoop/lab/benchmark/index.html
최종 크기: 16,831 bytes
브라우저에서 JS 콘솔 오류 없이 깔끔하게 로드되었습니다.

잘 구현된 점:
적절한 10×20 보드, 7-bag, 모든 조각, 고스트 (ghost), 점수/레벨, 홀드 (hold), 프리뷰. 실행 중에 실제 홀드 버그를 찾아내기도 했습니다: spawn_piece()가 can_hold를 초기화하여, 잠기기 전에 반복적인 홀드가 가능하게 만드는 문제였습니다. 모델은 해당 결함을 패치했습니다. 일반적인 홀드, 하드 드롭 (hard drop), 생성 충돌 (spawning collision), 그리고 상단 도달 경로 (top-out paths)는 ThinkingCap보다 실질적으로 더 뛰어났습니다.

이는 단 하나의 라인이 아니라 1/2/3/4 라인 클리어 (line clear) 동작을 검증했습니다. 독립적인 감사 (audit)에서 발견된 남은 결함은 CCW (반시계 방향) SRS 월 킥 (wall kicks)이 잘못되었다는 점입니다. 해당 월 킥 테이블은 CW (시계 방향) 및 역전이 (reverse transitions)를 결합하고 있지만, CCW 회전은 잘못된 절반을 먼저 반복합니다. 이로 인해 장애물 주변에서 조각이 잘못된 방향으로 킥될 수 있습니다. 일시정지/게임 오버 (game-over) 상태에서도 requestAnimationFrame이 무한히 스케줄링됩니다. 이는 중복 루프 가속 버그는 아니지만, 일시정지 중이거나 게임이 종료되었을 때 디스플레이 리프레시당 하나의 프레임 콜백을 낭비하게 합니다. 회전 실패 시 락 지연 (lock delay)이 초기화됩니다. 불가능한 회전을 반복해서 누르면 지면에 닿은 조각이 무한히 유지될 수 있습니다. 일시정지 상태에서 시작할 경우, 안전하게 재개하는 대신 현재 조각을 교체해 버립니다. 평가: 디버깅과 수리를 실제로 시도한, 플레이 가능한 기준점 (baseline)입니다. 정확성 결함이 존재하지만, ThinkingCap의 실패 사례보다는 범위가 좁습니다. 🥈 ThinkingCap: 더 빠르고 추론 비용 (reasoning cost)은 낮지만, 벤치마크에 실패한 코드 Artifact: /home/snoop/lab/benchmark/thinkingcap-tetris/index.html 최종 크기: 18,364 bytes 치명적 결함 초기 페이지 로드 시 예외 (exception)가 발생합니다. 보드가 초기화되기 전에 render()를 호출하여 다음과 같은 오류를 발생시킵니다: TypeError: Cannot read properties of undefined (reading '0'). 브라우저 세션은 초기 로드 시 포착되지 않은 예외 (uncaught exception)를 기록했습니다. 버튼은 충돌 전에 등록되므로 'Start'로 복구할 수는 있지만, 약속된 깨끗한 초기 상태는 깨진 상태이며, R은 해당 상태에서 게임을 시작할 수 없습니다. 다음 조각 미리보기 (Next-piece preview)가 영구적으로 잘못되어 있습니다. nextQueue가 렌더링되지만 조각을 생성할 때 소비되지 않습니다. 새로운 활성 조각들은 백 (bag)에서 직접 오지만, 표시된 Next 목록은 변하지 않고 오해를 불러일으킵니다. 생성/홀드 (spawn/hold) 상단 도달 충돌 (top-out collision)이 잘못된 수직 위치를 사용합니다. 조각들이 row: -2에서 생성되지만, 충돌 체크는 row: 0에서 테스트됩니다. 이는 조기 게임 오버를 유발할 수 있으며, 홀드된 조각을 다시 가져올 때도 영향을 미칩니다. 월 킥 테이블은 그렇게 라벨링되어 있음에도 불구하고 유효한 SRS가 아닙니다.

I-piece 테이블에는 표준 SRS (Super Rotation System)가 5단계 테스트 시퀀스를 사용하는 것과 달리, 4칸 수평 킥 (horizontal kick) 시도가 포함되어 있습니다. Pause 기능 또한 rAF (requestAnimationFrame) 콜백을 지속적으로 실행 상태로 유지하지만, Unsloth와 달리 게임 종료 (game-over) 후에는 체인을 적절히 중단합니다. 테스트 품질 문제에 대해, ThinkingCap의 최종 보고서는 15개 테스트가 모두 통과되었다고 주장했으나, 여러 "테스트"들은 단지 함수 호출 후 특정 변수가 여전히 존재하는지만을 확인했습니다. 예를 들어, 잠금 (locking) 이후 "piece !== undefined"를 확인한 것은 floor locking 동작을 증명하지 못했습니다. 한 줄 지우기 (One-line clearing)는 테스트되었으나, 2/3/4줄 지우기에 대해서는 철저하게 검증되지 않았음을 인정했습니다. 초기 로드 예외 (initial-load exception)가 감지되었으나, 브라우저/파일 프로토콜의 부산물로 치부되어 무시되었습니다. 하지만 독립적인 재현을 통해 이것이 게임 코드 내에 존재함이 증명되었습니다. 평가: 생성 속도는 빠르지만, 결과물이 벤치마크의 "오류 없이 즉시 실행 가능하며, 테스트 및 수정 가능해야 함"이라는 요구 사항을 충족하지 못합니다.

최종 순위
최고의 코드 / 신뢰성: Unsloth. 남은 결함이 더 적고 근본적이지 않았으며, 깔끔하게 로드되었고, 실제 버그를 찾아 수정했으며, 요구되는 동작들에 대해 더 신뢰할 수 있는 커버리지를 수행했습니다.
가장 빠른 완료: ThinkingCap. 엔드 투 엔드 (end-to-end) 기준으로 2분 02초 더 빨랐습니다. 첫 구현까지는 대략 50초 더 빨랐습니다. 여기에는 ThinkingCap 세션 중 발생한 사용자 중단이 포함되어 있습니다. 이를 보정하지 않더라도 ThinkingCap이 시간 면에서 승리합니다.
가장 적은 총 내부 추론: ThinkingCap. 추론 토큰 (reasoning tokens)이 62.6% 더 적었습니다. 하지만 추론 블록 (reasoning blocks)이 더 적은 것은 아닙니다. Unsloth의 32개에 비해 48개를 기록했습니다. 줄어든 사고 과정의 대가로 더 파편화된 도구 사용, 더 많은 총 입력 컨텍스트, 그리고 더 약한 검증이 나타났습니다.

종합 벤치마크 승자: Unsloth. 코딩 에이전트에게는 단순한 속도나 낮은 추론 토큰 사용량보다, 작동하는 결과물과 정직한 검증이 더 중요합니다. ThinkingCap은 빠른 초안 생성기(fast draft generator)로서는 유망해 보이지만, 자율 코딩을 위해 Hermes의 데일리 브레인 (daily brain)을 대체하기 전에는 더 강력한 테스트/수정 루프가 필요합니다.

submitted by /u/Sn0opY_GER [link] [comments]