So it got me thinking today after I was pondering more on the flow of handling an incoming notice from a court, What happens when two users are on the same case? Which, honestly, happens all the time: I deliberately copy my secretary on the NEFs in every federal court where I have filing privileges, because she’ll get the case documents and download them to our document management system (thank God because I hate using it). If we were both DocketView customers, my Email Worker would get two identical emails with different users but the same URL for the same document filing in the same case.

Wouldn’t it make more sense to parse the email, check to see if it had been already downloaded or logged into the database, and if it has then just associate the user to the case information (unless that’s already happened, in which case do nothing). This will save on compute time in not having to re-download a PDF, or series of PDFs for motions that have attachments and exhibits and a proof of service. And it saves on storage space since I’m only saving one copy of the PDFs themselves. And I have fewer database writes and reads, since I can simply check on the users-cases table and see which ones go with which user.

And yes, the Worker could just consult the database and see. But again, that’s expensive in terms of using up my database reads for the month and I believe also quite slow and probably stresses the database if there’s a lot of action at that time. It also just sort of offends my sense of efficiency, I’d like to be more elegant and thoughtful generally.

The ready solution seems to be a Durable Object. Instead of writing to the database, I’ll have the Email Worker parse the incoming email and extract that data to a JavaScript class and have the DO take that same class and return the value, checking it against the database to see if it’s already written. Meanwhile the Email Worker is off to handle the next incoming email or has just gone to sleep. If the DO hasn’t seen this document before, it’ll add the information from those classes.

This was actually suggested by Claude earlier when I asked it a random question about Durable Objects a couple of week ago, after seeing some tweets about it. Instead of firing up a new chat, I apparently (and almost certainly accidentally) asked it inside my DocketView Project so it assumed I was thinking of doing something with a DO.

Here’s Claude’s suggestion:

Each active court case could have its own Durable Object instance, identified by a combination of the court and case number. This object would maintain the current state of the case's document list and coordinate all updates to it. 

When your email Worker receives a new NEF, it would:  
- Route the request to the appropriate case's Durable Object 
- The Durable Object would validate that this document hasn't already been processed 
- Coordinate the storage of the PDF and metadata 
- Update the case's document index atomically  

This approach provides several benefits. First, it ensures consistency - you'll never have duplicate document entries or lost updates. Second, it allows for real-time features - if you later want to add functionality like notifying users when new documents arrive, the Durable Object can maintain WebSocket connections to interested clients. Third, it provides a natural way to handle rate limiting and queuing if needed. 

I didn’t do anything with this suggestion back then but I saw it today in my notes and spent an hour or so having Claude figure it out. Had to rewrite the original Email Worker, which made it simpler and shorter, and spin up a new Durable Object. Also had to adjust the database schema because it didn’t quite mesh. An underrated feature of the Claude Projects is uploading the Email Worker code, the database schema, and the Wrangler.toml file. So from my first prompt, Claude had a pretty decent context already. Makes the copy-pasta easier if it already knows your userID, for example.

After quite a bit of testing and tweaking, it’s working now. One step closer to a finished back-end! My next module is the Worker to handle downloading the PDFs, checking the database, and saving to the R2 bucket. Shouldn’t be too hard I’m anticipating, but we shall see. I still need to integrate Stripe and then dust off my prototype of the front end. I just want to make sure it works first, though. Just automatically downloading PDFs would be a huge help.

My application has a module written in TypeScript that parses these incoming email, extracts relevant data like the court, case number, document number, link to download the document if any, filer, etc. and writes that information to a database. The next step is to have a separate module take the document link and go get the PDF, give it a name that associates it with the lawsuit, and stick it in a pool of documents. The web app aka “front end code” will have a nice, efficient web page with a table showing all of those documents in order and a little icon so the user can see the actual filing, or download it for local use.

Sounds simple right? Well, not really.

Writing this code to parse the email is really complicated, mostly because there are a bunch of different variations by how different clerks set up their systems, what kind of things get filed as PDFs and which are text-only entries, how various filings are described, and on and on. But I got that sorted out and it seems to play nice with the examples I throw at it.

I created a Worker on Cloudflare and thought I was all set. Nope. The documentation for the Email Workers assumes you want to just have an email for your website, like dave@fubar-widgets.net and send that to your Gmail account. As a way of putting your best foot forward to customers. I get it. Great.

But I want a lot more functionality. I want to direct those incoming emails to my Worker to parse them out, reject emails that aren’t addressed to a valid user, and reject anything that doesn’t come from uscourts.gov to avoid spam.

Making the Worker wasn’t hard. Having Cloudflare recognize that Worker and see it as a valid target for the incoming email Route, well that’s a different kettle of fish.

I originally tried just copying my code over, since Cloudflare provides a nifty little code editor on the website if you click through some of the settings. But it doesn’t like TypeScript and I didn’t want to just copy it to Claude or Gemini and have them translate it, though after several days of going around and around, that was awfully tempting.

Eventually I figured out that the best way to create and deploy is using the Wrangler command line tool, installed via npm install -g wrangler@latest. Pretty much anything else, including Homebrew, is deprecated or doesn’t include dependencies.

The crucial part is the wrangler.toml file to specify that you want to use it for email. After several different tries, what worked seemed to be this:

It continually gives me this warning, but it works:

I’m sure it’s not the way the Cloudflare dev team wants this to be described, but I simply cannot find anything in the documentation or in the Discord channel for this to give me anything else. And I only got this after a half-dozen error messages when trying to deploy differently and feeding those errors into Claude 3.6 and begging for help. This makes it visible when setting up an email route, which apparently still needs to be done online. I cannot figure out how to do it on the command line with Wrangler, still.

My code sends the parsed information to a database, so I had to write the schema for that and deploy it, then take the database identifier and write it into the wrangler.toml because it will refuse to deploy the Worker without that off-ramp.

Oh and one more thing — the name for the incoming email address that you need to set up the route is “catch-all” because it doesn’t take an asterisk like every other normal boolean computer since Univac. Again undocumented, but solved by Claude.

I threw a bunch of fake emails at it using curl and iterated on the index.ts code for the Worker until it got it right. Ended up with about 200 lines of TypeScript, well within the limits of the system.

Next step is to give this test email to the courts and wait for a few NEFs to pile up and see if it actually works with live filings. I get a couple per day on various cases, so we’ll see.

