The data

The report is USDA’s National Daily Pork FOB Plant, Negotiated Sales, afternoon edition (LM_PK602). Packers report their sales under Livestock Mandatory Reporting, and USDA publishes:

• The carcass cutout and six primals (loin, butt, picnic, rib, ham and belly), in dollars per hundredweight.
• One row per item, in ten tables from loin cuts to variety meats and products with added ingredients: the pounds sold, the low, the high and the weighted average. Unlike beef, pork has no grades, so each item has one price a day.

Since January 2020 the report has listed 270 different items. Their names are the trade’s shorthand: Bnls CC Strap-off, Derind Belly 13-17#, Trmd Sparerib - MED, 1 PC VAC, FZN.

How it works

The board reads its history the way the beef board does. USDA’s datamart serves any date range with no key, so the site keeps no copy of its own: a GitHub Action reads back the CSVs it has already published and asks USDA only for the last month or two. The first run took all 82 months since January 2020.

The names were the new part. Instead of writing 270 names by hand, the snapshot splits each description into what the item is and how it’s sold: the bone, the trim (1/4 or 1/8 inch), the weight range, the lean percentage, the pack (vacuum-packed, boxed, a combo bin), frozen, and added ingredients. Each piece has an English and a Spanish word. 1/4 Trim Bnls Butt VAC becomes “Boneless pork butt, 1/4-inch trim, vacuum-packed”, and in Spanish “Espaldilla de cerdo, sin hueso, recorte de 1/4 de pulgada, al vacío”. An item USDA adds later gets named the same way and keeps its address. Any item that traded on at least 26 days in the past year gets a page, which today is 156 of them, plus the cutout and each primal.

The site’s Cloudflare Worker checks USDA every half hour for a new report and keeps only the newest, so a page whose copy is behind can show the afternoon’s figures before the evening rebuild.

What it shows

The report for Friday, October 16, 2026 had the pork carcass cutout at $80.55 per hundredweight, up $3.00 from the day before, on 273 loads. A year earlier it was $102.17, so the cutout was down about 21%. The record covers 1,731 business days:

Pork moves more with the seasons than beef. Measured against each year’s own average (the median over 2020 to 2025), the cutout usually runs highest in July, 13.5% above its year, and lowest in January, 10.6% below. The beef cutout, measured the same way, swings from 5.0% above in June to 9.5% below in February. Single cuts swing harder: derind bellies, the raw material for bacon, usually run 17.1% above their year in August and 18.3% below in December.

October 2026 is near the bottom of that cycle and of the year. Per pound, October 16, 2025 against October 16, 2026:

The back ribs’ $2.44 a pound was higher than on only 1 of the other 253 days they traded in the past year.

Where it falls short

• Thin items are noisy. Some items trade a few thousand pounds on a day; one deal can move their average a long way. The board’s “biggest moves” list only counts items with at least 20,000 pounds sold that day, and each page shows the pounds behind every price.
• Machine-built names are plain, not perfect. “Pork picnic, smoker trim (SS)” keeps USDA’s SS because the report doesn’t say what it stands for. The exact USDA description is on every page.
• The Spanish is mine. The cut names follow what’s used in Mexico, with USDA’s description beside them, but a butcher in another country may know a cut by a different name.

The board is at /pork-prices/, in Spanish at /es/precios-de-cerdo/, and with the other USDA boards at USDA market prices.

The data

All of it comes from Livestock Mandatory Reporting, through the same keyless datamart as the beef and pork boards:

Each price comes on four selling bases: live or dressed, and FOB the feedlot or delivered to the plant. The board leads with the two the trade quotes most, live FOB and dressed delivered, and keeps the other two on each region’s page and in the CSV.

How it works

The snapshot keeps no history of its own. It reads back the board’s CSVs, asks USDA for the current year of each weekly report and the last month or two of the daily, and rebuilds the board and the region pages twice a day. The first run made 152 requests to cover 2020 to now. A weekly report dated on a Monday covers the week before it, so the pages label each week by its Monday to Sunday.

A region gets a page once it has a price in at least 8 weeks of the past year. Eight do today. Colorado (last cash price in December 2022) and the Western States (September 2025) are in the table and the CSV but don’t have pages yet.

What it shows

In the week of October 5 to 11, 2026, 5-area live steers brought $220.14 per hundredweight and dressed steers $345.66, on 47,079 head of steers and heifers bought for cash. The record covers 354 weeks. Live steers, 5-area, weighted by head:

The price more than doubled in six years. That is why the board measures seasons against each year’s own average: live steers usually run 2.3% above their year in July and 8.0% below in January.

