DEV Community: Jim L

Code Interpreter is infrastructure, not a prompt

Jim L — Tue, 11 Aug 2026 12:33:52 +0000

I spent a weekend trying to move a custom GPT onto local weights and got the model part done in about an hour. The rest of the weekend went to one feature I had never once thought about: Code Interpreter.

My assumption going in was that writing Python was the hard part, so a model that writes decent Python covers it. That assumption is wrong in a specific way, and it is worth naming because the same mistake shows up in every "local model vs ChatGPT" comparison I have read.

Writing Python is the easy half. The hard half is running it.

What you are actually replacing

When a user uploads a CSV to a custom GPT and asks it to plot something, here is the shape of what happens on OpenAI's side:

a container spins up
the file lands in it
generated code executes against that file
the container has no network
it dies on a timeout
nothing it did can touch anything else

Every one of those is a decision someone made and then operated. None of them is a prompt. You do not get any of them by downloading weights, no matter how good the weights are at writing pandas.

So when you move off a custom GPT, this is not a capability that ports and it is not a capability that disappears. It is a capability that becomes yours to host. That distinction turns out to matter a lot for planning, because the three categories behave completely differently:

Category	Example	What it costs you
Ports as-is	Your Actions endpoint	Nothing, it was already your HTTP API
You rebuild	Code Interpreter	Evenings, plus something you now operate forever
Does not port	Image generation	A second model, or a no

I had been treating all three as one bucket labelled "stuff I lose", which made the whole decision look scarier than it was, while simultaneously filing "I'll just add a sandbox" under Saturday afternoon, which made the actual work look easier than it was.

The naive version and why it is not fine

The first thing anyone writes is this:

exec(generated_code, {"__builtins__": {}})

This is not a sandbox. Stripping builtins is a speed bump for anything that can reach a class hierarchy, and a generated script does not have to be malicious to hurt you here. A model that writes an accidental infinite loop, or an accidental while True that appends to a list, does the same damage as one that was trying to.

The actual requirements, once I wrote them down honestly:

Filesystem isolation, because the user's uploaded file should be the only file the code can see
No network, because a model that decides to pip install something is a model that just gave a package registry your execution context
A wall clock timeout that kills the process, not one that asks it nicely
A memory ceiling, for the same reason as the timeout
Some way to get the plot back out, which sounds trivial until the container is correctly isolated and now you need a channel

All of this is available. gVisor, Firecracker, a locked-down Docker container with --network none and a cgroup limit, or one of the hosted sandbox APIs if you would rather rent it than run it. None of it is exotic. What I keep coming back to is that on the ChatGPT side, items 1 through 5 were a checkbox in a form.

What it changed about my decision

I ended up not moving the assistant that used Code Interpreter, and moving two others that did not. That sounds like a compromise but it was actually the useful outcome, because it forced the question to be asked per capability instead of per assistant.

The move is worth it when the reason is that data cannot leave your machines, or when you want the model to still behave the same in five years regardless of what a pricing page says by then. It is not worth it when your real bill is engineering time. Two evenings rebuilding retrieval costs more than a year of Plus, and I say that as someone who spent the two evenings.

If you want to run the same audit against your own build rather than mine, the Muse Glimmer vs GPTs capability checker does exactly this: you tick which features your GPT actually uses, and it splits them into ports, rebuild, and blocked, with the reasoning shown for each. It also asks how much VRAM you have before it tells you anything encouraging, which I appreciated after being told by three separate blog posts that the model needs anywhere from 17 GB to 64 GB.

If I were starting the weekend again, I would skip the benchmarking entirely on day one and just list what my assistant uses, marking each feature as code or as operations. The model comparison I spent most of Saturday on turned out not to be the comparison that decided anything.

Every Pokopia guide names the habitat. None of them prices it

Jim L — Tue, 11 Aug 2026 05:27:50 +0000

Shellder lives in two Bubbly Basin habitats. One of them costs 2 material units to build. The other costs 6. Serebii, Nintendo Life and game8 all tell you where Shellder spawns, and I read all three on 11 August 2026 without finding a single unit cost between them.

That is the gap. Location data is everywhere. What you actually spend to reach that location is nowhere, and it is the number that decides your build order.

The numbers that fall out once you price everything

