prasoonds

I've used LLMs enough that I have a good sense of their _edges_ of intelligence. I had assumed that reasoning models should easily be able to answer this correctly.

And indeed, Sonnet and Opus 4.5 (medium reasoning) say the following:

Sonnet: Drive - you need to bring your car to the car wash to get it washed!

Opus: You'll need to drive — you have to bring the car to the car wash to get it washed!

Gemini 3 Pro (medium): You should drive.

--

But OpenAI 5.2 reasoning, even at high, told me to walk. My first instinct was, I had underspecified the location of the car. The model seems to assume the car is already at the car wash from the wording. GPT 5.x series models behave a bit more on the spectrum so you need to tell them the specifics. So I asked:

"I want to wash my car. My car is currently at home. The car wash is 50 meters away. Should I walk or drive?"

GPT 5.2 Reasoning (medium):

"Drive—your goal is to get the car to the car wash, and it’s only 50 meters, so a slow, careful drive is simplest.

One small optimization: if you’re worried about starting the car for such a short trip or you want to avoid idling in a line, you can walk over first to check if there’s a queue / if it’s open, then come back and drive the car over when it’s your turn."

Which seems to turn out as I expected.

Hey, I’m on mobile right now and can’t remember this off the top of my head. Will check and update in a few hours.

Hey, no. We are not dealing with raw card numbers. It’s just a layer on top of the existing stripe SDK that makes using stripe easier. PCI compliance does not kick in here.

haha yes, it’s definitely a bit of a silly name. The idea is you the user does not have to deal with the webhooks!

That’s a fair point. But of course, this library also helps with other matters - wallets, credits and a code as config based system which can be quite useful too.

And also, if you record all the webhooks events (and a backfill), that basically gives you your whole Stripe data available locally - I’ve actually put it to good use in diagnosing payment failure issues before.

Well it’s a silly name, yes. _You_ don’t have to deal with webhooks - it happens in the background and is taken care of by the library!

Great question. Basically, you would change your billing.config.ts and update the price.

Then, you run the `sync` command - it matches prices by a composite key: `productId:amount:currency:interval`. Since the amount has changed, it won't find a match for the old price. So, it will create a new price in Stripe and update the Price ID. Your new customers automatically get the new price in the Pricing Table component.

Your old subscriptions stay on the old price - which is still active in Stripe. We haven't added support for migrating these customers to the new price yet but it's in the roadmap!

I would like to add that we've tried making the porcelain / user API for the library to best fit today's commonly uses SaaS pricing models so most actions usually do what you would expect (like this price update) but, it's hard to strike a balance between customizability and the _just works_ factor.

Yes, this is one of the bigger use-cases for this library. Lots of folks want custom analytics on their Stripe data and this provides a nice way to do just that.

Let me know how you find it! Happy to implement any fixes and PRs welcome!

Hey Felix, yes you can.

This library is simply a wrapper around Stripe with easier implementation and some additional primitives (credits / wallets / real-time usage).

So, just as in Stripe, where you would make a new custom plan for, say, an enterprise use, simiarly here, you'd do the same.

Though, I will admit your `billing.config.ts` file will get pretty crowded...

I will think on it and try to come up with a more user-friendly UX for this use case.