The regions track each other closely. Over the past 53 weeks, all steers and heifers live FOB averaged within 32 cents of the 5-area price in Nebraska, the Western Cornbelt and the Eastern Cornbelt, which is Michigan’s region. The Eastern Cornbelt is a small market, though: 2,173 head that week against 23,858 in Nebraska.

Where the data is thin

• Texas-Oklahoma and Kansas often have no cash price. USDA publishes none when there are too few cash trades, and those two regions had a published price in only 31 and 45 of the past 52 weeks. Their pages say which week the last price is from instead of showing a stale number as current.
• The daily report is lumpy. Cash buying bunches into a day or two a week, so most daily rows are small. The weekly is the price to quote.
• The calculator compares prices, not bids. Live is FOB the feedlot and dressed is delivered, so freight and shrink sit on different sides. It shows the dressing percentage where the two pay the same, which is the useful number.

The board is at /fed-cattle-prices/, in Spanish at /es/precios-de-ganado-gordo/, and with the other USDA boards at USDA market prices.

I had three reasons for building it. I wanted to build something that works with the Discord bot I already use for posting: the bot puts the videos up, and this page shows how they do. I wanted the channel to be easier to discover. And I wanted somewhere on my own website to track how the channel performs, so the numbers show how my tool is doing.

Why a page can’t just ask YouTube

YouTube’s numbers come from the YouTube Data API, and every request needs an API key. A web page that asked YouTube directly would have to put that key in its source, where anyone could copy it and spend its quota. So the asking happens somewhere else: a small Cloudflare Worker, the same one behind this site’s reefer rate board and border wait board.

How it works

1. Every three hours, the Worker wakes itself up. A cron trigger runs it at 17 past midnight, 3, 6 and so on (UTC). Nobody has to visit the page, and my computer doesn’t have to be on.
2. It asks YouTube three questions. One call gets the channel’s subscribers, total views and video count, one gets the list of its latest uploads, and one gets each upload’s views, likes and length. Each call costs one unit of YouTube’s free daily quota of 10,000, so the whole day costs 24.
3. It writes the answer down. The latest snapshot goes into a small SQLite database on Cloudflare (D1), along with one row per day for the last 40 days, which is where the day-by-day changes come from. If YouTube doesn’t answer, nothing is overwritten.
4. The page reads the snapshot, not YouTube. A visit costs YouTube’s quota nothing, and Cloudflare keeps a copy at the edge for five minutes, so most visits don’t even reach the database.
5. At least once a day, a copy goes into the page itself. A GitHub Action writes the snapshot into the page’s HTML. That’s what search engines and link previews see. The same run adds each day’s numbers to a CSV in this site’s repository, which is the permanent record; the database only keeps the recent days the page needs.

The key is a plain API key stored as a Cloudflare secret. It can only read public data, so it can’t upload or change anything on the channel. The bot does the uploading with its own sign-in and its own quota, so this page can never get in its way. All of it runs on free plans.

For discoverability, the page is built to be found and to send people on. Its title and description say what the channel is, the numbers and the latest full game and Shorts are in the HTML, every recent upload links to YouTube, and a “Browse by matchup” row turns titles like “Kalista vs Smolder” into searches of the channel.

What the numbers show

When the site last copied the snapshot, on October 16, 2026, the channel had 183 videos, 92,443 views all time and 14 subscribers. The 12 latest uploads, from October 13 to 16, split very unevenly:

The most-viewed was a Short, “What should Thresh & Jhin have done vs Kalista?”, at 1,339 views. The day-by-day log shows the channel gained 2,310 views on October 15 and 2,213 on October 16 by the time of the copy, with no change in subscribers either day.

Where it breaks

• It’s a few days of data. The full games were all uploaded in those same four days, the last one hours before the copy, so their counts may still move. Four days can’t say how a full game does over a month.
• The day-by-day history is short. It holds one row per day, so it only says something once there are weeks of rows.
• Some of it is YouTube’s rules, not mine. The public subscriber count is rounded to three significant figures, and “Short” on the page means an upload three minutes long or less, which is YouTube’s own limit for one.

Updated October 18, 2026: the Worker now polls every three hours instead of every hour, since a channel this size barely moves in an hour, and every day’s numbers are kept in the site’s repository rather than in the Worker’s database. The numbers above are from the October 16 copy.

The YouTube page has the live numbers, the latest full game and Shorts, every recent upload and the day-by-day changes. The Worker’s code is in the worker folder of this site’s repository.

I built the Reefer Rate Board for two reasons. I wanted to learn more about Cloudflare and APIs: how to call one on a schedule, keep what it returns and serve it back without a server of my own. And I wanted to improve this site’s SEO. A board like this gives search engines a lot to find: a page for every lane, with every number in the HTML.

The data