One thing I’m really curious about is how long this is going to take to parse an email. The paid plan with Cloudflare is $5 per month (yes, five bucks) and comes with 15 minutes of compute time per request, 10 million requests per month, and 30 million milliseconds of compute per month. Which kind of sounds like a lot. Hoping it won’t be more than 10-20 ms to process an incoming email and write it to the database, but we’ll see. If I go over, it’s $0.02 per million CPU milliseconds.

I’m creating a web app for litigators called DocketView and the primary feature right now is taking Notices of Electronic Filing from the federal courts’ Pacer system and turning it into a database of PDFs organized by date and document number, as well as by court and name of the matter.

After an exhaustive review, it seems like the best approach is to do this as a “serverless” app with a bunch of discrete modules so it can “scale to zero” in the industry parlance — not charge me for the computer time when the computer’s not computing. Because there’s very little traffic on the weekends and evenings and no sense paying for a box to run 24/7 when that’s really not needed.

I investigated the pricing and performance of a number of different serverless providers, small scrappy start-ups like Amazon, Microsoft, and Google, as well as a new generation of companies like Vercel and Netlify and Supabase. It can work on all of them and the costs are more or less in line, except I think I may be facing a huge bill for egress if this gets traction and I have a few hundred lawyers and their office staff pulling down PDFs every hour. Which is to say, storage and egress of files.

When I was originally sketching this out a few years ago, the old school idea of some jQuery on the front end with a MySQL database in the back chugging away was appealing. But that’s like $150 per month in fixed costs on a hosted platform like Digital Ocean or Linode (or AWS or Azure) and as the database grows the storage can require a larger disc space. And on top of that the egress charges are frightening: 500 gb per month is included, unless you power down the compute instance in which case that reduces your included bandwidth accordingly, and are $0.01 per gb after that.

Serverless providers, by contrast, don’t seem to charge for the web app itself (not the largest part of the potential costs, to be sure) but they do charge for data leaving a storage bucket. AWS’ S3 is the original version of this, Super Simple Storage, and has different tiers of pricing for “egress” based on how close to the edge you want it. For ice cold, don’t think I’ll need it -type archives, it’s very cheap. But this ain’t that and current pricing on close-to-the-edge is free for the first 100 gb and $0.09 per gb after that up to 10 TB and falling as the data grows larger. Supabase does something similar but the “free” is smaller and the egress is cheaper. There are all various dials to turn to calculate pricing.

Cloudflare, a massive infrastructure provider, got into the serverless field several years ago and has shockingly good pricing: free. As in beer. As in, no egress charges at all. They’ve added compute modules called Workers and a database service they call D1, and their bucket storage to compete with S3 is called R2 — one notch better on everything, I guess. I think they’ve got cabinets in a thousand datacenters all over the world, a truly massive company but sort of sneaky stealthy because they seem not to care all that much about winning hearts and minds of developers.

So I picked them. And I’m now in the process of figuring out the architecture of what-goes-where and how to make it all fit together. Stay tuned!

Let’s set the table. Large Language Models, also known as LLMs, are what most normies think of when they hear “AI.” It’s products like OpenAI’s ChatGPT and Anthropic’s Claude, which fall under the larger heading of generative AI — artificial intelligence that generates an output, whether that’s a picture or an essay or computer code. These models are trained using immense amounts of raw data: Wikipedia, Reddit entries, old posts on Usenet, Project Gutenberg, stuff like that, and that’s just text. Anything on the internet can usually be scraped and shoved into a big pile. Then throw in transcripts of TV shows and podcasts, pictures and videos, every type and manner of content that we’ve ever digitized as a human species.

Then we train. Which means to run some vector algebra over the symbolic representations and do a bunch of matrix multiplications, which is really fascinating but let’s put that aside for now. On the other side, and LLM pops out. As the ever-insightful XKCD comic puts it,

What happens when we run out of data? To a normie, this sounds absurd. The internet is so vast and massive, especially when we think of non-English content, that we simply can’t comprehend ever getting to the edge of it, like reading every book in a library. But computers aren’t like that, they just consume and ingest and devour. Text, too, is really quite small in data terms. I found a digital copy of the Odyssey online in the original Greek and this foundational text of western civilization is a mere 465 kilobytes. Computers are just really good at storing and processing words, especially in English, and especially in languages that use alphabets. Video and audio are a different matter, though, but it’s not entirely clear how helpful that type of data is going to be for generative AI that’s not trying to do visual things like move around in the world or create an image.

Ilya Sustkever, one of the founders of OpenAI and absolutely on the cutting edge of the field, said at a conference a couple of weeks ago that data was the “fossil fuel” of AI. “We have but one internet,” he said, and once we have all that data in our training corpus, that’s it.

The solution is synthetic data, having LLMs create data and then use that data to train a larger and more advanced model. It sounds plausible at first, especially if you think of how the chess and Go systems were trained: instead of just looking at all the records of human games, they played against each other and made perhaps billions of absurd no-human-would-do-it moves in millions of games. The moves that won games were given a positive grade, the ones that didn’t were graded down, and over time the system learned on its own how to win consistently. The systems got so good that very advanced Grand Master-level Go players would improve their own games by seeing some of the outlandish inventions by the AI software. Humans never thought to do that, but the AI did because it trained on virtually all of the possibilities.

Synthetic data also sounds absolutely absurd. You’re going to ask Claude 3.5 to write fifty poems about leaves falling on snow and then throw that into a pile to train Claude 4 to get better at poetry? Are you nuts? It’s especially absurd if you stopped paying attention somewhere around ChatGPT 4 in late 2023 or early 2024, when it would hallucinate on a regular basis and turn out absolute junk that made no sense. Grammatically correct English sentences, to be sure, but flat and dull and unremarkable. Slop, as it’s called perjoratively.

Using slop to train a model will only produce more slop. A future where our synthetic overlords drown us in oceans of bland and tasteless slop, force-feeding use cheap gruel and draining all of the quirky, edgy, interesting, emotional — the real and human — out of the world. Synthetic slop as far as the eye can see, grays and blacks with no color, the fading light of humanity struggling amidst the ever-encroaching darkness.

The argument, as most prominently expressed by Shumailov and Shumaylov et al., gets very mathematical. Published in Science in July 2024, it is worth exploring in detail. I’m told it’s been passed around in policy circles in DC since it was submitted for publication in October 2023, and is highly influential among people making law and working at think tanks on how to legislate and regulate AI. It’s unclear to me whether it played a role in the SB 1047 fight this past summer, however; that seemed to me to be more about liability for model misuse.