There are 50 Pokemon in Bubbly Basin. Phione and Manaphy do not come from a habitat at all, which leaves 48 that do.

29 of those 48 come from exactly one habitat. For most of the Basin there is no route to compare, no saving to hunt, and nothing to optimise. The advice "pick the cheaper habitat" is unactionable for 60% of the roster, which is worth saying plainly rather than burying under a comparison table that mostly has one row.

The choices that do exist are small and clustered. Shellder has the biggest spread at 4 units between its cheapest and dearest source. Corphish and Corsola are next at 3. After that the gaps stop mattering.

Four species tie for cheapest at 2 units: Corphish, Crawdaunt, Shellder and Totodile. The dearest is Starmie at 13, via Mermaid's Gym, and nothing else spawns it. If Starmie is on your list, that 13 is not negotiable, and it is better to plan around it than to discover it halfway through a build.

Why the value ratio and the unit count disagree

The habitat table on the same site ranks habitats by Pokemon per distinct material type, and it is explicit that four units of one material cost it nothing. That is the correct measure when you have a full inventory and you are deciding what to spend it on.

It is the wrong measure when you are the one out gathering, because what you collect is units, not categories.

The two rankings pull apart at both ends. Bubbly bathtub asks for the fewest units in the Basin, 2, and comes 20th of 36 on the value ratio. Basin tall grass tops the ratio at 4.00 and sits 16th on units. Neither ranking is broken. They answer different questions, and which one you want depends entirely on whether your bottleneck is inventory or gathering time.

The thing neither measure can see

None of this knows where the materials are found. The dataset has habitat costs and no gathering locations in it.

That matters more than the unit gaps do. A 2-unit habitat whose one material only appears in a far corner of the map can easily take longer than a 5-unit habitat built from things lying around your base. Until someone maps material spawn points, unit cost is a proxy for effort rather than a measure of it, and anyone telling you otherwise has not gone and collected them.

I would rather say that out loud than let a tidy sorted table imply a precision it does not have.

How to use it anyway

Work backwards from the species you actually want. Look up each one, note whether it has a choice at all, and only spend thinking time on the handful with a real spread. Then total the materials for every habitat on your list at once rather than building them one at a time, because the overlaps are where the genuine savings are, not in swapping a 3-unit habitat for a 2-unit one.

The full table, all 50 species with their source habitats priced in total material units and sortable by cheapest source or biggest saving, is at Pokemon locations in Bubbly Basin. It also flags which species have no alternative, so you can stop looking for a cheaper route that does not exist.

Palworld's Cake recipe lists 5 Flour, and Flour is not something you can pick up

Jim L — Tue, 11 Aug 2026 05:24:38 +0000

The Cake recipe looks like five ingredients. Four of them are, in the sense that you can go out and end up holding one. Flour is not. Flour comes out of a Mill at 3 Wheat to 1, so the line that reads "Flour x5" is really "Wheat x15", and that single indirection is most of the reason Cake feels more expensive than the recipe card suggests.

Here is the whole bill for one Cake:

Ingredient	Per cake	Where it comes from
Flour	5	Milled from 15 Wheat, 3 to 1
Red Berries	8	Berry Plantation, or gathered wild
Milk	7	Mozzarina on a Ranch
Egg	8	Chikipi on a Ranch
Honey	2	Beegarde on a Ranch

Total raw Wheat: 15. Mill conversions: 5.

The part nobody puts in the recipe box

Three of those five lines are Ranch output. Milk, Egg and Honey cost you no materials at all, which is why they look free in a recipe listing. What they actually cost is three Ranch slots and the Pals to fill them, and they arrive on their own schedule rather than when you want them. If you are short on Cake it is usually not because you ran out of Wheat, it is because one of the three Ranch lines is not running.

The Wheat itself has an escape hatch worth knowing about. You can grow it on a plantation, or you can buy it from a Wandering Merchant and skip the plantation entirely. Either way it is the only ingredient that still needs processing after you have it, at 10 workload per Mill conversion.

Cooking is a Cooking Pot or Electric Kitchen at 2000 workload with a Kindling Pal assigned.

What you need unlocked before any of this matters

Cake recipe: Technology level 17.
Breeding Farm: Technology tier 19, plus 2 Ancient Technology points. Build cost is 10 Wooden Board, 20 Stone, 50 Fiber.
Mill: needed for the Flour step, 3 Wheat to 1 Flour.

