1st September 2026

Today is Claude Fable (and Mythos) 5.1 day. Anthropic say that Fable 5.1 “sets a new standard for coding, knowledge work, and long-running problem-solving tasks”. Their announcement spends a notable amount of time on scientific research, boasting of a 52.6% score on the brand new Terminal-Bench-Science 0.1 benchmark (first announced on August 27th), up from 24.7% for Fable 5, 29.0% for Opus 5 and 22.4% for GPT-5.6 Sol. Other benchmarks show slightly improved scores, but none as impressive as the Science one.

But how well can it pelican?

Back in July I wrote about how I was losing faith in the pelican benchmark—its connection to how good the models were at other tasks didn’t seem to hold as strongly as it did back in 2025. The most interesting insights I get from it now are comparisons within model families, and particularly comparisons for the same prompt at different reasoning effort levels.

Fable 5.1 has five reasoning levels: low, medium, high, xhigh, max—and no option to turn off reasoning entirely.

I fixed an issue in llm-anthropic which caused reasoning traces not to be correctly recorded, then ran some prompts.

Here’s the full set of pelicans for all of the reasoning levels, each with the full reasoning transcript. I’ll replicate them here:

Low and medium, both without reasoning? #

Next, a bit of a mystery. This is what I got for effort low:

The transcript doesn’t show any summarized reasoning tokens, and the output token count is 1,998. With Claude that output token count includes reasoning tokens. It took 23.8 seconds and cost 10.017 cents.

I bumped that up to medium and got this:

Weirdly, that one also shows no reasoning text and used 1,977 output tokens—21 tokens less than low. It took 23 seconds and cost 9.912 cents.

So for this particular prompt (“Generate an SVG of a pelican riding a bicycle”) Fable 5.1 appeared to skip reasoning entirely at both low and medium settings.

High #

Here’s high—29.6 seconds, 2,612 output tokens, 13.087 cents:

This one did do a bit of reasoning, summary here:

I’m planning the SVG layout for a pelican riding a bicycle, with a sky and ground background, a bicycle with two spoked wheels, frame, seat and handlebars, and a white-bodied pelican with a long neck and orange beak positioned on top.

Really not much difference from low and medium, though.

At xhigh things got radically different. 36,767 output tokens, 7 minutes 51 seconds, $1.83!

The reasoning trace is pretty lengthy, and includes details like this:

Adding the eye, wings stretching down to the handlebar grip, orange legs reaching to the pedals, and a small tail feather, while keeping the pelican intentionally oversized compared to the bike for comic effect. [...]

I’ll accept the slight thickness as charming rather than overengineering it.

Max #

Setting effort to max gave me the best pelican I’ve seen from any of Anthropic’s models. 65,927 output tokens, 13 minutes and 54 seconds, $3.30:

There’s a lot to like about this. The background is tasteful, the legs are clearly on either side of the frame, the feet are on the pedals, the wing is on the handlebars, the pelican has a cute blue hat and there’s a basket with a fish.

It’s still not showing nearly the same level of flair as Gemini 3.7 Flash, but I didn’t ask for flair—I asked for an SVG, and that’s what I got.

Some highlights from that reasoning trace:

Adding pedal shapes near both feet, with the far foot on the second leg partially visible behind the frame. I’m considering whether to add a small scarf or cap for extra character, but leaning toward keeping it simple to avoid clutter.

Now I’m debating a bicycle helmet on the head versus the pelican’s signature crest—the beak and pouch already read clearly as “pelican,” so a helmet could reinforce the bicycle theme without losing identity, though it might compete with the crest for visual space.

I realize the beak at (484,84) would overlap with the dome helmet, so I need to shrink the helmet so it only covers the top of the head, adjusting its arc endpoints to sit higher and narrower so the beak can attach cleanly at the front without collision. [...]

I’m adding a darker tip region to represent the primary feathers, then reconsidering the trailing edge to include scalloped feather curves instead of one smooth line for a more natural look. [...]

Now I’m checking the vent line placements on the helmet, making sure they sit far enough inside the helmet’s edge given the stroke width and rounded caps, and confirming each vent stays within the helmet’s circular boundary. [...]

I decide skipping a handlebar bell and tire highlights since they’re unnecessary additions. Now I’m reconsidering the front fork’s curve — the current control point pulls the shape backward when it should bow forward for a proper rake, so I need to shift the control point rightward to fix the fork’s lean.

OK, let’s animate it #

On Hacker News, swalsh commented on that Max pelican:

Now that it’s a solved benchmark, can we get the animated version?

