Claude on a Commodore 64
A TLS 1.3 client for the Commodore 64, written in 6502 assembly. It
connects to api.anthropic.com itself and does the
cryptography on the 6510: X25519, ECDSA over NIST P-256 against a pinned
issuer, ChaCha20-Poly1305 and SHA-256. No proxy, no helper, nothing on the
other end of a cable doing the hard part. It has held real conversations.
It has never run on real hardware.
claude64 is not affiliated with, authorised by or endorsed by Anthropic. Claude is their product; this is a program that talks to it.
Why this is possible
A Commodore 64 does not talk to a modern API by being a Commodore 64. Two things have to be true. The machine has to reach the internet, which the C64 Ultimate does: it is the whole computer on an FPGA, with networking built in beside the 6502 and a block of registers the processor drives it through. And the server has to accept a handshake a 6502 can actually compute. This one does.
Probed against the live endpoint with openssl s_client. The
handshake completes, Verify return code: 0 (ok).
| Key exchange | X25519 |
| Cipher suite | TLS_CHACHA20_POLY1305_SHA256 |
| Transcript hash, HKDF | SHA-256 |
| Server signature | ecdsa_secp256r1_sha256 |
Not one of those needs a multiply the 6502 does not have, given enough seconds and arithmetic written for an eight-bit machine. Three of the four already existed, tested, in c64ssh, an SSH-2 client for the same machine, and are reused here unchanged. The fourth, verifying the server's certificate with ECDSA over P-256, is the new arithmetic and the bulk of the work.
What it costs
Measured under x64sc, the cycle-exact VICE, by reading the cycle counter.
| p256_mul | 98,194 cycles |
| fe_mul, X25519's, for comparison | 79,522 cycles |
| ECDSA verification | 425,691,052 cycles |
| X25519 | 248,269,240 cycles |
| A whole TLS 1.3 handshake | 1,486,952,800 cycles |
That handshake is 23 seconds on a C64 Ultimate at 64 MHz and about 25 minutes on a stock 1 MHz machine. It is measured start to finish rather than added up from the parts, which is the difference between a figure and an estimate: the estimate beforehand was 1.1 billion cycles, 24 percent low, because there are two X25519s and not one, our own public key and then the shared secret, and because SHA-256 and ChaCha20-Poly1305 over a 2.6 KB flight are not noise at this scale.
After that the session is cheap. ChaCha20-Poly1305 runs at about 8.8 KB/s, so a kilobyte of answer costs a tenth of a second and the machine spends its time waiting for the network.
The Ultimate's turbo is not a convenience here, it is the reason any of this works. The work after the server's flight arrives is 990 million cycles, almost all of it two P-256 verifications, and a server waits about a minute for it. That is 15 seconds on an Ultimate and sixteen minutes at 1 MHz, which also settles the question of putting an ethernet cartridge in a breadbin. No server waits that long.
Who signs for the server
A Commodore 64 has no room for a root store and no business carrying a
hundred certificate authorities. The chain api.anthropic.com
actually sends is leaf, GTS WE1, GTS Root R4, so the client pins one
issuer: WE1's public key, P-256, valid to February 2029. Two
verifications, the leaf under WE1 and then CertificateVerify under the
leaf, and no root store at all.
That is narrower than the usual model, where any of a hundred-odd authorities will do. The cost of it is that the pin has to be replaceable the day Anthropic changes CA, so it is not in the binary: it is 128 hex digits in a file on the disk, written in hex rather than raw bytes because somebody may have to read it and replace it by hand.
Three things that are not in the binary
A handshake means nothing without them, and not one of the three can be compiled in.
| The API key | a credential, and one per person |
| The pinned issuer | it changes when Anthropic changes CA |
| Today's date | the machine has no clock, and notBefore and notAfter say nothing without one |
So the first screen is a menu, and ask claude refuses while
any of the three is missing. The key is typed, or read from a file on the
disk and written back to one. A key read off the disk was never typed,
and the one unpredictable thing on this machine is when a person presses
a key, so the client asks for a line of anything before it will use it:
the entropy is in the timing of the keystrokes, never in what they spell.
Run it
The program itself. It loads at $0801 and runs, and it wants
a Commodore 64 with the Ultimate's command interface behind it: a C64
Ultimate, or an Ultimate-II+ in an original machine. Turn the turbo on.
At 1 MHz the certificate check alone is sixteen minutes and no server
waits that long.
claude.prg ↓ 32,112 bytes
| SHA-256 | 1f21a3c2769b3807d4552f3d2ca1db20c6a25f5979c4a37e81307431d56bc431 |
| You also need | an Anthropic API key, the pinned issuer, and today's date, none of which are in the file. The disk below carries the first two, and can carry the program as well if you would rather have one file than two |
| Licence | free for noncommercial use under the PolyForm Noncommercial License 1.0.0. Commercial use needs a separate one, which is a mail to the address below |
Use a key made for this. Give it a spend limit and revoke it when you are done. That is ordinary advice for any third-party client, and it is worth taking here: this program has never run on real hardware, the module that drives the network has only ever talked to a model of it, and you would be the first person to find out what that is worth. I would like to know either way: coldice.sh@june17.app.
Make the disk
The program reads your key off a disk, and typing a hundred and eight
characters on a Commodore 64 keyboard is a poor way to get it there. So:
a 1541 disk image, built here, in this page. It can carry the program
too, and then the one file is everything you need. Attach it as drive 8,
LOAD"CLAUDE",8,1, RUN.
Built in your browser: the key goes into the image and nowhere else. If you would rather check that than take it, the page is static and self-contained, so save it, turn the network off, and build the disk from your own copy.
The disk holds the key in the clear, in CLAUDEKEY, because
that is what the program reads. Treat the .d64 as the credential.
CLAUDEPIN beside it is the issuer, a public key with nothing
to protect, and CLAUDE is the program.
How it is verified
- Over 1,200 checks run under VICE, every algorithm against published vectors: X25519 against RFC 7748, ChaCha20 and Poly1305 against RFC 8439, SHA-256 against the FIPS vectors, and the whole TLS 1.3 key schedule against RFC 8448, every derivation and every HkdfLabel byte it publishes.
- The 6502 only ever computes and leaves its answer at a fixed address. The comparison happens in Python, because cryptography cannot be eyeballed: a carry bug yields output that looks plausible and is wrong. Test vectors are generated, never hand-typed.
- A reference client in Python, built on the same primitives, completes a real handshake with the live API and records it. The 6502 is replayed against that recording and produces byte for byte the bytes the real client sent, ending on the same traffic keys. A Finished is an HMAC over the whole transcript under a key derived through the whole schedule, so reproducing one means every byte and every derivation along the way agreed.
-
One real 2,613-byte record from
api.anthropic.comis decrypted on the 6502 back into the server's handshake flight. - The certificate walk is checked against the three certificates the API actually sends, field by field, against an independent walk of the same DER, with four kinds of damaged certificate refused rather than answered wrongly. The hostname is matched against the subjectAltName and never the common name, which RFC 6125 forbids, and the validity window is compared as fourteen ASCII digits so there is no date arithmetic to get wrong.
- Replies are fed in one byte at a time, because an answer arrives in TLS records whose boundaries have nothing to do with HTTP's: a real 401 from the live API, a streamed answer cut into 37-byte chunks that split events across them, and every escape the API can send.
Where it all fits
The API does not negotiate a record size limit. Asked for 1024 it does not answer, so the client has to be able to hold a record of the full 16 KB the protocol allows, which with the expansion the standard permits is a 16.5 KB buffer. In a machine with 64 KB and ROMs in the way, that means the ROMs come out, and the client runs in two configurations and switches between them.
$01 = $35 | RAM under BASIC and the KERNAL, I/O still at $D000, interrupts off. The handshake, the records, the certificates |
$01 = $37 | the ordinary machine, interrupts on. Only while the user is typing or the disk is turning, because both of those belong to the KERNAL and neither is in a hurry |
$35 and not $34, which is one bit and the
difference between talking and not: with LORAM and HIRAM both clear, the
whole of $D000 to $DFFF is RAM. No VIC, no CIAs,
and nothing at $DF1C, where the Ultimate's networking
answers.
$0801-$85FF | code and tables, about 31 KB |
$8600-$C704 | the TLS record buffer |
$C800-$CCFF | the scrollback ring, 32 lines of 40 |
$E000-$EFFF | the handshake flight, while it is being assembled |
What is real, and what is standing in
The screens on this page are a real client doing real work, and the answers in them came from Anthropic. Two things in the path are not the Commodore's, and both are the emulator's doing rather than the client's.
The far end is a relay. VICE runs this code about four times slower than an Ultimate would: the work after the server's flight arrives takes 63 seconds there against 15 on the hardware, and the real server stops waiting at about sixty. Three runs closed at 65, 67 and 71 seconds, which is the client finishing its certificate check into a socket that has already gone. So the server answering these handshakes is a TLS 1.3 server on the same desk, which forwards to the real API. What is the C64's: its X25519, its certificate walk against a pinned issuer, its ECDSA, its Finished, its ChaCha20-Poly1305, its HTTP, and the answer. What is not: the certificate it checks is minted here, and the leg from this desk to Anthropic is OpenSSL's.
The networking is a model. The module that drives the Ultimate's command interface can only really execute on the Ultimate. VICE does not emulate it and there is no ROM to load, because the behaviour is FPGA logic and firmware, so the registers are modelled on the host side of the harness with an ordinary socket behind them. A watchpoint fires on an address and cannot tell you what the address is wired to, so that can show the client and the documentation agree and it cannot show the client is talking to anything.
What has never run
Every number and every screen on this page comes from an emulated Commodore 64 with a model of the Ultimate behind it. The hardware arrives in February, and the first run on it is the only test that counts.
If anyone can get a C64 Ultimate into my hands before then, this stops being a model and starts being a machine.
Where this came from
c64ssh came first: an SSH-2 client for the same machine, written to play coldice.sh, which is a cyberpunk text game you connect to over SSH. Eight of its modules are in this client unchanged and still passing their own tests, from the 8 by 8 multiply up through the field arithmetic, X25519, SHA-256, ChaCha20, Poly1305 and base64. TLS and SSH disagree about almost everything above that line and agree about nearly all of the arithmetic below it.
Licence, and the name
Copyright 2026 Laszlo Kondor. Free for noncommercial use under the PolyForm Noncommercial License 1.0.0: personal use, research, teaching, hobby projects, and use by charities and other noncommercial organisations are all covered, and none of them needs to ask. Commercial use is not covered and needs a separate licence, which is a mail to the address below saying what you want to build and who for.
claude64 is not affiliated with, authorised by or endorsed by Anthropic. "Claude" is their name for their product. This is a program that talks to it over the public API, written from the published protocol standards and from what the endpoint itself answers.
The game the sibling client was written to reach.