One honest gap in that list. The Breeding Farm workload figure reads as 15000 to me, and an independent check of the same page read it as 150. Two orders of magnitude apart on a number I only have one page for, so I left it out rather than pick a side.

How many cakes does a mutation hunt cost

This is the question everyone actually arrives with, and it is not answerable. Not because the arithmetic is hard, but because half of it has never been published.

One breeding cycle consumes one Cake, so cakes are roughly equal to cycles. That figure is single-sourced, and both Game8 and the Cake and Breeding Farm pages on palworld.wiki.gg omit it entirely, so it is not a settled number either.

What nobody publishes is how many cycles a mutation takes. The rates I found range from 1% to somewhere in the 5 to 10% band per egg. That is a five to tenfold spread, and multiplying an unknown by a lightly-sourced known does not produce an answer, it produces a number that looks like one.

Cycle length has the same problem. One source puts a cycle at "roughly two to four hours of in-game time depending on the parent Pals rank". That is single-sourced and wide enough that cake-per-real-hour is not worth computing. The Breeding Farm page omits duration altogether.

So the useful version of the question is not "how much will my mutation hunt cost", it is "how much Wheat do I need for the next 25 cakes", which is 375, plus 200 Red Berries and three Ranch lines that have been running long enough to bank 175 Milk, 200 Egg and 50 Honey.

If you want the multiplication done for a batch size you pick, with every quantity attributed to the page that stated it, the Palworld cake cost calculator runs the whole chain including the Mill conversions. Nothing on it is estimated, and the figures that are single-sourced are labelled as such rather than presented alongside the corroborated ones.

A 60-inch round table seats 8. It also seats 10. Both numbers are correct

Jim L — Tue, 11 Aug 2026 05:21:24 +0000

Book 13 tables for 100 wedding guests and you finish with four spare seats. Book 10 and you finish with a room where nobody can slide a chair under the table. Both counts describe the same table, the 60-inch round, and both come from companies that rent it out for a living.

I went looking for the discrepancy expecting to find one supplier being sloppy. That is not what is going on. The suppliers are answering different questions and none of them says which question they answered.

The four questions hiding inside one number

How the table is laid. Ten covers fit on a 60-inch tabletop. Ten full covers, meaning charger, side plate and three glasses, do not. One rental firm states this outright: with formal place settings you cannot fit more than eight. If your caterer is doing a charger and a wine flight, your table is an eight whatever the capacity chart says.

Whether the chairs tuck in. At ten, chairs stop sliding under the table. This is the detail that decides whether a table feels crowded, and it happens long before anyone counts the plates. Nobody at the wedding will say "this table is over capacity". They will say they had to shuffle sideways to let someone past.

How the food arrives. A plated dinner is costed at roughly 24 inches of table edge per guest. Family-style service, where platters live on the table, is quoted nearer 18. Same supplier, same table, different answer, because the platters need the middle and the plates need the edge.

Who is answering. One of the sources I checked was a furniture retailer describing home dining. It starts a 48-inch round at four people. Event rental firms put the same table at six to eight. Neither is wrong. A dining room is not a marquee, and the retailer never claimed otherwise.

The page that could not agree with itself

The clearest illustration was a single rental listing that manages three different numbers on one page. The heading says "Seats up to 10 adults". The body says it "will seat up to 8 adult guests comfortably". A photo caption underneath says "up to 10 chairs".

That is not sloppiness worth mocking. It is what happens when comfortable capacity and physical capacity get written by different people for the same product. It does mean that any single number you are quoted should be treated as the opening of a conversation with your venue rather than a specification.

What this does to your 100-guest count

Table	Comfortable	Maximum	Tables for 100
60 inch round (5 ft)	8	10	13 to 10
72 inch round (6 ft)	10	12	10 to 9
48 inch round (4 ft)	4	8	25 to 13
8 ft banquet	8	10	13 to 10
6 ft banquet	6	8	17 to 13

One note on the banquet rows. A 6 ft table gets quoted as "6-8", and the one source that spells out the arrangement puts three chairs down each side plus one at each end. If you are not seating the ends, and plenty of couples do not, it is a six.

The 66-inch round is missing from that table on purpose. Suppliers disagreed on it without a majority, and averaging numbers nobody stated felt worse than leaving a gap.