I didn’t want to spend another $3 so I took the Max pelican and piped it into the default thinking level of High:

llm logs -cx | llm -m claude-fable-5.1 -s 'animate this'

6,121 input, 26,201 output = $1.37. The result looked like this, exported here as video since some people have trouble viewing animated SVGs:

The wheels in the video are rotating in the wrong direction, but I think that’s an artifact of the conversion to MP4—they seem to be going in the correct direction in the original SVG.

Today we’re releasing tailcat, a remix of pieces of Tailscale that gives you a way to use the open-source Tailscale data plane (WireGuard® + NAT traversal + DERP) without the Tailscale control plane, written by the people who made Tailscale. It’s Tailscale without Tailscale, by Tailscale.

Specifically, tailcat is both an open-source Go package and a CLI tool using that package. It lets you run a server-side listener and a client to connect to that server, moving bidirectional bytes back and forth.

That is, it’s like netcat but flowing over Tailscale’s magicsock (WireGuard encryption + NAT traversal + DERP rendezvous/fallback relay).

Notably, tailcat has:

• no IP addresses
• no accounts (no logins, no passwords, no SSO)
• no control plane
• no users
• no admins
• no administrative controls
• no root or admin OS access requirement
• no relationship with or dependence on Tailscale as a company (if you run your own cmd/derper DERP server, at least)

What does “Tailscale” even mean?

When you watch people describe Tailscale to each other online, you see very different interpretations of what “Tailscale” means to them.

One group of people, often seen saying things like “I’ll just run WireGuard myself,” focuses on the WireGuard part and doesn't consider (or care about) parts like NAT traversal, DERP fallbacks, centrally managed firewall (ACL) rules, SSO login, tagging, MDM policies, audit logging, etc. Maybe they only want or need the WireGuard part on a public IP. That’s fine.

Another group of people talks more about the company, corporate structure, long-term viability, founders, funding stage, pricing, certifications, reliability, responsible handling of security disclosures, etc.

Another group of people talk about whether Tailscale is open source or not. As a reminder: our core is open source (with a real OSI-approved license!), our DERP server is open source, and our clients are open source on platforms that are themselves open source: Linux and Android. Our server-side control plane is not. A lot of people in this audience appreciate that Headscale (which we love and partially fund development of) exists, either to use today, or use in the future, as a fallback plan.

All of those interpretations are fine. Whether you’re using our official GUI client wrappers around our official control plane, with a corporate SSO identity provider, or you’re at the other extreme, using only tsnet on Linux nodes against your self-hosted Headscale server, there are many ways to wire up and use Tailscale and its many pieces:

• Its WireGuard + NAT traversal + DERP fallback data plane
• Its control plane
• Its company (paying us to run and support things for you)
• Its open source code

tailcat gives you another way to use a subset of Tailscale.

How it works

Let’s say you want to run a tailcat server. Here’s what it does:

• generates a keypair (either ephemeral or named & reused)
• picks a DERP server (either one you specify, or an auto-selected bandwidth-limited Tailscale-run one)
• generates a tailcat address, which is a string of the form: tc + base64(CBOR( public key + DERP bootstrap info ))
• you then share that address string with somebody out of band, either directly, or by putting it in a DNS TXT record, and sharing that DNS hostname out of band

The client side is about the same:

• pick a key (ephemeral or locally named & reused)
• connect to the rendezvous DERP server specified in the tailcat address
• send a MEOW message to the server’s public key over DERP to add yourself to the netmap

At that point, if the server is cool with that client’s public key (it can be optionally locked down), then it replies with a happy MEOW reply.

The client then proceeds to make a TCP connection to the other side using an embedded userspace TCP stack atop WireGuard. There are actual IP addresses on the wire (IPv6 ones derived from your public key), but they’re never visible to users. Your operating system is never involved at the TCP layer and never sees the synthetic tailcat IPs. All your operating system does is send the DERP TCP messages and/or NAT-punched UDP WireGuard messages.

Because it goes over Tailscale’s magicsock data plane, NAT traversal automatically kicks in and tries to get a direct connection, so data transfer (WireGuard UDP packets) ends up going directly between the client and server, without a DERP relay involved. But if both sides are behind a hard NAT without any port mapping services available, the data packets are relayed over DERP as a fallback. If you use Tailscale-hosted DERP servers, those are rate-limited (bandwidth costs us money). But if you run your own DERP server, you can control any rate limiting.