USDA’s Agricultural Marketing Service publishes the Specialty Crops National Truck Rate Report (report 2375) every week. Its market news reporters ask shippers, receivers and truck brokers what it cost to move produce in a 48 to 53 foot refrigerated trailer, broker fees included. Each rate goes from a shipping area, like South Texas, the Imperial Valley or Central Wisconsin, to one of ten big cities. Each one is a range, low to high, sometimes with a “mostly” range where most loads actually moved, plus USDA’s read on whether trucks are short or in surplus.

Through the MyMarketNews API it comes as one row per shipping area, city and commodity. The same rate is repeated for every crop it covers, so one number can show up dozens of times.

How it works

1. A Cloudflare Worker asks USDA. It holds the API key, which is free, read-only, and stored as a Cloudflare secret, never in the site’s code. It fetches whichever week it’s asked for, and the U.S. diesel price from the Energy Information Administration. It stores none of it: USDA and EIA already keep the history.
2. It boils the rows down to lanes. Each distinct rate a shipping area quotes to a city comes back once, with the crops it covered. Usually there’s one rate per lane. Sometimes an area quotes a second rate for a group of crops, citrus most often, and the board lists that separately.
3. Twice a day, the site rebuilds. A GitHub Action reads back the CSV of every week on record and asks the Worker only for the newest week and the four before it, in case USDA corrected one. Then it writes the board, a page for every lane and the CSV. The pages are plain HTML, so reading them never touches the Worker, however many people visit.

The free plan shaped the design. A request gets 10 milliseconds of CPU, so the Worker answers one week at a time, and the CSV is written by the GitHub Action as a static file instead of by the Worker. The whole thing costs nothing to run.

What it shows

The report for the week of October 12, 2026, published October 14, quoted 68 lanes from 10 shipping areas. Areas out of season keep their pages, so there are 299 lane pages in all, and the CSV holds 30,908 weekly rates back to April 2021. The biggest moves that week:

Trucks were short in Delmarva, South and Central California, and Yakima and Wenatchee.

Each lane page compares the week with that lane’s own history. South Texas to Chicago was $3,800–4,400 a load, mostly $3,800–4,000, which is higher than 154 of its 283 earlier weeks on record. Over the last 52 weeks it was quoted every week, from a low of $2,400 to a high of $7,000, averaging $4,510 at the middle of the range.

The history changes the answer. When I first wrote this, the record only went back to March 2026, and the same rate was higher than just 9 of 37 earlier weeks, which read as cheap. With every week back to April 2021, it’s about average.

What surprised me

USDA’s typos. This is the most consistent public record of reefer spot rates there is, and it still has mistakes in it. For the week of May 25, 2026, the report has Florida to New York at $53–5,500. The weeks around it were $5,500–5,700 and $5,600–5,800, so that low was almost certainly $5,300 with digits missing. USDA’s own change column for that week says −50%, so the typo made it into their math too. Two months later, South and Central California to Atlanta has a low of $740 for the week of July 20, where the weeks around it start at $7,200.

For a while the board took those numbers at face value, and the Florida to New York page said the lane’s lowest rate on record was $53. Real ranges in the data never span more than about 2.2 times from low to high, so now a low under a quarter of its high is treated as a typo and left off the pages. The CSV still keeps the report exactly as USDA published it, so anyone can check.

Diesel. The board also tracks EIA’s weekly U.S. average price for diesel, the number most fuel surcharge tables are built on. The week of October 21, 2024, it was $3.553 a gallon. At the end of August 2026 it was $5.599. It then climbed for three straight weeks to $6.529 on September 21, and was $6.179 the week of October 12.

Where it breaks

• The rates are USDA’s survey, not a quote. They’re what reporters heard for spot loads that week. A contract rate, or one specific load, can sit outside the range.
• The board can’t split a rate into fuel and everything else. USDA’s rates are all-in, so the diesel table sits beside them without saying how much of a move came from fuel.
• The history starts in April 2021. That’s as far back as USDA’s API goes for this report, and USDA published no report for one week in between. The comparisons on each lane page are against that record, not against every rate ever charged.
• Lanes come and go with the seasons. A lane missing from this week’s sheet is usually just out of season. Its page stays up with its history.

The Reefer Rate Board has this week’s sheet, a lookup for any lane, the rates into each city and the whole history as a CSV. The lanes from Mexico also show the live truck waits at their border crossings, from the border wait board.

The Boxed Beef Price Board puts it on one page, with a page and the full daily history for every cut. I wanted another project in the same mold as the reefer rate board and the border wait board: a public data source, the site’s Cloudflare Worker, pages search engines can find, and nothing to pay.

The data