Room size is worth a sanity check rather than a decision: 100 guests with a dance floor lands somewhere around 1,300 to 1,850 sq ft. Venues quote their own capacity, so use this to notice a room that is obviously too small, not to overrule the venue.

Round up, on purpose

Whichever number you land on, take the comfortable one rather than the maximum. Guest counts move in the last fortnight and they mostly move up. A layout with zero slack turns one late acceptance into a new table, new linen, and a chart that has to be redrawn after it went to the printer.

The count is also the easy half. Knowing you need ten tables tells you what to book. It does not tell you who sits where, and that is the part that keeps changing after the stationery is ordered. In r/weddingplanning threads about presenting a seating plan, one recurring argument for individual escort cards over a single printed chart is that a card can be quietly pulled when somebody cancels, while a chart has to be redone. That is one commenter in one thread rather than a survey, but the underlying worry is real: the question is rarely "can I edit the plan", it is "does this edit force a reprint".

If you want to run your own guest count and table size rather than borrow mine, the tables for 100 guests calculator does the arithmetic and shows how many spare seats each layout leaves you, with every capacity figure attributed to the supplier who published it.

I Kept Missing a Game Event by 40 Minutes, So I Built a Timezone-Aware Countdown For It

Jim L — Thu, 06 Aug 2026 04:59:08 +0000

Forza Horizon 6 has a weekly event called the Treasure Hunt: photo clues drop you into a hidden car reward, and the whole thing resets every Thursday at 14:30 UTC. Simple enough, except I'm in Australia, the reset time is written in UTC everywhere the game and its community talk about it, and daylight saving shifts my offset from UTC twice a year. I missed the reset window three weeks running, not because the game is hard, but because I did timezone arithmetic badly at 11pm.

The usual fix people post in the FH6 subreddit is "just remember it's Thursday afternoon UTC." That works until DST flips in either your hemisphere or the UK's (the game's scheduling appears to follow UK server time, which itself observes BST/GMT), and now your mental math is off by an hour and you don't find out until the treasure hunt map is already blank.

So I built a small countdown page: fh6treasurehunt.com/tools/reset-timer. It does three things I couldn't find bundled anywhere else:

Converts 14:30 UTC to your local time automatically, using Intl.DateTimeFormat with the browser's detected timezone rather than a hardcoded offset table, so it doesn't quietly break twice a year when DST changes.
Shows a live countdown, not just a static "resets Thursday" label, so you can tell at a glance whether you have 6 hours or 6 minutes.
States where the season rotation currently sits, since the treasure hunt content itself changes with the season and a bare countdown without that context is only half the answer.

The annoying part wasn't the countdown math, that part is a solved problem. It was building an archive to go with it. Once I had the timer, the obvious next question was "okay, but what about the hunt I missed two weeks ago." Most guide sites only ever show the current week, so I ended up building a searchable archive of past hunts alongside the timer, which turned out to be more work than the timer itself.

Small site, narrow job, but it's the kind of "I got annoyed enough to fix it myself" project that's more fun to build than anything I get paid for. If you've built something similarly single-purpose to fix your own recurring annoyance, I'd like to hear about it in the comments.

I Ran the Numbers on HKMC's 3% Annuity Discount Before Booking the Sales Appointment

Jim L — Wed, 05 Aug 2026 03:31:07 +0000

HKMCA is dangling a 3% premium discount if you book a sales appointment by August 31 and get your application in by September 30. Sounds like a nice little bonus until you sit down and work out what 3% actually means in dollars, because on the kind of premium people actually put into these annuity plans, it's not pocket change either direction.

I've been tracking Hong Kong's HKMC Annuity Plan on and off for about two years, mostly because my parents keep asking whether it's worth converting part of their MPF payout into one. The 3% discount promo is the first time HKMC has run a time-limited incentive like this on the plan, and it's pulling in a lot of "should I rush this" energy from people who otherwise weren't planning to touch the product this year.

Here's the math nobody spells out at the sales appointment. On a HK$500,000 premium, 3% is HK$15,000. On HK$2,000,000, it's HK$60,000. That's real money, but it's a one-time discount on an irreversible decision that locks your capital into a fixed monthly payout for the rest of your life, with no lump-sum exit once you're in. The annuity's actual value depends far more on your age, sex (payout rates differ), and how long you expect to live than on whether you caught a 3% early-bird window.