In the default mode where you don’t specify a port number on the tailcat server, the default is to just pipe the received data to the server’s stdout, like netcat. But it can also run in a client mode, where it runs a SOCKS server on an ephemeral local port and then runs a provided child process (e.g. curl or whatever) with an environment variable set to use said SOCKS server, letting tailcat-oblivious programs use tailcat transparently. (tailcat is currently always userspace-only, never reconfiguring your system’s networking stack … no TUN devices, no routing table changes, etc.)

Why?

I wrote tailcat in September 2023 on a long ten-hour flight while catching up on bad movies. At the time, tailcat was mostly a fun novelty. I presented it internally, and I’d use it occasionally myself, but I mostly forgot about it. But then a number of customers approached us with use cases where it was a perfect fit, so we gave them copies of it, with arrangements where we’d host the DERP fallback relays for them in cases where tailcat’s use of Tailscale’s magicsock fails to get a direct connection.

Fast-forward to a few months ago, when all this AI agentic coding stuff was in full swing. It’s been really powerful to just give my sandboxed AI agents access to make their own also-untrusted nested VMs and give them tailcat. With access to exotic hardware in faraway places, I let the AI go wild wiring things up to each other and running experiments. Off the top of my head, I can recall:

• giving an agent access to a fleet of every Raspberry Pi generation
• giving an agent access to a sandboxed EC2 instance that had ambient access to control a nearby EC2 instance and kexec reboot it repeatedly, while porting Tailscale to run in EC2’s UEFI environment, including porting the Amazon Nitro ENA network driver to pure Go (under Tamago)
• giving an agent access to a Windows host to repeatedly create and destroy Hyper-V VMs to debug and fix a stack corruption bug in the Go runtime and standard library

In most of these cases, I probably technically could’ve just used Tailscale proper, but it would’ve been more tedious to the point that I probably wouldn’t have even done it, and would’ve just set up a few port forwards instead, or opened up some ports on a firewall somewhere. I find that tailcat is often the perfect tool when I already have two shells open on two machines in two very different worlds and I just want to connect the two together, for a quick file copy, or port forward, or letting one SSH to the other. Especially when one side is untrusted or ephemeral or I’m afraid to touch its system configuration.

When we launched Taildrop in 2021, one of the first requests was for netcat-like sharing between nodes. tailcat now provides that, and more. We’d still like to do something tailcat-like in the main Tailscale client too, but we’ll have to figure out how that fits into the rest of the Tailscale product.

Another reason to open source tailcat is that it’s kinda obvious and inevitable. We’d selfishly rather people be using, improving, and filing bugs against our data plane, which then makes the rest of the Tailscale product better.

I would be remiss if I didn’t mention that you should contact us if you have fun use cases where tailcat might help you, and where we can help you integrate tailcat or run a global fleet of DERP relays for you. (e.g. IoT, P2P games, distributed GPUs, etc.)

The DERP server fleet we’re running for tailcat is throttled and only available in a handful of regions around the world. The idea is that, most of the time, our magicsock NAT traversal will do its thing and DERP isn’t relevant, with tailcat getting a direct UDP WireGuard connection between the two peers. But in cases where that fails, we’d be happy to exchange money for goods and services.

Or, hey, run your own DERP fleet or single server. It’s open source too.

Enjoy!

We look forward to seeing what you build and how you use this. Give tailcat a spin here.

Over the past couple weeks I’ve been doing agent-driven reverse engineering of peripherals that happen to be within arm’s reach. From those devices, I’ve come away with a full plaintext command shell inside my microphone, a webcam whose activity LED I can switch off while it records, and a key light that hands out memory writes to anyone on the WiFi. Peripherals have proven to be an ideal target for agentic RE - they’re tiny computers attached to my computer, with a data connection to the host and usually a firmware update mechanism, so an agent has something to iterate against. The net outcome is better control and understanding of my machine.

My process was pretty much the same for each of these devices: grab a copy of the device’s firmware and associated update tool from the manufacturer, throw it into my reverse engineering environment, tell Claude Opus 5 what my goals are, and let it churn. Depending on the device, the goals were somewhat different, but they usually looked something like:

In this directory is the firmware and update utility for ___. The device is also attached to this computer, and you may interact with it in non-mutating ways. Exhaustively document and cross-validate the entire firmware, including the following goals:

* reverse engineer the firmware update format and update protocol
* implement our own update utility
* determine the security properties of the update protocol, including checksums, signature validation, secure boot
* use static and dynamic analysis to determine all protocol surfaces and completely enumerate functionality
* find any hidden or debug functionality in the product and how to access it