Just to define our terms up front, “model collapse is a degenerative process affecting generations of learned generative models, in which the data they generate end up polluting the training set of the next generation. Being trained on polluted data, they then mis-perceive reality.” Sounds pretty stark. They show some statistical methods to develop this theoretical intuition and conclude that “both early model collapse, in which only the low-probability events get cut off, and late stage model collapse, in which the process begins to collapse into a single mode, must arise in the case of discrete distributions with perfect functional approximation.” (emphasis mine)

The authors then run a series of experiments to test out this theoretical understanding, training a model on its own outputs for five generations and then statistically sampling the diversity of the outputs. It shows this convergence and sharply reduced perplexity over time.

But here’s exactly where it falls apart, and it seems to me that their methodology is, to put it candidly, ridiculous — and more than that, filled with the worst sort of excuse-making. I have a bit of sympathy for them since this field is moving at light speed. The last three months of 2024 alone had mind-blowing advances, from the release of OpenAI’s o1 to their preview of o3 in December to DeepSeek’s v3 put up some state-of-art results on evals using only $6 million in compute resources on hardware from two generations ago.

The Shamailov paper was submitted in October 2023 and published in July 2024, so it was already well behind the curve when it finally came out. But even in October 2023, it wasn’t anywhere close to the frontier.

The researchers sniff that “We can easily replicate all experiments covered in this paper with larger language models in non-fine-tuning settings to demonstrate model collapse.” But they don’t. Why not, if you’re making these bold claims in the world’s most prominent scientific journal? “Given that training a single moderately large model produces twice the American lifetime’s worth of CO₂ (ref. ¹⁵), we opted to not run such an experiment and instead focus on a more realistic setting for a proof of concept.”

Nonsense. Absolute nonsense. Just be honest and say “our department chair wouldn’t let us use the big computers for this” instead of making some moralizing, pearl-clutching dreck about carbon emissions — which by the way footnote 15 is a citation to a 2019 paper estimating compute resources and electrical generation sources that are way out of date. They could’ve trained on a server in Texas using wind and solar, or done it in France where the grid is 80% nuclear, or bought offsets if they were genuinely concerned about climate.

So what model did they use instead of a “moderately large model”? Here’s where it gets even more ridiculous. They used the OPT-125m from Meta as hosted on Hugging Face and say that “even the language experiments described in this paper took weeks to run.”

One hundred and twenty-five million parameters. Million with an M. Reader, I have an 8 billion parameter model running on my iPhone 16, and it’s considered a small model. I can run a 70b parameter model at decent speeds using a two year old Mac Studio with an M2 Ultra chip.

Which is all to say, of course they found model collapse and that the synthetic data generated by this tiny little toy model was buggy and weak, and training runs built on top of its output would collapse to a delta function.

It’s like complaining that you can’t enlarge a picture without having things get fuzzy. You do some math and say, See? It loses resolution as we zoom in for 100x and then another 100x and another 100x. Then you do a test with a 150kb digital image from a flip phone in 2002 and say, See? We blew it up 100x and it no longer looks like a rhododendron. Of course we didn’t use a more modern camera, do you know what those things cost and anyway we don’t want to endorse conspicuous consumption because we’re morally superior academics.

When in reality, using a decent camera with a 48 megapixel image blows up quite nicely even to massive scale and yes it’s fuzzy (or fuzzier than the original) but it’s still a rhododendron and you can see a ton of detail.

I honestly doubt whether we’ll end up living in a world of slop. Our current models are so vastly superior to the ones we had in 2023, and advancing rapidly. Ilya may be right that we’re running out of non-synethic data but I question whether that’s ultimately meaningful. Maybe we have more than we need to create objects of real beauty and enable a world of abundance and delight. Maybe our human resolution just isn’t all that sharp. Sure, in a mathematical sense pushing the models for another couple of orders of magnitude will break down. Possibly. But we can’t say for sure from here and all the actual, real-world developments even since this paper came out in July 2024 demonstrate convincingly that we’re nowhere close to collapse.

Keep building.

Second step is to remove the top-most gear from the Leader arm servos. This is pretty simple since each servo has a screw on the corner (a long black one) and the gears just lift off their posts.

I'm saving them because for my next build I may want to have six other servos and may want to drive with them, so I'll put the plastic gears into a box and of course never open it until four or five years from now when I'll wonder what they are. But I'll save them anyway because YOU NEVER KNOW.

This, dear reader, is why I still have my Palm Pilot from 2003, along with several flip phones and their charging cables, plus the original iPhone.

After the servos are all set up with unique IDs and the top gear is removed, the next step is to make sure the drive horns are positioned and locked down with a screw in the center. The case has a little notch at the intermediate positions (10:30 or however you want to describe it; maybe NW?) and the instructions are to put the four screw holes in those coordinates. Not sure why this matters, but hey whatever. The tricky part is that now that the servo has a gear missing, the drive horn isn’t connected to anything and will spin freely. So do your best.

Now it’s time to assemble the servos and the plastic parts into an actual robot arm. The Hugging Face video has a lovely animation showing how the parts fit together, but it’s pretty obvious when looking at a picture of the finished product. The parts aren’t all that similar except for the two main sections with Servos #2, 3, and 4. But those two aren’t identical, so you’ll figure it out pretty easily.

Sometimes you’ll want to connect the leads before pushing the servo into the part for the arm. Servo #3, for example, has a pretty tight clearance between the lower arm part and the ports for the wire leads. Others are actually impossible, like #5 which I had to detach the drive horn from the spindle before it would slide into the “wrist” piece. But you’ll figure it out.

Ta-da! Leader arm is black, with the pistol grip handle and the Follower arm is red.

Once it's all together, move on to the next step: Calibration. You'll need the Hugging Face software package for that.

The cleanest way to do this part of the project is to download the Le Robot python package which has a command line way to get info from the servos and reprogram. But I already had the manufacturer’s software downloaded from this link and watched a YouTube video by The Robot Studio explaining step by step how to reset the servo IDs, so I just did it that way instead.

Plugging in the USB cable makes the power LED on the control board light up, but the servo won’t show up even if it’s connected. That needs power to the board and fortunately I got the right power supply because it says 9-12v on the board and I have a 12v power supply. I thought that might have been too much for the servos, which per the manufacturer top out at 7.4v, but it could just mean that’s all they can take before they stall, not their max capacity. And maybe the controller steps that down anyway? Not sure.