I built a small calculator that takes your age, sex, and intended premium and shows the exact discount amount alongside the plan's standard internal rate of return at different life expectancies, so you can see whether the 3% actually moves the needle versus just waiting for the next promo cycle (HKMC has run smaller ones before). https://www.lowrisktradesmart.org/en/tools/hkmc-annuity-discount-worth-it. Enter your numbers and it spits out both figures side by side.

A few things I noticed while building it:

The discount rate scales with premium size but the underlying monthly payout formula doesn't get any more generous. You're not getting a better annuity, just a cheaper entry ticket into the same one.
Deadlines matter more than the discount itself for some people. If you were already going to apply this year, the 3% is free money. If you weren't, don't let a promo talk you into an irreversible 15-20 year commitment you weren't ready for.
The break-even point (age at which the annuity starts winning over just keeping the cash in a term deposit or the Silver Bond) doesn't move much with a 3% discount. It shifts the number by maybe 1-2 years, not the 5+ years some sales pitches implied when I asked.

If you're on the fence, run your actual premium through the tool before the appointment. It takes less time than the meeting itself, and at least you'll walk in knowing whether you're chasing HK$15,000 or HK$150,000, and whether either number changes your answer.

I Killed My Subscription Price Because Nobody Buys a Monthly Plan for an Anniversary Gift

Jim L — Mon, 03 Aug 2026 21:36:29 +0000

I launched songmemento.com with a $19.99/month subscription as the only way to pay, and it took less time than I'd like to admit to realize that was the wrong model for what the product actually is.