Depending on the results, there were different directions of follow-up, but you should get the general idea. Let’s run through the list - each device links to a GitHub repo full of generated-slop docs and scripts, most of which have been validated live against real hardware. I’ve also included the effort each device took, pulled out of the Claude Code session transcripts. “Churn” is the time Claude was actually working, with the long idle gaps removed. “Prompts from me” is every message I typed, including the one-word ones telling it to keep going. All five devices together came out to about 13 hours of churn and 98 prompts, spread across two weeks of evenings.

Everything I own

Insta360 Link webcam

GitHub repo - 3.7 hours of Claude churn, 33 prompts from me

I use an Insta360 Link webcam, which is a nice gimbaled pan-tilt-zoom camera that does face tracking for automatically framing the shot. I wanted to know if it was possible to subvert the activity LED, like in the classic iSeeYou exploit.

Interestingly, it was immediately obvious that this camera has a lot going on inside it. It turns out that it runs a whole RTOS (ThreadX) sourced from the upstream SoC vendor, Ambarella. The RTOS hosts several small vision models that provide things like the aforementioned face tracking, as well as gesture detection for controlling settings. Pretty amazing complexity inside a tiny webcam, but it also means there’s some exciting attack surface here.

Over the USB Video Class interface, there’s an XU (Extension Unit) command that kicks the device into “mass storage” mode. This then lets us transfer a staged firmware update to the device’s internal FAT filesystem, which the device then applies to itself on reboot. This route does require user intervention to reboot with a replug, but there’s actually another command channel that exposes arbitrary read/write of files and a reboot command over the USB vendor class. With this, we can fully flash the device without any user interaction. Once the firmware is in the right place, there’s effectively no anti-tamper, just an appended MD5 hash to ensure integrity.

The indicator LED turns out to have a well-structured set of “patterns” in the firmware that dictate color, blink pattern, etc. that are indexed into for various device states. I had Claude write a tool to patch out the table entry for camera activity, fix up the integrity hash, and flash it to the camera. A quick test showed that the green LED that normally illuminates while recording no longer turned on. Horrifying! On this device, the gimbal itself also deflects down when not recording, so it’s not completely stealth, but it still doesn’t feel great.

The LED behavior before and after patching.

ASUS ROG Swift PG42UQ monitor

GitHub repo - 1.2 hours of Claude churn, 13 prompts from me

My ASUS ROG Swift PG42UQ monitor was actually where I started, because I got annoyed at the pop-up overlay that comes up every once in a while that tells me to run “pixel cleaning”. I have never intentionally run pixel cleaning on this monitor and I never will, I don’t care, and I would like for that overlay to go away forever. Maybe there’s a debug menu or something that can turn it off, or worst case we patch a branch in the firmware?

Claude found that the firmware has effectively no protection whatsoever - there’s a two-slot A/B scheme and a simple checksum, but ultimately we can write whatever we want to the thing. Firmware updates run over an I2C bus bridged over USB.

The pixel cleaning warning turns out to have no native way to disable it, and it’ll always show up after 8 hours of runtime. Oh well. Claude did find the appropriate area to patch to kill the functionality though. I haven’t actually been brave enough to write a modified firmware to the thing yet - it’s a pretty expensive monitor - but I’ll get there at some point.

Another neat thing was exploring the DDC/CI interface. This is the control channel available over the display cable itself, allowing the host to change inputs and other settings. I believe ASUS offers this through their Windows utility, DisplayWidget, but that does little for me on Linux. So, now I have a shell script that can flip through some of the DDC/CI features like the hardware crosshair or zoom overlays, FPS counter, and countdown timer. I might set up some of these on hotkeys in the future for easy access.

Shure MV7 microphone

GitHub repo - 4.2 hours of Claude churn, 32 prompts from me

At this point, there’s less actual incentive to keep popping these devices and more just morbid curiosity. My microphone, the Shure MV7, connects over USB and obviously has some amount of smarts to it, with on-device digital volume controls and such.

The firmware for this one turned out to be hidden inside the Windows software, MOTIV Mix, so Claude installed that in Wine, found the update server, and pulled it down. I wasn’t on the latest, so there was actually a reasonable incentive here to get this working just to update my microphone from Linux. The firmware turned out to contain both DSP and MCU firmware, and was honestly pretty boring as you might expect. Again, no real security on the firmware flash itself.

