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.

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.

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.

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

I've linked a demo app linked in the post to try this out:

<https://snw-test.vercel.app>

It uses Clerk for auth and Clerk seems to be having problems:

<https://downdetector.com/status/clerk-inc/>

So if you're having any issues loading the app, you may have to wait a bit!

Here's a demo video: https://youtu.be/cyEgW7wElcs

Why is this useful? (1) You don't have to figure out which webhooks you need or write listeners for each one. The library handles all of that. This follows the approach of libraries like dj-stripe in the Django world (https://dj-stripe.dev/). (2) Stripe's API has a 100 rpm rate limit. If you're checking subscription status frequently or building internal tools, you'll hit it. Querying your own Postgres doesn't have this problem. (3) You can give an AI agent read access to the stripe.* schema to debug payment issues—failed charges, refunds, whatever—without handing over Stripe dashboard access. (4) You can join Stripe data with your own tables for custom analytics, LTV calculations, etc.

It creates a webhook endpoint in your Stripe account to forward webhooks to your backend where a webhook listener stores all the data into a new stripe.* schema. You define your plans in TypeScript, run a sync command, and the library takes care of creating Stripe products and prices, handling webhooks, and keeping your database in sync. We also let you backfill your Stripe data for existing accounts.

It supports pre-paid usage credits, account wallets and usage-based billing. It also lets you generate a pricing table component that you can customize. You can access the user information using the simple API the library provides:

  billing.subscriptions.get({ userId });
  billing.credits.consume({ userId, key: "api_calls", amount: 1 });
  billing.usage.record({ userId, key: "ai_model_tokens_input", amount: 4726 });

Let's see how it works with a quick example. Say you have a billing plan like Cursor (the IDE) used to have: $20/mo, you get 500 API completions + 2000 tab completions, you can buy additional API credits, and any additional usage is billed as overage.

You define your plan in TypeScript:

  {
    name: "Pro",
    description: "Cursor Pro plan",
    price: [{ amount: 2000, currency: "usd", interval: "month" }],
    features: {
      api_completion: {
        pricePerCredit: 1,              // 1 cent per unit
        trackUsage: true,               // Enable usage billing
        credits: { allocation: 500 },
        displayName: "API Completions",
      },
      tab_completion: {
        credits: { allocation: 2000 },
        displayName: "Tab Completions",
      },
    },
  }

Consume code would look like this:

  await billing.credits.consume({
    userId: user.id,
    key: "api_completion",
    amount: 1,
  });

  await billing.credits.topUp({
    userId: user.id,
    key: "api_completion",
    amount: 500,     // buy 500 credits, charges $5.00
  });

This would be a lot of work to implement by yourself on top of Stripe. You need to keep track of all of these entitlements in your own DB and deal with renewals, expiry, ad-hoc grants, etc. It's definitely doable, especially with AI coding, but you'll probably end up building something fragile and hard to maintain.

This is just a high-level overview of what the library is capable of. It also supports seat-level credits, monetary wallets (with micro-cent precision), auto top-ups, robust failure recovery, tax collection, invoices, and an out-of-the-box pricing table.

I vibe-coded a little toy app for testing: https://snw-test.vercel.app. There's no validation so feel free to sign up with a dummy email, then subscribe to a plan with a test card: 4242 4242 4242 4242, any future expiry, any 3-digit CVV.

Screenshot: https://imgur.com/a/demo-screenshot-Rh6Ucqx

Feel free to try it out! If you end up using this library, please report any bugs on the repo. If you're having trouble / want to chat, I'm happy to help - my contact is in my HN profile.

Comments URL: https://news.ycombinator.com/item?id=46963177

Points: 66

# Comments: 30

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.

If you are not a backwater that doesn't get any travelers, you should cater to tourists who, as a rule, do not speak your language. Even those tourists who do speak a few phrases will absolutely be unable to understand something as complex as a the train spilling up into two before going to the Airport.

> Why should anywhere cater to my failure to learn their language and systems? It’s nice if they do but I don’t expect it.

I certainly don't see this attitude from Germans in Spain.

However, at least for my use-case, this is a very infrequent problem. So, a monthly subscription and the security risk wouldn't be worth it. Though I'm certain there are people who work with files all day and for them, this might be god-send!

> That’s not a marginal improvement; it’s a different way of building classifiers.

They've replaced an em-dash with a semi-colon.

I’ve been using it for personal projects but surely large companies have _some_ way they’re trying to prevent security issues? For instance, I remember one company I worked at blocked us from installing VSCode extensions.

Comments URL: https://news.ycombinator.com/item?id=43579844

Points: 4

# Comments: 0

Sonnet 3.6 (the 2022-10-22 release of Sonnet 3.5) is head and shoulders above GPT-4 and anyone who has been using both regularly can attest to this fact.

Reasoning models do reason quite well but you need the right problems to ask them. Don't throw open-ended problems at them. They perform well on problems with one (or many) correct solution(s). Code is a great example - o1 has fixed tricky code bugs for me where Sonnet and other GPT-4 class models have failed.

LLMs are leaky abstractions still - as the user, you need to know when and how to use them. This, I think, will get fixed in the 1-2 years. For now, there's no substitute for hands on time using these weird tools. But the effort is well worth it.