The tool turns one specific memory into a custom AI-generated song: you answer three short questions (who it's for, the memory, the occasion), get a free ~15-second preview generated from your actual answers, then pay for the full track. The occasions people were describing in testing were things like a proposal, an anniversary, a specific birthday. Those are events that happen once or twice a year for any given person, sometimes once ever. Asking someone to commit to a recurring monthly charge for a gift they need exactly one time is a mismatch between the pricing model and the actual use case, and I built that mismatch myself by defaulting to "SaaS pricing" without checking whether this was actually a SaaS.

I switched to a one-off price of $1.80 per song, with a $13 bundle (about $1.30/song) for anyone making more than one, wedding favors or a batch of birthday gifts across a year. The subscription still exists but it's no longer the lead offer; one-off is what the checkout flow pushes toward now.

The engineering side of that pivot was smaller than the business-reasoning side, which is worth saying plainly: dropping a subscription-gate check and adding a single-purchase Stripe flow is a day of work, not a rebuild. The actual full track renders in roughly 60 seconds after purchase using the ACE-Step model on Replicate, and that part of the stack didn't change at all. What changed was entirely upstream: I'd built pricing around what's easy to bill (recurring revenue is nice on paper) instead of around when the customer actually has money-in-hand intent, which for a gift product is right at the moment of the occasion, not on a monthly cycle.

I'll be honest about where this still sits: real user numbers are near zero, this is a few-days-old build-in-public project, and I'm not going to pretend otherwise with fake testimonials or usage stats. The free preview is a real render of your own answers, not a stock demo, and that part I'll stand behind regardless of pricing. If you're building a gift or occasion-based product and defaulting to subscription pricing because that's what every SaaS starter template ships with, it's worth asking whether your actual purchase moment repeats monthly or not before you commit to that model.

I Skipped the YouTube Scraper and Made You Paste the Transcript Instead

Jim L — Mon, 03 Aug 2026 21:26:55 +0000

A friend sent me a 40-minute lecture recording two nights before her exam and asked if my quiz tool could just "pull the transcript" from the video URL. The honest answer was no, and after building the alternative, I don't think I want it to.

My first instinct when I started quizpaste.com was to build a YouTube scraper: paste a URL, hit the captions endpoint, extract the transcript, generate a quiz. I got as far as a working prototype using youtube-transcript-api before I stopped and thought about what happens six months from now when YouTube changes how captions are served, or rate-limits the endpoint, or the video is age-restricted, or the uploader disabled captions entirely. Every one of those breaks silently, and I'd be the one finding out from a support email instead of a test.

So I ripped it out. Instead, quizpaste just takes text. If you want a quiz from a YouTube video, you open the transcript panel under the video, click "Copy transcript," and paste the raw text into the same box you'd use for lecture notes. No API key, no scraping, no maintenance burden tied to a UI I don't control. It is a worse demo (you can't just drop a URL) and a more durable product.

The harder engineering problem turned out to be downstream of that decision, not upstream of it: making sure every question the model generates can actually be traced back to a sentence in whatever text you pasted, transcript or notes. The generation step asks the model for candidate question/answer pairs, but before anything reaches your screen, a second pass checks whether the answer text has a real match against the source: not a fuzzy vibe-check, an actual substring/near-match search against the original paragraph. If a candidate question doesn't clear that bar, it's discarded and never shown to you, quietly, no retry loop that eventually gives up and shows you something ungrounded anyway. That constraint is what makes the transcript-paste approach work at all: a hallucinated answer sourced from "general knowledge about the video" would be useless once you're staring at a flashcard with no way to check it.

The tradeoffs I made are honest ones. There's no account sync between devices right now, so if you generate a quiz on your laptop it doesn't follow you to your phone, and the free tier caps out at two generations per IP per day (that cap exists to keep the AI bill sane, not to push an upgrade, because there currently isn't a paid tier to push you to). Export is .tsv and CSV, Anki-importable, but there's no packaged .apkg file yet.

If you're building anything that ingests third-party platform content, I'd genuinely rather maintain a slightly worse first-run experience than own a scraper that breaks the moment someone else's frontend changes. Happy to talk through the citation-matching logic in more detail if anyone's solving a similar problem.

Why the #1 Model on the Benchmark Leaderboard Isn't the One I Reached for Most This Week

Jim L — Mon, 03 Aug 2026 01:41:23 +0000

I run a site that tracks which AI model is actually worth paying for, so I check the leaderboards more than most people would want to. Claude Opus 5 sits at #1 out of 215 models on the BenchLM.ai aggregate ranking this week, scoring 85.88 overall, with 96.0% on SWE-bench Verified and 79.2% on the harder SWE-bench Pro. Nothing else on the list is close on raw coding ability. And I still switched most of my own work this week to a model that ranks #4.

That model is GPT-5.6, or more specifically its cheapest tier, which OpenAI calls Luna. Sol, the flagship GPT-5.6 tier, ranks #4 overall at 81.46, with 88.8% on Terminal-Bench 2.1 (91.9% in its ultra mode) and 64.6% on SWE-bench Pro, a real gap behind Opus 5's 79.2%. So on the metric that supposedly matters most for a coding assistant, GPT-5.6 loses outright. I use it anyway for the bulk of my day.

Here's the part the leaderboard doesn't price in: what I actually do most of the time isn't a multi-file refactor or a long agentic tool-use chain. It's small, repetitive, low-stakes stuff. Rename a function across three files. Write a one-off script to reshape a CSV. Draft boilerplate for a new API route I've written thirty times before. For that category of work, the difference between a 96.0% and an 88.8% pass rate on some benchmark essentially never shows up, because the tasks aren't hard enough to separate the two models. What does show up is the bill.

Opus 5 is priced at $5 per million input tokens and $25 per million output tokens, and that's the only tier it comes in. GPT-5.6 splits into three: Sol at $5/$30, Terra at $2.50/$15, and Luna at $1/$6. Luna is roughly a fifth of what Opus 5 costs on the output side. Run enough of those small tasks through an API in a given week and that ratio adds up to real money, not a rounding error.

So my actual routing looks like this. Anything that's genuinely a production PR, a change that touches a lot of files with dependencies between them, or a long tool-use chain where a wrong early step compounds into a wasted afternoon, goes to Opus 5. I've watched Opus 5 hold context through longer agentic chains without losing the plot in a way GPT-5.6 sometimes does past a certain chain length, and for that kind of work the extra cost is trivial next to the time it saves. Everything else, the quick stuff, the stuff where being wrong costs me thirty seconds instead of thirty minutes, goes to Luna or Terra depending on how much I trust the task.

I'll admit the split isn't scientific. I haven't run a controlled study measuring exactly where the quality gap between Opus 5 and Luna starts to matter for my specific workload; I'm going on a few weeks of gut feel and a running mental tally of which model made me redo something. It's entirely possible I'm leaving quality on the table for some subset of "simple" tasks that are actually subtler than I've been treating them. But the leaderboard was never going to tell me that. It ranks models on a fixed set of hard problems, and most of what I actually type into a terminal on a Tuesday afternoon isn't one of them.

If you're trying to figure out your own routing instead of just picking whatever's #1, I wrote up the full breakdown, benchmarks, pricing tiers, and where each model actually wins, at openaitoolshub.org/en/blog/opus-5-vs-gpt-5-6, since both numbers move often enough that a single snapshot goes stale fast.

My browser build passed every test. Then it crashed on the first real upload.

Jim L — Sun, 02 Aug 2026 01:16:51 +0000

Why My Bongo Cat Drop-Rate Tool Refuses to Give You a Single Legendary Percentage

Jim L — Wed, 29 Jul 2026 05:32:16 +0000

I write small calculators for a Roblox fan-wiki as a side project, and the Bongo Cat drop-rate tool is the one where I almost shipped a number I couldn't actually back up. The naive version is easy: take the community-reported Legendary chest rate (roughly 1 in 500,000, since the developer has never published an official table) and divide it by 12, because there are 12 base-pool Legendary items, and print "1 in 41,666 chance of this specific hat." It reads clean. It's also fabricated precision, because nobody has published the individual weight on any of those 12 items, and averaging assumes they're evenly weighted, which is an assumption, not a fact.

So the tool only ever reports per-rarity-tier odds, never per-item. Common 90 percent, Uncommon 9.5 percent, Rare 0.49 percent, Epic 0.01 percent, Legendary about 1 in 500,000, as a tier, full stop. If a player wants a specific Legendary, the honest answer is "somewhere between 1 in 500,000 and 1 in 6,000,000 depending on how the game actually weights them, and nobody outside the dev team knows which end it's closer to." That's a worse-feeling answer than a clean percentage. It's also the true one.

The other thing I left alone on purpose: add up the five community-reported rarity percentages and you get roughly 100.0002 percent, not a clean 100. That's rounding noise from wherever the original community data was collected, not my error. I could silently normalize it to exactly 100 and nobody would notice. I didn't, because doing that would make the numbers look more precise than the source data actually is, and the entire point of the tool is not doing that.

Chest cadence is the third assumption I left exposed instead of hardcoding. The community estimate is roughly one chest per 30 minutes of active keyboard and mouse use, but the developer has never published the real cadence either, so the tool treats it as an editable input the player sets themselves rather than a baked-in constant.

None of this is complicated engineering. It's three small refusals: don't divide by an unknown weight distribution, don't silently normalize rounding noise, don't hardcode an unpublished rate as fact. The calculator itself is live at bongocat.wiki/tools/drop-rates if you want to see what "honestly uncertain" looks like as an actual UI instead of a caveat paragraph nobody reads.

I Needed a Signature Stamp by 9 AM. The Print Shop Wanted 3 Days.

Jim L — Mon, 27 Jul 2026 02:00:09 +0000

The stamp shop wanted 3 business days and $38 for a signature stamp I needed by 9am the next morning, for a stack of paper contracts a client's compliance team insisted on printing and physically signing. I called two more shops. Same answer: 2 to 3 days, because the die gets cut by hand and neither branch had my exact size in stock.

I ended up making one myself from my laptop instead, using an online stamp generator (stampmakertool.com) that lets you draw or upload a signature, pick a stamp style, and export a transparent PNG at print resolution. Four minutes, most of which was me redrawing my own signature three times because the first two looked like someone else forged it.

It's not a real rubber stamp, and I want to be upfront about that. If you need an actual embossed stamp for a notarized document or a company chop a bank teller can feel with their thumb, this doesn't replace that. It's a flat image you print or place digitally. For me it was fine: the client just wanted a scanned PDF back with a stamp graphic in the signature block, not a wet-ink original.

What I didn't expect was how often I'd reuse the file afterward. I've since used the same PNG on two invoice templates and one grant cover sheet, because once it exists as a transparent image, dropping it into a doc takes ten seconds instead of hunting down the physical stamp, finding the ink pad, and pressing it straight the first time.

If your stamp need is one-off and not legally binding (invoices, internal paperwork, personal projects) the online version is faster and cheaper than reordering the physical one. If it has to survive a notary or a bank counter, call the shop and budget the 3 days.