The software is super basic, but gets the job done. You’ll have to make sure the COM port is correct; one of my boards was COM3 and the other COM4, not sure why that happened since I used the same USB C cable to connect to both, and not simultaneously.

Next, you’ll change the BaudR (baud rate, of course) to 1000000, the highest setting. Have no idea why that is and why that’s not the default and why that default doesn’t persist after you close the software program and reopen it. But it does. So check that before moving on.

Then click “open” to make sure you’re sending data over that port, then click “search.” You should get an ID of 1 and the “Modle” of STS3215. If you see lines moving on the graph, you’re good. If not, click the model name or ID and it should fire up. The green line is speed and the black line is position.

The positions go from 0 to 4095 and as far as I know can’t be changed. If you’re smart enough to do this before assembling your robot arm (ahem) then you can set them all to 2048 and put the metal collar on, the one with the splines to match the splines of the drive shaft, and then lock it down. Like the man in the video instructs. Or you could be an excited dumbass who thinks he knows better.

Next step is to assign an ID. This is also simple, but a bit clunky. Click over to the “programming” tab (just above the graph with the lines) and you’ll see a whole list of things that you can fiddle with and where they’re saved and whether you can only read or read and write.

The first entry that you can "rw" is address 5 for the ID. Click that. It’ll highlight in blue. Down in the lower right corner, next to the “save” button, is a window where you can reset the ID number of the servo. Type in the number and hit save, and it should give you a nice pleasant chime of success and a pop-up window with the same. If not, then you probably went too fast from the previous servo and didn’t search or select the new servo or select the new ID under programming.

At the end, if you want to daisy chain them all together and hit search, you should see servos 1 through 6 and when you go back to the debug screen you can move the slider and they’ll whirl into place. Neat!

Having assigned the servos unique IDs, I then labeled them and screwed everything back together. I didn’t set them for zero position though, like the video says, because most of them were connected already and I didn't want to mess with it.

Success! I think. Screwed it all back together and then connected it to the board and power. Everything lit up, I had servos 1 through 6 recognized. But then I wanted to open and close the claw, which is Servo #6. I selected that and slid the position slider and Servo #1 immediately flipped over and locked. So I selected Servo #1 and unchecked the Torque box and moved it to a middle position, which is about 500. So then I typed in 440 and hit save, and it spun to that position and began to quiver. Like it was eager to get to the next instruction. The line on the graph was janky, too, going up and down.

Not sure what the issue is, but we’ll fix it later when I install the Hugging Face software. Next step is to program the Leader servos and for those I have to take out a gear because they're basically not going to work at all, just be a sensor to send back starting position and ending position and speed of movement. Or something like that.

Maybe I will end up having to recenter those servos in the follower arm, so they’ll sync up. One would hope that a reasonably competent control software would translate or benchmark the two: “When Leader Servo #1 is at position 0, that translates to Follower Servo #1 at 643” or whatever, and do relative movements from there.

She watched him position them with the precision of a chess master, all facing east, their rosy cheeks catching the wan light of dawn.

The neighborhood, predictably, descended into whispers and theories. The ladies at number forty-two declared him mad with grief over his recently deceased cat (though the cat was very much alive and simply hiding from the gardener). The retired accountant across the street insisted it was an elaborate insurance fraud scheme, though he couldn't quite explain how.

For three weeks, the gnomes stood their silent vigil, their painted eyes reflecting nothing but the passing clouds and occasional curious bird.

Then came the morning of the vernal equinox. As the sun breached the horizon, each gnome cast a shadow that aligned perfectly with the next, creating an arrow that pointed directly to a time capsule his grandfather had buried fifty years prior, containing the deed to a forgotten piece of land in Switzerland worth millions.

The neighbor had simply been following his grandfather's cryptic instructions, written in a letter to be opened upon his death.Sometimes, you see, what appears to be madness to the common eye is simply genius operating on a frequency few can comprehend.

Though I suppose the real lesson here is that one should never trust a garden gnome that isn't German-made -the craftsmanship simply isn't there.

* * *

Persona: You are a sombre creative director with a history of dry wit and a flair for the dramatic, but most acknowledge you as a brilliant if idiosyncratic writer. Truly your style is novel. Some describe it as groundbreaking, others bold but at times dark. When writing text, adopt this persona. I want you to answer the following in this persona, responding directly and with no preamble:

"Please write a 3 paragraph story with a lesson in it."

Illustration by Grok v2 (beta)

I’ve seen this done before, I remember reading about a guy who built a Lego sorter that didn’t grab any pieces but used vision recognition along a conveyor belt and air nozzles to blow the pieces off the belt into bins, sorting by color. (Apparently buying mixed lots of second-hand Lego is very cheap, but lots sorted by color are pricier.)

My first step was the Le Robot project, by the Hugging Face people. Here’s the GitHub page and it suggests starting with the SO-100 robot arms.

This is a leader-follower design. The yellow arm (leader) on the right has a pistol grip and a sort of trigger, that will open and close the pincer tongs on the orange arm (follower). Apparently the software learns how you move the leader and duplicates those moves on the follower.

Acquire the Parts

First step was to get the parts list and go on to Aliexpress to buy twelve little STS3215 motors (called “servos” I guess, not sure why maybe the point is not to just spin but to control the position accurately) and then Amazon for two controller boards and two power supplies. I elected to beef up the design by using the 12v version of the servo and the 12v 5A power supply. This is double the torque. The servos were $14.88 each because the shops offered three or four at a lower price, like $6 or $7 but I need twelve and didn’t want to split the order up. You do you.

The control boards are on Amazon. Here are the ones I got for $10.55 each but if that disappears search on “serial bus servo driver board st/sc” and see what happens.

Crazy thing is that this will allegedly control 253 servos all in serial, which seems utterly nuts to me but maybe they’re doing magic over there in Shenzhen. The power supply was just “12v 5A power supply” on Amazon, all of that came well before the servos arrived from China.

I know what you’re thinking: Where do I find the screws to put all this together? Here’s the amazing thing, they’re in the box with the servo! Lots of little screws and two metal plates, one with teeth and one without. The servo has a metal driver post with teeth that fit one of the metal discs. The other is just to screw down to the plastic part where the servo is to be installed and provide a sturdy anchor part.

Even includes the ribbon cable for power and data. Well done.

Print the Plastic Bits

