모델 코딩 벤치마크 (Model Coding Benchmark) 🚀
에이전트 (Agents): Cursor, 모델 (Models):

• Kimi K2.7 code
• Sonnet 5 Max
• Fable 5 Max
• GPT 5.5 Very High
• GLM 5.2 Max
• Composer 2.5 Fast

태스크 (Task): HTML 이중 진자 시뮬레이터 (HTML Double Pendulum Simulator)

🎉우승자: Fable 5 Max🎉

최종 점수 및 요약

• Fable 5 Max — 94/100
• Sonnet 5 Max — 92/100
• GLM 5.2 Max — 88/100
• Composer 2.5 Fast — 실패 (Fail)
• Kimi K2.7 code — 82/100
• GPT 5.5 Very High — 81/100

Fable 5 Max의 약점

• 전반적인 우승자이지만 코드 밀도가 높음; 유지보수를 위해 약간의 규율이 필요함.
• Chaos 구조가 별도의 ChaosSwarm 클래스 대신 App 내에 더 통합되어 진행됨; 아키텍처가 "매우 깔끔"하지만 Sonnet만큼 클래스 분리가 되어 있지는 않음.
• 매우 발전된 트레일/렌더링 (trail/render) 시스템이 최대 설정에서 CPU에 부담을 줄 수 있음; 이에 대해 세그먼트 예산 (segment budget)을 설정한 것은 큰 장점임.
• 보존 임계값 (Conservation threshold)이 매우 엄격함; 극단적으로 높은 에너지 프리셋에서 "경고"를 생성할 가능성이 높지만, 이는 사실 정직한 정확도 접근 방식임.

Sonnet 5 Max의 약점

• 가장 포괄적인 아키텍처 중 하나이지만, 목표가 3000~4000행일 때 ~훨씬 더 큰 애플리케이션을 생성함; "벤치마크 프롬프트 (benchmark prompt)에 대한 규율 있는 준수" 측면에서 Fable보다 뒤처짐.
• 보존 패스 임계값 (Conservation pass threshold)이 Fable에 비해 더 느슨함; Sonnet의 CONSERVATION_PASS_PERCENT는 1.0 수준이지만, Fable에는 훨씬 더 엄격한 임계값이 있음.
• 드래그 (Drag) 이후의 물리적 "플링 (fling)" 예측이 없음; 드래그는 안전하지만 Fable/GLM만큼 생동감 있게 느껴지지 않을 수 있음.
• 매우 광범위한 UI/진단 (diagnostics) 구조는 좋지만, 일부 사용자에게는 패널이 너무 밀집되어 보일 수 있음.

GLM 5.2 Max 약점

• 매우 강력한 시각적 및 교육적 설명 능력을 갖추고 있으나, RK4 wrapper 측면에서 stepState가 매 단계마다 toArr()를 통해 배열을 생성하고 다시 쓰는 방식을 취함; 12–24 chaos pendulum + extreme timestep 조건 하에서 불필요한 할당 (allocation) 위험이 있음.
• Trail setCapacity가 이전 지점들을 보존하지 않고 새로운 버퍼 (buffer)로 전환됨; trail length를 변경할 때 시각적 연속성이 손실될 수 있음.
• 코드가 3000행 제한에 매우 근접해 있으나 약간 미달함; 프롬프트의 "실질적인 3000–4000행" 기대치를 Fable/Sonnet만큼 충족하지 못함.
• 물리 및 UI는 훌륭하지만, 성능 아키텍처 (performance architecture)가 Fable/Sonnet만큼 정교하지 않음.

Composer 2.5 Fast 약점

• 훌륭한 아키텍처 아이디어들이 있음: PhysicsSelfTest, ConservationRunner, state/hash/export, graphs, presets. 그러나 전체 구현량이 프롬프트가 목표로 하는 3000–4000행 수준보다 눈에 띄게 낮음.
• Self-test 기능은 있으나 에너지 테스트의 허용 오차 (tolerance)가 상당히 느슨함; 예를 들어, 10초간의 에너지 드리프트 (energy drift) 테스트에서 5% 임계값을 사용함.
• Trail/render 시스템은 기능적이지만 Fable/Sonnet/GLM만큼 시네마틱하지 않음.
• 일부 UI 요소들이 문자열 템플릿 (string template)에 의존함; 프로덕션 UI 느낌은 강하지만 상위 두 모델만큼 정교하지는 않음.

Kimi K2.7 code 약점

• RK4 및 보존 체크 (conservation check) 기능이 있으나, trail buffer가 object-array 기반임; Fable/Sonnet의 typed-array ring buffer 접근 방식만큼 성능 친화적이지 않음.
• Randomize 흐름이 진정한 의미의 편집 가능한 결정론적 시드 (editable deterministic seed)를 통해 진행되지 않음; Math.random()을 사용하여 새로운 시드를 생성하려는 경향이 있음.
• 상태 직렬화/내보내기 (State serialization/export) 기능은 존재하지만, 검증/안전 (validation/safety) 계층이 Sonnet/Fable만큼 견고하지 않음.
• Graph/render 측면에서 array spread/map 사용이 있음; 작은 장면에서는 문제가 없으나 벤치마크 용도로는 더 위험할 수 있음.

GPT 5.5 Very High의 약점

• 물리/RK4 코어는 견고하며, typed-array 트레일 버퍼 (trail buffer)도 포함되어 있음; 하지만 구현된 프롬프트(prompt)가 요구한 3,000~4,000행 규모의 "실질적인 프로덕션 실험실 (substantial production lab)" 목표치에는 훨씬 못 미침.
• 프리셋 (preset) 세트가 누락된 것으로 보임; 프롬프트에서 요구된 "최소 진단 (Minimal diagnostics)" 프리셋이 조건(condition)으로 언급되었으나, 프리셋 목록에는 정확히 일치하는 항목이 없음.
• 상태/내보내기 (State/export) 및 보존 확인 (conservation check) 기능은 있으나, Sonnet/Fable만큼 포괄적인 검증 (validation), 안전 복구 (safety recovery) 및 진단 (diagnostics)의 깊이는 부족함.
• 더 컴팩트하고 깔끔하지만, 이 벤치마크 (benchmark)에서 요구한 것은 "적은 코드로 보여주는 좋은 데모"가 아니라 "완전한 제품 (full product)"이었음.