The report is USDA’s National Daily Boxed Beef Cutout and Boxed Beef Cuts, Negotiated Sales, afternoon edition (LM_XB403). Under Livestock Mandatory Reporting, packers have to report their sales, and USDA publishes the totals:

• The cutout, for Choice and for Select: an estimate of what a carcass is worth broken into the cuts packers sell, in dollars per hundredweight (100 lb) of carcass.
• Seven primal values: the rib, chuck, round, loin, brisket, short plate and flank.
• One row per cut, for each grade: the number of trades, the pounds, the low, the high and the weighted average. Each cut is named the way the trade orders it, with its IMPS number and a fat limitation code, like Rib, ribeye, bnls, heavy (112A 3).
• Ground beef and trimmings, sold by lean percentage.

USDA’s Livestock Mandatory Reporting datamart serves all of it as JSON with no key. One request with allSections=true returns the whole day’s report, about 110 KB.

How it works

1. The history stays USDA’s. USDA already keeps every report, and the datamart serves any date range, so nothing on this site stores a second copy of it. A GitHub Action runs twice a day and reads back the CSVs the site already publishes, which hold every day fetched so far. It asks USDA only for what they don’t settle, which on an ordinary run is the last month or two (USDA sometimes corrects a report). The very first run asked for all 82 months since January 2020, about two minutes of downloads.
2. A cut that didn’t trade is left blank, never zero. USDA prints those as $0.00 with no trades. Stored as a price, they’d drag every average toward nothing, so they’re not stored at all.
3. The Action rebuilds the site. It writes the board, a page for each of 58 cuts, primals and ground beef items, the CSVs (the daily cutout and primal values, and one file per year of every cut) and a JSON file of the newest report. The pages are plain HTML.
4. A Cloudflare Worker watches for the next report. Every half hour it asks USDA for the newest report’s summary, a few hundred bytes. When there’s a new one, it fetches the whole report, about 110 KB, and keeps it: one row in a SQLite database on Cloudflare (D1), the only thing it stores. The rebuilds only come twice a day, so a page whose copy is older than a report that should be out asks the Worker and puts the new figures at the top, usually within half an hour of USDA posting them. Otherwise the pages ask nothing.

What it shows

The report for Friday, October 16, 2026 had the Choice cutout at $372.31 and Select at $353.05, with 103 loads of Choice and 5 of Select sold. A year earlier, October 16, 2025, Choice was $366.11, so the cutout was up 1.7%. The record covers 1,731 business days, from January 2, 2020:

The record high is from the spring of 2020, when packing plants shut down: $475.39 on May 12. Two months later, on July 17, the cutout hit its low for the whole record, $200.47.

A cutout up 1.7% on the year hides how differently its parts moved. Choice prices per pound, October 16, 2025 against October 16, 2026:

Each cut page ranks the latest price against the cut’s own past year. The heavy boneless ribeye’s $15.47 a pound was higher than on 234 of the other 254 days it traded in the past year. The boneless top sirloin butt was the opposite, higher than on only 2 of 253.

What the history shows

Every cut has its own season. Each cut page compares every month with its own year’s average and takes the median over 2020 to 2025. That takes out the drift: the cutout rose about 50% in those years, and without it every later month would look dear. The Choice cutout usually runs highest in June (+5.0%) and lowest in February (−9.5%). The loin cuts swing much harder than that, and they peak at the same time of year:

The ribeyes peak at the other end of the year, in November and December. Lean ground beef barely moves at all.

The median matters. Averaged across the years instead, the numbers say the cutout usually runs 14.6% above its year in May. That’s 2020 alone: one May with closed plants and a record cutout is enough to make every May look expensive. With the median, May is +0.4%.

Select sometimes beats Choice. Choice has more marbling and nearly always costs more. Not always: Select’s cutout came in above Choice’s on 16 days in the record, once in February 2022 and 15 times between January and May 2026. The widest gap the other way was $39.74, on June 21, 2021.

Where it breaks

• It’s negotiated sales only. Beef sold on formulas or forward contracts is reported separately and isn’t in these numbers.
• Select is thin. On October 16, Choice sold 103 loads and Select 5. Many cuts have no Select price on a given day, and the ones that do can rest on a handful of trades. The board’s list of the week’s biggest moves only counts cuts with at least 10 trades for that reason.
• They’re wholesale prices, in nominal dollars. A cut in a box at the packing plant is worth far less a pound than the same cut trimmed and wrapped in a store, and the history isn’t adjusted for inflation.
• Seasons need years. Six full years is enough to see a pattern, not enough to promise one. The pages say “usually”, and the year-by-month tables show every month, so you can see when a season didn’t hold.
• A day can be missing. USDA doesn’t publish a price it would have to hide to protect who traded, and federal holidays have no report. Those days are blank.