Having ordered all the parts, the next step is to download the files for the 3D printer. Oh, did I not mention that? Yeah, pretty much need access to a 3D printer of some kind in order to fabricate the parts for the arms. I have a Bambu Labs X1 Carbon printer and fiddled around making various things for my kids. The precision is astonishing and it’s quite simple to make it work, but do get a decent-sized Micro SD card to store your stuff in. You can print from the Bambu Studio software on a laptop or desktop directly to the X1C since it’s WiFi-enabled, but it’s just a lot easier to download interesting models from different websites and save to the card.

And you will need the Studio for this project because the GitHub repository only has STL files laid out for the Prusa and Ender printers. These will work with the X1C, but because the size of the print surface is a bit different (Bambu labs is 250mm square, nearly; the others are rectangular) you may need to budge it a bit so it won’t throw an error that you’re asking it to print off the surface. Bad!

Nobody says this because I guess all the folks building robots are experts or something, but an STL file won’t print directly. It needs to be “sliced” for your specific printer model. Once it’s sliced, it’s saved as a 3mf file. Moreover, it needs to be a “gcode.3mf” file, which I don’t understand but the ones that aren’t gcode just don’t work.

First thing you want to do is print the gauge model from the GitHub repository. This will print in maybe 15 minutes and you can fit it to your servo to verify that the printer is measuring and specing everything correctly. It only fits one way, as you’ll see when you get your hands on the servos. They have a little bump on one side that is wide and the bump on the other is narrow. Print out the gauge before you spent 10 hours and 350g of filament on a bunch of arm pieces that are off by 1 mm because some setting somewhere ended up being a 99% or whatever. Bad!

Bambu Studio Software Procedure

It took me hours, and I mean hours, to figure this out. Ended up looking at a PDF from the University of Wisconsin’s engineering lab that had a very n00b step-by-step procedure. Go Badgers. But that was apparently an older version of the Bambu Studio software because I had to spend yet more time figuring out where these settings and stuff were.

Here’s what I did, step by step. This is as much for J. Random Person on the internet struggling with the same project as it is for Future Me who will look back in a few months and wonder where the hell that setting is.

The zero-th step is to download the software and get it going on your system of choice. Here is my MacBook Air running 01.10.01.50, the latest version as of this writing.

Step 1 is to click on the home icon in the upper left and then “Create New Project” in the upper right. You should have a user name already and be connected to your home device. That was pretty simple to do from the iPhone app. (It’s very well done, you can even get a live video feed of the print in progress from the interior camera, so you don’t have to keep running out to the garage or wherever you have your printer set up. But the phone app won’t slice an STL file for you. Got to have the desktop software.)

Step 2 is to add the model to your project. This tiny little icon here which makes no sense and isn’t intuitive in any way. Yeah that one.

