Claude Opus 5.5 invents a music notation and browser synthesizer to compose adventure-game tracks for Simon Willison's Scrimshaw Jukebox

• Model: Claude Opus 5.5 (claude-opus-5-5 family). It has a 1M-token context window and 128K maximum output. It is available through Anthropic, AWS, Google Cloud and Azure (Let's Data Science).
• Output: the model generates no audio itself. It writes a text score plus a Web Audio synthesizer that renders the score live, with no audio samples (tool).
• Access: the jukebox is public, and you can edit any score in the browser.

• Format design: the score lists settings, voice declarations, pattern blocks and an arrangement, in that order (tool).
• Rhythm: every bar has a fixed number of steps, and each dash extends a note by one step.
• Supported time signatures: 4/4, 6/8, 3/4 and 12/8, plus a swing setting.
• Pattern tools: repeats (B*2) and transpositions (A+5).
• Instruments: more than 40 synthesized voices. Each voice has settings for volume, pan, reverb, envelope, glide and brightness.
• Reproducibility: the original prompt is published, and the format prompt in PR #353 gives any other model the same spec, including counting rules and a worked example. That makes cross-model tests straightforward to run, but nobody has published any.

• "Surprisingly good" output: this is Willison's personal judgment. No listener study or musicological review backs it (post).
• Composition is a new capability: Willison poses this as a question, not a finding (X post). Independent corroboration is not available.
• Opus 5.5 is cheaper and safer: these claims come from Anthropic. Reported price figures conflict:
• One report says it costs 40% less to run than Opus 5, priced at $4/$20 per million input/output tokens (Let's Data Science).
• Thurrott cites both the 40% figure and a 20% cut in token prices.

Writing music as text is an established research direction. ChatMusician (2024) showed that a text-only LLM could compose in ABC notation once trained on a music corpus (repo). Scrimshaw differs in two ways:

• A general-purpose model invented its own notation instead of using a standard one.
• The same model wrote both the score and the player.

Willison compares this to text models recently getting competent at 3D graphics, which suggests a broader pattern of code-mediated creative output. The music-video demos fit the same pattern (Rad Neurons).

• Sample size: one prompt, one model and one evaluator. Willison says only "careful experiments" across models could show whether the ability is new (post).
• Imitation of copyrighted style: the output followed the named soundtrack closely. Willison asks how Claude "knows" what Monkey Island sounds like. His guess is that training data included text renditions of game music from online forums (X post). That is speculation, not documented fact.
• Weak evidence elsewhere: the music-video coverage has no benchmarks and does not discuss limitations (Rad Neurons).

• Prototyping: an AI-designed text format plus a synthesizer can produce editable, version-controllable game audio with no sample licensing. That suits prototypes and jam builds.
• Pattern worth copying: have the model design a small domain-specific format (a DSL), then hand the format's spec to other models. PR #353 is a ready template.
• IP risk: when prompts name an existing franchise, output can lean heavily toward it. Teams shipping commercially should avoid reference-by-name prompts and review melodies before release.
• Evaluation gap: music needs human listening tests. Teams should build their own before relying on vendor or anecdotal claims.