The Boxed Beef Price Board has today’s cutout, the primals, every cut by primal, the biggest moves of the week, the history since 2020 and the data as CSV files, free to use with credit to USDA.

I built the Border Wait Board for the same reasons as the reefer rate board: to learn more about Cloudflare and working with APIs, and to improve this site’s SEO, with a page that people searching for a crossing’s wait time can actually find. The two boards also fit together. Produce loads from Mexico wait at these crossings before they roll, so the reefer lanes from South Texas, Nogales and Calexico show the live waits at their crossings.

The data

CBP’s Border Wait Times feed is public and needs no key. It lists about 85 ports, and about 50 of them have commercial lanes; the board shows 53, 28 on the Mexican border and 25 on the Canadian. For each one, officers post the wait in the standard commercial lanes and in the FAST lanes (for carriers and drivers in CBP’s Free and Secure Trade program), how many lanes are open, and the time they posted it.

How it works

1. A Cloudflare Worker reads the feed every half hour. It’s the same Worker that runs the reefer board, and both of its hourly cron runs, at 17 and 47 past, read CBP.
2. Each reading is kept once, for good. A reading is stored with the port and the time it was posted, so reading the feed twice in one hour never counts the same reading twice. The Worker holds the last two weeks in a small SQLite database on Cloudflare (D1), and every rebuild adds them to the permanent record: one CSV per year in this site’s repository, where a reading, once kept, is never changed.
3. Unknown is not zero. When lanes are closed or an update is pending, CBP posts no wait. Those are stored as blanks, not as zero minutes, and every average skips them. Counted as zero, a crossing that’s often closed would look fast.
4. Times are the port’s own clock. The feed gives each port’s local date and time, and that’s what “the best hour to cross” has to mean. Its time zone labels aren’t always right, though: Arizona ports say PST, and Port Huron says EST in October. So the board uses the clock time and ignores the labels.
5. CBP’s own history fills the gap. CBP also publishes, for every port, the average wait at each hour of each weekday in a month, from the year before. Until a crossing has a few days of the board’s own readings, its page shows CBP’s numbers for the current month, labeled as CBP’s.
6. At least once a day, the site rebuilds. A GitHub Action copies the Worker’s data into the site: the board, a page for each of 16 major commercial crossings, CSVs of every reading and of the 30-day averages, and a Spanish page for each of the 9 Mexico crossings among them. The Spanish pages use CBP’s own Spanish (“sin demora” for no delay, “carriles generales” for the standard lanes) and point at their English pages, so search engines show the right one. The “right now” columns also refresh from the Worker when a page opens.

What it shows

The board’s own record only started on October 14, 2026, so for now the usual waits come from CBP’s averages for October last year. In the standard commercial lanes, the six crossings with the longest average wait:

Four of the six are at their worst on a Monday, and every one is at its best early in the morning or late at night. Averages also hide peaks: Port Huron’s 23-minute average comes with an 82-minute peak at 5 PM on Mondays. Closer to home, the Ambassador Bridge in Detroit averaged just 6 minutes that month, and 3 in the FAST lanes.

When the site last copied the data, on the evening of October 16, 37 of the 53 crossings were posting a wait, and the longest standard-lane wait was 60 minutes at Sweetgrass, Montana.

Where it breaks

• Last October isn’t this October. Until the board has its own month of readings, the usual waits are CBP’s averages from a year ago. Each page says whose numbers it’s showing, and CBP’s published averages for every month and crossing are kept in a CSV to check the board’s own numbers against.
• Early averages are thin. A crossing needs about two days of readings before the board will name its own best and worst hour, and even then an hour may rest on two or three readings. The pages show how many readings each one is based on.
• The wait is what CBP posts, rounded the way CBP rounds it. Texas A&M’s Border Crossing Information System measures crossing times with roadside readers at some ports in Texas, New Mexico and Arizona. That’s a different measure, so the two are worth comparing.

Updated October 18, 2026: CBP keeps no past readings, so the board’s record started when the Worker did, on October 14. An independent public archive had saved CBP’s whole feed about once an hour since September 13, and its readings are now part of the record, run through the same code the Worker uses and marked as the archive’s. Where both had a reading, they matched 523 times out of 530. The record now goes back to September 13, so the board’s own 30-day averages have taken over from CBP’s. The numbers above are from the October 16 copy. Checking this also turned up a bug: the Worker read CBP’s dates as two-digit months and days, but CBP writes October 1 as 10/1/2026, so from November 1 it would have stopped recording on the first nine days of every month. That’s fixed.

The Border Wait Board has every commercial crossing right now, the crossing pages have a heat map of the usual wait by day and hour, the Mexico crossings are in Spanish too, and every reading, the 30-day averages and CBP’s published averages are free CSV downloads on the board.