This will bring up the File menu so go to wherever you downloaded the STL files from GitHub and open one of those. I found that the Prusa versions worked the best, I think because the print area is pretty close so the layout was fine (or maybe off by a tiny bit but you’ll see in the next screen shot how it looks and you can nudge it into place.

Step 3 you’ll click over to the Preview tab on the software and it’ll give you this great view of everything all laid out as a wireframe.

But oh no! Error! This orange box is telling you that the model has a problem and won’t print. Let me save you the trouble: you need to turn on the “support” function. The printer is laying down a very precise line of melted plastic so anything that’s just hanging in mid-air won’t work, it’ll fall over. So the printer needs to lay down some thin scaffolding to be able to build the model up. You can’t see it in this screen shot, but I have it set to show support structures as green. Once you turn that on, it’ll show up. (See Step 5, down below.)

Step 4 shows how to resolve this. Yeah, again, super non-intuitive. You click the tab in the middle of the left menu pane for Support (in orange) and then check the box that says “Enable support” (also in orange). You don’t even want to know how long that took me to figure out. Ugh.

It should automatically refresh and then show you in a contrasting color where those supports are going to be but if not, you can click over to the Device tab and make sure you’ve connected to your specific printer and then coming back to the Preview tab should refresh too.

Step 5 is the one that gave me all kinds of fits. I have the AMS module on the top of my printer, don’t know what it stands for but it holds four spools of filament and if you buy the Bambu filament they have little QR codes printed on the side of the spool and a little reader built in. The AMS will spin the spool and read the QR code and then tell you “Oh this is PLA Matte filament in Red and it’s 1 kg.” Wonderful!

Except.

Except that the model has to know that. I wanted to print the Follower and Leader in different colors (I had red and black) but it wanted to print with whatever filament was in Slot #1 of the AMS. I went back and forth on this, but the solution is to make sure that the Studio software has scanned your printer and gotten the latest info, then go here to this setting and make whatever your print color is as the filament for Slot #1, even if it’s over in Slot #2 or #4.

Here, I’m telling it to use the Black PLA Matte currently residing in Slot #4 as the print option. I’m sure there’s a different way to do this. What threw me off is all the little test stuff I did for my kids I was able to alter the filament choice right before I printed it out. But with these sliced files it didn’t work. So the hack is to set it up before you save the sliced file to gcode.3mf and export.

(I also added a second Big Arrow to show the green support filament structures that the software added after clicking that option earlier. You can close up the details in the color option drop-down pane and get a better look, and zoom in and rotate to see the details.)

And that brings us to Step 6, export your model. I strongly suggest you have a folder for this project and save your gcode.3mf files because it’s a complete pain to go back and re-do all these steps to slice up the file again. But don’t worry, if one of the pieces doesn’t print right, you can select just that object out of the STL file and make that a new project and print it individually. I think. Hasn’t happened to me yet, but that’s the theory. That’s what “plate” means here in this option, everything on the plate.

Once you’ve saved it, you can send it to your printer’s SD card right from this Studio software.

Learned that the hard way; first option for me was to pop out the SD card and use an adapter to connect it to my laptop’s USB port, which worked but then I realized I hadn’t saved the gcode.3mf version of the file, just the 3mf, and that wouldn’t print. I was dreading the trip back out to the garage and of course I’d put the card reader and the USB-C adapter away because I hadn’t used it in four years or so. But then clicking over to the Device tab allowed me to figure out how to send the saved file to the SD card over WiFi.

And here they are, all the pieces for the Follower arm, cleaned up to remove the support structures. Oddly satisfying to pry away the support stuff, they crackle and sometimes pulling on a thread of filament will peel off a whole wad. Don’t worry, the actual piece is much stronger and you won’t accidentally yank anything off. You might scratch the part, though, so don’t be an animal

.Now to assembly!

I was scrolling through Twitter, which remains a source of fascinating learning for me, especially about AI stuff, and came across this tweet. The author is Victor Taelin who is doing a project called HVM, GitHub repo here, described as “a compiler and evaluator for high-level languages that automatically achieves near-ideal speedup, up to 1000+ threads.”

Pretty advanced stuff and I really don’t understand much of it, but from what I gather he’s using a theory that uses a concurrent computation to create Interaction Combinators and in that way allow for a program to run in parallel. This is important because instead of things running serially, working down a bunch of code on a CPU, it can run simultaneously on the thousands of nodes in the GPU. I tried to read the paper on which it’s based, from 1997 by Yves Lafont, but wow did my comprehension come nowhere close to grasping it. Theoretical computer science is … challenging.

Anyway, Victor had this bit of code in a gist that he was asking folks on the internet to run for him, to see if the new M4 chips from Apple were worth investigating. Since his code is pure C, it should run just fine and even includes a little thing at the end to spit out the results. It takes a fixed number of interactions and runs them over a fixed number of nodes and the fast the better, more int/sec, the better.

All of this is an excuse to exercise my new Mac mini with an M4 Pro and 64 gigabytes of unified RAM, shared with the twenty GPU cores. The memory bandwidth is substantially higher at 273 gb/s and I wanted to see how it compared to some of the other systems running Nvidia GPUs and another person with an M2 Ultra Mac Studio.

I used Claude to help me with some of the background and it was surprisingly easy. I’ve seen mention by coders about “compiling from source” and how Real Nerds never just download a binary, they get the source code from GitHub or SourceForge back in the day and compile it themselves. And from what I gather a considerable portion of a developer’s day back in the olden times (like 2004) was waiting for the code to recompile after making an edit or two to the Java code.

It was really quite simple. I copy-pasted the gist to a plain text document on my computer, saved it with a .c extension, which then made the text all colorful because I have syntax highlighting turned on in TextMate. Then I went to the command line and verified that I had Clang installed (not sure why but I did, and it was recent) and typed “clang hvm3.c -o hvm.” I have no idea what the -o flag is doing, but that’s what Claude says so I did it. [apparently means “optimize” and there are three different levels that make various tradeoffs. I stuck to the plain one without a numeric identifier.]

A second or two later, possibly less, it was done. I did a quick ls -lah and saw that, yep, there’s now a binary called “hvm” sitting right there in my home directory.

I had no idea how to run the thing, but another trip to Claude revealed the oh-so-difficult command of “./hvm3”. And do you know what, dear reader? IT WORKED! First time! Amazing.

Here’s the fun part: I ran it ten times in a row, by pressing the up arrow cursor key to get the last run command and then hitting enter, so it did ten different runs of the program all with slightly different times. I then took a screen shot of it and dumped it into Claude and asked it to pull the interactions per second data, do a min-max-mean on it and report the results.

I love using these multi-billion dollar LLMs for mundane tasks, like copying and pasting and performing rudimentary math. In my day job, I had Claude pull the email address for the first lawyer for each defendant out of a 20+ page PDF and then format so I could copy-paste into Outlook. Took maybe forty seconds. Me highlighting and copying over would’ve been easily fifteen minutes of tedium, and I might have gotten something wrong. I spent a minute to double-check, of course, but that was no problem at all and it got it right the first time.

I also ran the same program on my MacBook Air with an M2 chip and on my Ubuntu desktop with a RTX 3080 board.

(oh and one more thing: the cute developer bear cartoon is courtesy of xAI in the Twitter app, it took me four or five iterations to get it right but I think it’s a nice little addition to the essay.)

.

My process was fairly simple. I started with a text file on my laptop and started describing what I wanted. A React app, with a table at the top using data pulled from a screen shot of my client’s existing portfolio tracker. To simplify, I only used the first four publicly traded equities, but the table shows purchase price and current value, from that it can calculate the cost basis. The problem is, how do we transfer those holdings to the limited partners without saddling either the remaining funds or the withdrawing limited partners with a disproportionate share of the capital gains, and hence a greater tax liability?

It’s not super hard to do as math, basically just a weighted average but it then gets tricky from a “what if” perspective. What if Bob wants to pull out $800,000 but Jane wants to withdraw $2.4 million. How many shares of each stock do we transfer? But then what if Bob changes his mind and says No, let’s only pull $650,000 and leave the rest in the fund?

I figured a React app would be best as an interactive dashboard. Why? I have no idea. I think I saw someone tweet about it and the AI created a React web app with a slider. So I thought, Ooh, yeah let’s have a slider.

I wrote a plain text document describing the problem, setting out the limitations, and describing how to present the information. I wanted one table at the top called “Before” restating the current portfolio, then another table at the bottom called “After,” with a subtable or “card” for each LP with a slider and then rows underneath calculating the specific mix of stocks to withdraw and a total withdrawn. So an LP can go to the dashboard, move the slider to get the right percentage withdrawal or just total dollars pulled out of the fund, and it automatically in real time recalculates what the composition of the fund will look like after.

Then I copy-pasted each chunk of instructions into Claude and asked it to present it to me as an Artifact, a side window with the code (Javascript I think? Maybe Typescript? I literally have no idea) and it has a toggle so you can preview what it looks like.

I iterated on that for a while — make the cards narrower, no wider; give me a shadow behind each card, ok now in color, no not that color — and tried to make sure that my text file with the prompts was up to date so I could reproduce it if needed.

Here’s an example of a few of the prompts:

Each card should have the LP's name and a slider for each limited partner showing a value of between 0 and 90 to represent the total value of the withdrawal. Please show that value selected next to the slider.

Below the slider, for each limited partner make four lines showing the number of shares of each stock that would be hypothetically withdrawn to create that total. Please note that a fractional share may not be withdrawn. Only whole shares. Please indent the row slightly from the left margin under each limited partner's name. Each row should have the Name of the stock, number of shares, and the total value of those shares using the current value price from the Before table.

Add a fifth row showing the dollar value of the hypothetical withdrawal, calculated by summing the dollar value of each row. 

Add a sixth row showing  the tax burden of that limited partner's hypothetical withdrawal, calculated by using the relevant values from the Before table. Please display the dollar values in the right hand column of these rows for the limited partner hypothetical withdrawals using commas for thousands and millions -- just like you did in the Before table

Not every paragraph was a new prompt. I think I put two or three, or maybe all four of these, into one prompt. (Can’t give you the full prompt sequence since it contains client information and is privileged, but it’s not important to the story anyway.)

And as it went, it would retype the code in the Artifact window. Candidly, it wasn’t fast. I think it would redo the entire project from the beginning and not cache anything, so it was pretty slow. I sort of expected some of the changes to just jump into the code and fix it, like the background color. I’m not sure how many tokens I used up or how close I came to hitting my daily limit, but I’m on the $20 per month pro plan so I figured they’d give me some slack.

Here’s the best part: when I was satisfied, I discovered a button down in the lower corner of the Artifact window labeled “Publish.” Anthropic automatically turns the React code into a web app, and publishes it to the web with an obscure URL (you can keep it private if you want, but I needed to send it to the client for approval). Amazing feature!

The feedback I got was along the lines of “Why is my card pink? I want a rainbow gradient background!” which is to say, the best kind of feedback for a lawyer; all style, no substance. Yes, this is not exactly what you hire a lawyer for, but it was a question we needed answered and I got a little curious.

Total time spent, start to finish even with aesthetic tinkering: Forty-five minutes. Amazing.

I have in mind to try it in Cursor to see how that goes. Maybe that’s another blog post.

I copied it over into four different models that I had handy on my phone: ChatGPT (running 4o), Claude 3.5 Sonnet, Gemini 1.5 Pro Experimental 0827, and Llama 3.2 3b Instruct q4 (loaded on my iPhone 16 Pro using the Pocket Pal app)1. My methodology was to just say “try again” if it didn’t get it right on the first shot and see how long it took to return the correct answer.

For the first riddle, Variation 2 in the illustration above, here are the results:

ChatGPT-4o — wrong answer (2) on first, got it on second

Claude 3.5 Sonnet — wrong answer (2) on first, got it on second

Gemini 1.5 Pro Exp — correct on first try

Llama 3.2 3b — Amazingly bad. The first response was that it could not answer given the information stated because nothing was indicated about Alice’s brother’s siblings. I told it to try again, same response. I then said “her brothers are related to her sisters” and it responded that her brothers have two sisters. Same wrong answer as the other models, so I said “wrong answer, try again” and it said 2 again. This went on for three more turns until I said expressly “try again and the answer is not two.” And it answered … two. Insert face palm emoji.

For the second riddle, same methodology:

ChatGPT-4o — wrong answer (1) on first, got it on second

Claude 3.5 Sonnet — correct on first try

Gemini 1.5 Pro Exp — wrong answer (1) on first, got it on second

Llama 3.2 3b — Amazingly bad. First answer was wrong (1) and then it went to zero, and kept answering that. I told it the answer was neither zero nor one and to try again and it said … one. More face palm.

The tweet author, Jenia Jitsev, sets up a test on these sorts of problems and benchmarks the 4o model against 4o-mini and find that the 4o model needs approximately 1 try to get the right answer, while the 4o-mini model is all over the place.

He then tests against the extended problem sets, similar word problems that require you to know that, e.g., an uncle is the sibling of your parent and your uncle’s niece is your sister if your parent only has one sibling. These aren’t hard, requires a couple of extra steps, my eleven year old son got the answers correct while watching YouTube on his phone almost as soon as I read the problem out to him. He finds, however, that even the 4o model has substantial variation of answers.

Both models purportedly ace the Math Olympiad and International Olympiad of Informatics problems, problems that are way harder than these. Moreover, there shouldn’t be any variation at all, he argues, because the reasoning required is the same: you either get it or you don’t, so maybe plus or minus one prompt is within variation, but not 6+. Jitsev speculates that maybe the MO and IOI problems leaked into the training data and thus it’s just not reasoning at all.

One response by Lucas Beyer:

Ultimately, that was what made me switch. I was trying to change the font and had Claude suggest some simple edits to the CSS file. But the issue (as far as I can tell) ended up being that whatever edits I made to the CSS didn’t get saved to GitHub, and hence not actually published, because I’d cloned the GitHub repository of the theme (aptly named “Plainwhite”) and because it was owned by someone else and I don’t have permission to edit that repo, nothing would change in my larger repository.

I’m entirely confident that there is a way to fix this, and I tried a couple of things — changing the name of the theme to “new” and saving it as part of my own repository was the best idea I could come up with — but it wouldn’t build from there and threw constant errors.

So here we are on Substack with the same URL as before. And now I also have an iPhone app for quick posts, which I’m using to write this in fact. And smart quotes! Yay! And a nicer font! I was also not able to figure out how to add pictures to Hugo, but now it’s dead simple.

Ok, back to learning.

GGUF is “GPT-Generated Unified Format” which is basically the file format for large language models. Like you would say PDF or jpeg, and an “endpoint” is a cloud service like Groq or Azure or AWS, more formally “a stable and durable URL that can be used to request or invoke a model.” At least according to Microsoft.

“Quantized” is a technique used to reduce the precision of the numbers used to represent the model’s parameters (weights and biases). Instead of using full 32-bit floating-point numbers, quantization uses lower precision representations, such as 16-bit, 8-bit, or even 4-bit integers.

You trade some precision for a smaller size, again like jpeg compression back in the old days of dial-up when we would have to adjust a picture to make it work on the slow web of the day and couldn’t count on the user’s software being able to make that adjustment efficiently (or at all).

So I was pretty blown away when I saw a Tweet by Awni Hannun fine-tuning the new Llama3.2-1b open source model on a iPhone 16 Pro and getting better than 150 tokens per second.

Impressive! No bozo, he’s one of the lead ML researchers at Apple and major contributor to MLX, the open source software that optimizes Apple Silicon for machine learning. He linked to mlx-swift which is a Github repo with the code to download and compile with XCode so I can make an app to run on my iPhone.

I thought I would try it. But before I could open my laptop and start working on XCode (which I haven’t run in maybe eight years) I saw a comment with someone suggesting PocketPal on the App Store. It’s similar, a wrapper around open source models that you can download.

I tried that and it works great, was able to run Llama3.2-3b-instruct — but only at 16 tok/sec. The output is a bit slow, way different from running Groq on the cloud at 2200 tok/sec for the Llama3.2-1b model. Oddly, the 1b model isn't available on PocketPal as far as I can tell.

But hey, a really useful generative AI model running entirely locally, without need of an internet connection, with performance that’s basically on par with state of the art models from less than a year ago. That’s how blazing fast this area is moving.

Found an interesting video on YouTube by Dan Vega:

Ollama is local software for Mac and Windows(!) that takes care a lot of the overhead of running models, but is strictly command line. Here's how to get it started:

ollama run llama3.1

Super easy. You type your queries much like using ChatGPT on the web or an iPhone app, except it’s in a terminal window and it spits out the answers right there, without the pretty user interface. It's all plain text.

WebUI gives a nice, pretty wrapper for that and it’s clearly copied on the font and colors of ChatGPT. Which is a bummer as I really prefer Anthropic’s Claude interface, especially their “artifacts” feature, which opens a sidebar with a mini-window with nice presentation of code and the like.

WebUI runs in Docker and since I like to have things neat I downloaded the Docker Desktop app and it’s a lovely UI for that program.

Still, per Dan Vega, you go to the WebUI docs page and run this command:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Fine. But because I seem to have negative energy when it comes to code, the first time I ran WebUI it asked for a user and password (all local to the Docker image but it's set up out-of-the-box for group useage). I let Apple generate a strong password — which failed to save anywhere, so then I was locked out. MoTH#RF*$ER!!

Killed the Docker image, trashed it, trashed the local resources that I just downloaded, and then Googled to figure out how to change the user environment variable according to the WebUI docs: “If you want to disable login for a single-user setup, set WEBUI_AUTH to False. This will bypass the login page.” Basically I have to add

--env=WEBUI_AUTH=False

to the “docker run” command that downloads everything and sets up the local web page UI.

... or so I thought. Did not work at all. There’s a way to do it in the Docker Desktop app somewhere but it needs to be done before the “docker run” command sets it all up and I simply cannot figure out how to do that. For now, I’ll just create a user with a fake name and password or something like that and see if I can get Chrome to save it for me.

I really like the way they have the page set up. It’s a Jupyter-style notebook in the center where you can type the code that you're learning and then with a simple shift-enter have the page run it and return the results — or, more likely, an error message — right there on the page. Previously, when I was learning several years ago, you’d have one window or a book propped up with the tutorial and another window with a text editor and then a third with the command line. You’d type into the text editor, trying not to just copy-paste because come on bro you need to learn, and then save then Command-Tab over to the iTerm2 window and tell it to run the script and see what the output is.

The rest of the Deeplearning.ai page is a video on the right showing what the tutorial is and walking you through some sample code in the blocks of the notebook in the center, and then a pop-up panel to ask the LLM how to solve the problem. You copy the code that the AI spits out into the notebook and give it a try. So, yeah, still some copy-paste but it avoids so much of the tedium and friction and keeps you focused on learning the actual code. I mean, did you really need to waste ten extra seconds because you went arrow-up on the zshell and re-ran the last command, but forgot to change it from py-tutorial-ch12-ex4.py to py-tutorial-ch12-ex5.py before hitting enter to see if you debugged that issue correctly?

No, dear reader, you do not. Those are wasteful interruptions to your actual learning. This way is far better, and I’m loving the idea that AI coders are the future, so learn that instead of the Old Way. It’s like admitting that people will, actually, use Quickbooks for bookkeeping so let’s go ahead and teach that instead of making a would-be CPA use paper ledger sheets and pencil and abacus to learn how to do accounting.

I asked Claude, thusly:

what does FP16 mean in the context of an LLM?

and here's the answer:

FP16, or "Float Point 16," refers to a 16-bit floating-point numerical format used in the context of Large Language Models (LLMs) and other machine learning applications. Here's a brief explanation of its significance:

1. Precision: FP16 uses 16 bits to represent a number, offering less precision than the more common 32-bit (FP32) or 64-bit (FP64) formats

2. Memory efficiency: Using FP16 allows for storing model parameters and activations in half the memory compared to FP32, which is particularly beneficial for large models like LLMs.

3. Computational speed: Many modern GPUs have specialized hardware for FP16 operations, allowing for faster computations compared to higher precision formats.

4. Training and inference: FP16 is often used in a technique called "mixed precision training," where some operations are performed in FP16 while others use FP32. This balances speed and accuracy.

5. Model size reduction: Using FP16 can effectively reduce the size of an LLM, making it easier to deploy on devices with limited resources.

6. Trade-offs: While FP16 offers benefits in terms of speed and memory usage, it can potentially lead to some loss of accuracy due to its lower precision.

In the context of LLMs, FP16 is often used to optimize model performance, reduce memory requirements, and speed up inference times, especially on hardware designed to handle this format efficiently.

ok thanks Claude.

Is there a native setting for floating point operations? Do models get trained up in FP32 and then “boiled down” or throttled by less precision when it comes to their use in other settings? Interestingly, I asked Claude about that and it said it’d never heard of Llama 3.1 or even a Llama 3 since it was spun up in April 2024 — and apparently 3.1 was released that same month.

Various places on the internet say that models are typically trained up using 32-bit floating point numbers for “model weights and activations.” Then a process called “quantization” takes those weights and represents them with lower-precision numbers, sometimes even four bit numbers it seems. This reduces the memory and computational load so the models run more quickly and efficiently, and hopefully without a loss of quality or at least not a meaningful one. Life is always a trade-off.

Meta has an interesting discussion here of quantization for further reference. Too technical for me at this point.

Things I learned: a four bit integer is called a “nibble,” and represents a number from 0 to 15. Four bit processors were used in microwave ovens, calculators, and cash registers for decimal math. Bit < Nibble < Byte.

My methodology, to the extent I have one at all, is to scroll diligently through Twitter and see where my brain "catches" on a topic, abbreviation, term of art, concept, and then explore that. Sometimes it's just "what does FP16 mean in this context" and tracking that down.

So why bother writing this? Why not just learn and file it away and keep moving? Surely that would be faster. But if I don't put it down somewhere or talk it out, then the concept won't stick and I won't learn. I'm hoping this will be selfishly useful later on either in the act of writing and explaining in straightforward non-jargony prose I'll be able to ramify that concept in my own head, or at the least I'll have some notes to look back at.

And maybe someone else will be searching the internet for the same concept and come upon my notes and it'll help them a little. (For this aspect I am indebted to Patrick McKenzie, the inestimable patio11, for his insight that creating value is sometimes just Writing Stuff Down for yourself and other people. And his exhortation to just write more, like 10x more.) Perhaps some future Large Language Model will be snarfling this up and it'll nudge Claude 15 in a slightly different direction? If LLMs are the path to artificial general superintelligence, then it's all just words and words and words. So let's add to that corpus and try to get things right.