However, the update protocol revealed that the entire thing actually runs over a USB HID vendor class protocol that implements a full plaintext command shell, with 48 different commands. Since it’s HID, we can actually hit this over WebHID from a webpage in Chrome, so I had Claude build a web interface for using the shell. There’s all sorts of interesting settings in here including a dozen DSP knobs, arbitrary memory read/write, LED control, and a 4-tier user privilege system whose entire authentication is a string comparison against the name of the tier you asked for. su sup just works, and the top tier can disable the touch panel so you can’t mute at the device, and drive the mute LED independently of whether the microphone is actually muted. It’s the webcam LED trick again, on a microphone. Obviously, be aware that you could probably break your device if you use that UI and do something stupid with it.

The WebHID shell interface. The DSP knobs on the left are the device’s own settings; the console on the right is the plaintext command shell talking over HID.

Elgato Cam Link 4K video capture

GitHub repo - 1.5 hours of Claude churn, 10 prompts from me

The Elgato Cam Link 4K is just an HDMI video capture device, and honestly was just more of the same. The interesting thing for this one was that I let it go fully unattended - I literally kicked off the process before going to sleep and woke up to a teardown and functioning firmware updater. The firmware contains an MCU image and an FPGA bitstream for the actual HDMI handling, so you could potentially do something fun with the FPGA if you went deep enough into the reverse engineering there. There’s no protection on the firmware update path.

I was able to pull out all the EDID information used for negotiating video parameters, so we know exactly what resolutions, refresh rates, color spaces, and chroma subsampling options are offered to devices.

The vendor HID protocol does include tunneled access to the internal I2C bus, which is kinda neat as you can poke the internal HDMI receiver registers.

Elgato Key Light Mini

GitHub repo - 2.4 hours of Claude churn, 10 prompts from me

Finally, I poked at something that wasn’t connected over USB but WiFi instead, the Elgato Key Light Mini. This one turned out to be way more interesting than I expected: it’s the only one with meaningful firmware integrity protection. Elgato signs the firmware updates with Ed25519 over a SHA-512 hash of the firmware payload, and rejects firmware that doesn’t validate. This makes sense to do, as the device basically connects to a WiFi network and then provides unauthenticated access to anyone on the same network, so the threat model is inherently different.

Unfortunately, while that’s an improvement over all of the other devices we’ve looked at, it protects the firmware at exactly one point in time: when an update is happening. It’s not a boot time check enforced by the bootloader or any other kind of secure boot scheme, and the updater happens to be running while everything else in the device is still operating, meaning there’s huge attack surface to try to disable that signature validation. I asked Claude to look for an exploit that might enable this, and it found a doozy: an HTTP POST request that drops a payload straight into the internal UART, which includes a memory poke command. This means that a single HTTP POST of ATSE=0200ED94,0E001009 turns the signature check into a no-op, and we can freely update to a firmware image without a legitimate signature. I successfully tested this with a simple patch that changed the name of the device, so uh, yeah, don’t put these on an untrusted network.

…, owned

I have a lot of feelings about this whole thing. As I wrote back in March, this is incredible for interoperability and fixing things that don’t work how we want them to. Hardware is almost universally “open” for tinkering at this point with just a couple hours of mostly hands-off machine-driven labor each, and I look forward to a near future where I can add features to my webcam firmware as easily as I can to software that runs on my Linux machine itself.

On the other hand, as a security professional, this scares me for several reasons. I would work from the operating assumption that any device attached to a computer could have had a malicious firmware implant performed, where previously that required significant per-model investment and was stereotyped as a “state actor” kind of activity. Operating systems aren’t really equipped to work with the user to ensure that a microphone stays a microphone, and doesn’t spontaneously turn into a keyboard that hits Win+R and drops a payload to steal all your data when the room is quiet enough that it can assume you aren’t watching. And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.

Network-connected devices seem near universally fucked at this point? There are a few others I’ve poked at that I haven’t documented here, but I’ve gotten a root shell on a commercial Dell display, and RCE on an Eaton UPS. Obviously it was never best practice to let untrusted clients touch these things, but the speed and scale at which this can be executed makes the risk so much higher now.

Finally, I can’t help but think about what an AI-equipped automatically-reverse-engineering worm could do today. It’s only a tiny leap to imagine that someone could make a self-replicating piece of malware that probes its environment, relaying reconnaissance back to a smart command-and-control that actively works to push itself into accessories and IoT devices and industrial equipment found adjacent to an infected target. Two things have kept this from happening: every device model needs its own reverse engineering, and validating any of it needs the hardware in hand. The first is the labor I just handed to an agent. The second is free to malware already sitting on an infected host. Honestly, I wouldn’t be surprised if this already exists, and I think the next few years are going to be extremely interesting. 🫠