This is how it works and what it turned up.

What a spreadsheet can’t keep up with

A spreadsheet is fine for a handful of recipes. You type in the price of paper and leather, write a formula for a book, then one for a bookshelf. The trouble is that Minecraft has a lot of recipes and they feed into each other. Every new item means new formulas, and every price change ripples up the chain.

Craft Ledger flips that around. You never enter a recipe. The full vanilla recipe set is built in, read from the game’s own data files: 1,536 recipes covering 2,770 items, including crafting, smelting, blasting, smoking, campfire cooking, stonecutting and smithing. You only enter prices. The more raw materials you price, the more of the list fills in on its own.

How it works

For every item it works out two things: what it sells for, and what it costs to make by the cheapest recipe. The interesting part is what counts as “cost.”

Say books sell for 2,000 and a bookshelf for 15,000. A book costs 1,161 to craft from paper and leather, so it’s tempting to say the bookshelf costs six planks plus three books at 1,161. But if you can sell a book for 2,000, putting it into a bookshelf costs you 2,000, because you gave up that sale. That’s opportunity cost, and it’s the default here (I call it Market basis):

Both numbers are right. Market tells you whether the last step is worth doing. Cheapest tells you whether the whole chain beats doing nothing.

Two things made the math harder than a spreadsheet:

• Recipes loop. Nine gold ingots make a block of gold, and a block of gold makes nine ingots. A formula that follows recipes downward never finishes. The ledger instead starts from the prices you know and keeps passing over every recipe, lowering each item’s cost whenever it finds a cheaper way to make it, until nothing changes anymore.
• The top price doesn’t hold. The best order on the board might only want nine units. The ledger stores the order book and walks it for the number of units you actually plan to sell, so an item that looks great at a volume of one can fall off the list at a volume of a thousand.

It also charges fuel for smelting from the burn time of whatever you pick, takes the server’s sale fee off every profit, and marks prices amber after a week and red after a month so stale numbers don’t quietly skew everything above them.

What it turned up

The ledger opens with 13 example prices. They’re made up, not DonutSMP’s, so they show how it reads rather than what to craft today. With just those, at a volume of 1,000, it ranks:

Even this small example shows the pattern. Bookshelves earn the most per unit, but the golden carrot has the best margin on the board, and packing gold ingots into blocks loses money even though it feels like it should be free.

That was the real surprise once I put in actual server prices: there are opportunities in a lot of items you would never consider. Ender chests were mine: a high margin, and I crafted a ton of them.

Pricing more items makes the list grow quickly, and the Coverage tab ranks the items you haven’t priced by how many crafts each one would unlock, so you know what to look up next.

Where it breaks

It knows vanilla recipes only, so servers with custom items or changed recipes aren’t covered. It also only knows the prices you give it. Prices on a live server move every day, and a stale price deep in a chain throws off every item above it. Buy and sell are one number too, because on DonutSMP you fill on orders. On a server with a wide gap between buying and selling, you’d have to pick which side you mean.

Try it

Craft Ledger is free, needs no account and keeps your prices in your browser. It works on any SMP with an auction house, an order board or player shops. There’s a step-by-step guide for DonutSMP below the ledger.

This post is how it works, what the sample case shows, and what I learned about solvers along the way.

The problem

Aggregate planning asks a simple question with an annoying number of moving parts. You have a year of monthly demand. You have a workforce that can make so much a month. What’s the cheapest way to cover the gap?

Every option costs something. Hiring and layoffs cost money. Overtime pays a premium. Stock built early has to be stored. Orders filled late cost goodwill. Cases usually ask you to compare three policies:

• Level. Keep the same workforce all year. Build inventory in slow months, use it up in busy ones.
• Chase. Hire and lay off freely so production follows demand.
• Band. Let the workforce move, but only between limits you set.

The planner solves all three at once, from the same inputs, and puts them side by side.

How the solver works, in plain words

Every month gets a handful of decisions: teams hired, teams laid off, teams employed, overtime hours, units made, units held in stock, and orders left late. Those are the variables. Then every month has to obey four rules:

1. Teams this month = teams last month + hires − layoffs.
2. Last month’s stock + this month’s production = this month’s demand + what’s left over (late orders count as negative stock).
3. Overtime can’t go past the cap per team.
4. Production can’t go past what the teams can make in regular time plus overtime.

The goal is to make the total cost of all those decisions as small as possible. That’s a linear program: every cost and every rule is a straight-line formula of the variables. For the 12-month sample, it comes to 84 variables and 48 rules.

The catch is people. You can’t hire 6.35 teams. Requiring whole teams turns it into a mixed-integer program, which is much harder in general. The solver handles it with branch and bound. First it solves the problem with fractions allowed, which gives a cost no whole-team plan can beat. Then it picks a fractional number, say 6.35 teams, and splits the problem in two: one where that month has at most 6 and one where it has at least 7. It solves both halves, throws away any branch that can’t beat the best whole-team plan found so far, and keeps splitting until nothing better can exist.

The solver doing that is HiGHS, a free, open-source optimizer. It’s compiled to WebAssembly, so it runs inside the page. The page writes the model out as text, hands it to HiGHS in a background thread, and reads the answer back. Nothing you type is sent anywhere.

What the sample case shows

The page opens with a made-up seasonal product. Demand climbs from 1,600 units in month 1 to 4,100 in month 11. The plant starts with 12 teams of 5 workers. Labor is $25 an hour, overtime $37.50. Hiring costs $500 a worker and a layoff $800. A unit costs $12 a month to hold and $30 a month to leave late. The year has to end with 12 teams, at least 300 units in stock and nothing still late.

With whole teams, HiGHS returns:

Total material is the same $1,992,000 in every plan, because all three make exactly the 33,200 units demand needs. The difference is all in how they pay for labor and storage. The level plan spends $245,040 holding stock that peaks in month 8. The chase plan spends $65,000 on hiring and layoffs instead and keeps holding costs down to $43,920.

A few things in there I didn’t expect:

• Chase only saves about 7%. Total freedom to hire and fire beats a fixed workforce, but not by much. A band of just 10 to 14 teams gets more than half of that saving, with 4 hires instead of 10.
• The cheapest plan runs late on purpose. Chase leaves 8 units unfilled in month 3 and 8 more in month 8. Each one costs $30 for the month. Adding staff or holding extra stock to cover them would have cost more.
• Whole teams cost very little. With fractions allowed, the chase plan costs $4,867,016, about $8,900 less, using 6.35 teams in the first month. Branch and bound took 13 nodes to find the best whole-team plan and prove it. Level and band needed only the first node.

What surprised me

How accessible and accurate this was. I went in thinking a real solver meant a license, a server or at least a Python setup. Instead, HiGHS gives exact, provably optimal answers in under a second, in a browser tab, for free. You don’t have to take its word for it, either. The page exports a workbook in the usual Solver layout, with live formulas, so you can check every number or run Solver on it again. It’s also not just a classroom trick. The same kind of model plans real production, staffing and inventory.

Where it breaks

The model is only as honest as its assumptions. It treats the demand forecast as known. A real plan has to absorb forecast error, and this one will happily cut inventory to the bone if you tell it demand is certain. Costs are linear too: the 50th hire costs the same as the first, and a team is just as productive in its first month as in its tenth. It plans up to 24 months, and HiGHS stops after 20 seconds if a whole-team model gets hard. The page then suggests allowing fractions or a shorter horizon.

Study mode

The part I’d want a student to use is Study. It takes the same plan apart with your own numbers. It shows how the inputs become the model, the solve with fractions allowed, the first branch-and-bound split with both halves solved, HiGHS’s own search log, and shadow prices: what one more unit of demand or capacity in each month would change the cost by. It also shows the exact model text that was sent to the solver.

Two things I hope a student takes away. First, how solvers work: they aren’t magic, just a careful search over a model you wrote down. Second, how much logistics pulls together. This one case needs forecasting, labor planning, cost accounting, inventory policy and optimization all at once, and a good plan comes from understanding all of them.

The Aggregate Planner opens on the sample. Change any number and it solves all three plans again, or switch to Study to see how it got there.

So I built it. The Fruit Fly Dispatcher puts a fruit fly’s navigation circuit in charge of a delivery truck and races it against Google’s OR-Tools for a week of deliveries. You can watch any of the runs on that page. This post is how it works and what came out of it.

The setup

One truck, one distribution center, 55 convenience stores, Monday to Sunday. Fresh food sells in breakfast, lunch and dinner rushes off a shelf that only holds 40% of a day’s sales, so the truck has to keep coming back. An empty shelf means a lost sale. The truck drives 30 km/h and every stop takes 5 minutes. Profit is a 30% margin on what actually sells, minus ¥200 for every kilometer driven. The store economics come from the class case.

Four “brains” take turns driving:

• OR-Tools, live. Google’s exact solver (CP-SAT), re-planning the rest of the trip at every stop.
• OR-Tools, planned day. Plans every trip at dawn from that morning’s shelf data.
• Fly rule. A greedy rule: go wherever earns the most per hour, one stop at a time.
• FlyWire brain. The fly’s own navigation circuit, built from the connectome.

The twist is that each brain is also run at four levels of knowledge:

1. Company data. Live shelf levels and GPS, which is what a real dispatcher at 7-Eleven has.
2. Perfect memory. Knows every store and how it usually sells, but only learns shelf levels by smell.
3. Learning fly. Starts knowing only where the depot is and learns the stores as it finds them.
4. Dumb fly. No memory at all. It finds stores only by following their smell, and every day is its first.

That split is the whole point. I wanted to separate who makes the decisions from what they know.

Putting a fly in the driver’s seat

FlyWire is a map of every neuron and synapse in an adult fruit fly’s brain, published in Nature in 2024. The part I used is the navigation circuit. One ring of cells keeps track of which way the fly is facing, another set holds a goal direction, and steering cells compare the two to decide which way to turn. When the fly smells something, wind-sensing cells write an “upwind” goal into those same goal cells through their real FlyWire connections. So memory (“the store was over there”) and smell (“something good is upwind”) compete inside the actual wiring.

I tried to keep myself honest here. Every direction the circuit uses was derived from the wiring alone and then checked against something independent. I didn’t feed any published results in. A few things aren’t the connectome: four settings were tuned on simple single-goal steering, two constants come from behavior studies, and the choice of which store to go for is a foraging rule I wrote. The circuit handles the steering, not the whole business.

All the brains share the same reflexes when memory runs out: surge upwind on a whiff, cast crosswind when the scent is lost, then search in a spiral. Across the density sweeps and example weeks, that came to more than 300 simulated weeks.

What happened

Knowing beat deciding, by a lot

Going from a fly with no memory to live company data is worth about ¥19.7M a week on average. Swapping one brain for another at the same level of knowledge changes profit by at most ¥3.86M. What the truck knows mattered far more than how smart the thing driving it was.

Even more surprising: a fly that just remembers where the stores are and how they usually sell earns 99% of what live point-of-sale data earns. Most of the losses come from not knowing the map at all.

The fly won when information was thin

With the same senses and the same truck, the FlyWire brain beat OR-Tools by up to 9%. That was as a dumb fly, with stores about 128 m apart. In the dense example week the gap was bigger. With no memory, the fly served 55% of demand against OR-Tools’ 43%:

An optimizer is only as good as what it’s told. Give it good information and it’s the best there is. Take the information away and it’s planning around stores it doesn’t know exist. The fly doesn’t plan much at all. It reacts to what it smells, and blending that with whatever it remembers lets it pick up stores it passes on the way. When stores are packed close together, that turns out to be a very good strategy.

Spread the stores out and the solver takes over

This is the part I didn’t expect going in. It only works when stores are close. Spread them out and every wrong turn gets expensive:

OR-Tools wins at every level. By the time stores are 5.1 km apart, the learning fly earns 47% less than the solver. Exact routing also only starts paying off (up to 10% over the greedy rule) once stores are about 1.3 km or more apart. Below roughly 640 m, the simple rule ties it.

Density explained the 7-Eleven case

The case talks about 7-Eleven Japan delivering fresh food about three times a day, against about once a day in the US. I never told the model to do that. It came out on its own. With stores packed close, one truck manages about 3.7 deliveries per store per day. Spread the same 55 stores out and it drops to 1.1. Past about 546 m between stores, the truck can’t come back often enough, no matter which brain is driving. Delivery frequency isn’t really a policy you pick. It follows from how close your stores are.

Learning, and what bad GPS does to it

A learning fly in a dense area goes from serving 70% of demand on Monday to 99% by Sunday, and knows 50+ stores by Tuesday. In the spread-out layout it only gets from 40% to 45% and finds 28 of the 55 stores all week. Getting a new driver or a new area up to speed has a real cost, and that cost grows with distance.

I also added drift to the truck’s sense of its own position. A learning fly records its map while it’s drifting, so the map itself ends up wrong. FlyWire lost 54% of its profit, OR-Tools 68% and the greedy rule 70%. The fly held up best because smell corrects a bad memory on the way in.

What I took from it

• Fix the information before the algorithm. Clean store locations and demand history got 99% of the value of live data.
• Optimizers earn their keep when stops are far apart. In a tight cluster, a simple rule ties an exact solver.
• When information is poor, let the edge react. A driver who stops where the shelf looks empty can beat a plan built on bad data.
• Density drives frequency. Cluster the stores and frequent fresh delivery follows.

The fly didn’t beat Google in general, and I didn’t expect it to. What it did was show where each approach makes sense. In a tight network where nobody knows much, a brain that evolved to find food by smell is really good at logistics. Where the map is big and every kilometer costs money, you want the solver.

Every run is on the Fruit Fly Dispatcher page. You can pick any brain at any level and watch its whole week, or drag the memory and smell inputs around inside the circuit yourself.