seanw265

I don't see bespoke software as a viable alternative because probing for vulnerabilities is both getting cheaper by the day, and also massively parallelizable.

Someone will inevitably spin up a large swath of agents running an abliterated pareto curve model and point them at the internet.

Not to mention your bespoke tool is likely way less hardened than the existing player in the space.

The tradeoff is that you become your own ops team and need to monitor and respond to cves in real time.

Thanks for checking out Easel! And congrats on your app's success.

Out of curiosity, would a $10/month plan with $10 in included usage make Easel more attractive for you? This is really useful feedback as we're figuring out our pricing.

And yes, we have first-class support for Next.js on Easel. We support App Router, Pages Router, SSR, ISR, Server Actions, etc. natively without an adapter.

I'd love to hear how it goes with your portfolio and side projects. If you run into any issues deploying them, please let me know and I'll be happy to help.

Make sure you're taking full advantage of the CDN cache. Cache hits should help reduce your active cpu, isr reads, and origin transfer, although they won't reduce CDN requests.

When you say Vercel's paid plan is too expensive, is the $20/month starting price itself the issue, or are you expecting your usage to push the bill higher than that?

For context, this is almost exactly what I'm trying to solve with Easel.sh (https://www.easel.sh). We're building a Vercel-compatible hosting platform, but with a lower cost structure because we operate much of the infrastructure ourselves rather than being built on top of AWS like Vercel.

Interesting read. Text rendering techniques have always fascinated me.

I'm a bit confused because at some points it seems like the author is conflating "tessellation" and "Rive". Are they the same thing? As an uneducated reader, my understanding would be that Rive is an implementation of a renderer using the tessellation approach. But surely a generic tessellation approach could support perfect arbitrary transformations even if Rive doesn't?

Maybe there's something I'm missing.

Also, a nitpick: in the "head to head" section, the author highlights Slug's better performance in green for the entries that it wins (or ties). For the sake of fairness, shouldn't we highlight the winners in every category? Surely Rive's "low" memory usage beats Slug's "moderate"?

Your browser's network fingerprint has likely already been validated as not-suspicious traffic. Your curl instance has a different fingerprint and reads as more suspicious. This is Cloudflare working as intended.

We have a similar set of checks on https://www.easel.sh.

I take some issue with that testing methodology. It seems to me that you're conflating the model's performance with the reliability of whatever provider you're using to run the benchmark.

Many models, especially open weight ones, are served by a variety of providers in their lifetime. Each provider has their own reliability statistics which can vary throughout a model's lifetime, as well as day to day and hour to hour.

Not to mention that there are plenty of gateways that track provider uptime and can intelligently route to the one most likely to complete your request.

Kimi K2.6 also released today. I think it's fair to compare the two models.

Qwen appears to be much more expensive:

- Qwen: $1.3 in / $7.8 out

- Kimi: $0.95 in / $4 out

--

The announcement posts only share two overlapping benchmark results. Qwen appears to score slightly lower on SWE-Bench Pro and Terminal-Bench 2.0.

Qwen:

- Teminal-Bench 2.0: 65.4

- SWE-Bench Pro: 57.3

Kimi:

- Terminal-Bench 2.0: 66.8

- SWE-Bench Pro: 58.6

--

Different models have different strong suits, and benchmarks don't cover everything. But from a numbers perspective, Kimi looks much more appealing.

I'll piggyback on this to highlight Refactoring UI as well. It's an ebook by Adam and Steve, though I'm not sure if it's technically part of Tailwind Labs or not.

This book taught me so much about modern UI design. If you've ever tried building a component and thought to yourself, "hmm something about this looks off," you might benefit from this book.

These days some of the examples might be a little bit dated (fashions come and go), but the principles it teaches you are rock solid.

It's always up to the reader to determine which biases they themself care about.

If you're wondering at what point "we" as a collective will stop caring about a bias or set of biases, I don't think such a time exists.

You'll never get everyone to agree on anything.

I’d argue the goalposts have moved substantially over the past decade. The LLMs we casually use in ChatGPT today would have been described as AGI by many people 15, 10, maybe even 5 years ago.

This is not what the article says at all.

The article is about the constraints of computation, scaling of current inference architecture, and economics.

It is completely unrelated to your claim that cognition is entirely separate from computation.

I tend to agree. Cloudflare and Vercel were able to mitigate in the form of WAF rules, but it's not immediately clear what a user or vendor can do to implement mitigations themselves other than updating their dependencies (quickly!).

IMO the CVE announcement could have been better handled. This was a level 10. If other mitigations can are viable and you know about them, you have a responsibility to disclose them in order to best protect the safety of the billions of users of React applications.

I wonder how many applications are still vulnerable.

FWIW it looks like OpenRouter's two providers for this model (one of whom being Deepseek itself) are only running the model around 28tps at the moment.

https://openrouter.ai/deepseek/deepseek-v3.2

This only bolsters your point. Will be interesting to see if this changes as the model is adopted more widely.

Thanks for the thoughtful reply. Best of luck!

After reading the post I kept thinking about two other pieces, and only later realized it was Taylor who had submitted it. His most recent essay [0] actually led me to the Commoncog piece “Are You Playing to Play, or Playing to Win?” [1], and the two together felt directly relevant here.

Sometimes people end up creating a kind of sub-game they can “win” (in this case, running a studio without using or promoting AI) even if it means losing the actual game that determines whether the business survives. The studio here is turning down all AI-related work, and unsurprisingly the business is now struggling.

I’m not saying the underlying principle is right or wrong, nor do I know the internal dynamics and opinions of their team. But in this case the cost of holding that stance doesn’t fall just on the owner, it also falls on the people who work there.

Links:

[0] https://taylor.town/iq-not-enough

[1] https://commoncog.com/playing-to-play-playing-to-win/

Stripe billing definitely leaves something to be desired and agree that a layer on top can improve the DX tremendously.

What differentiates you from competitors like Lago and Autumn?

If they are serious they should realize that "80% accuracy" is almost meaningless for this kind of classifier. They should publish a confusion matrix if they haven't already.

I haven’t tried it myself, but if you’re asking specifically about the human models, the article says they’re not generating raw meshes from scratch. They extract the skeleton, shape, and pose from the input and feed that into their HMR system [0], which is a parametric human model with clean topology.

So the human results should have a clean mesh. But that’s separate from whatever pipeline they use for non-human objects.

[0]: https://github.com/facebookresearch/MHR

Aha! Now I see I'm talking to the expert on the topic ;) Thanks for the link. I'll check this out.

Doable for http and https, but if you're running it in a browser environment, you'll eventually run into issues with CORS and other protocols. To get around this you need a proxy server running elsewhere that exposes the lower layers of the network stack.

Very cool! I'm curious as to how it compares with WASIX in terms of both compatibility and performance.

Also tangentially related: I'd love to see a performant build of Node.js compatible with this runtime (or really any flavor of WASM), but I think you'd run into the same issues that I have with WASIX. Namely build headaches, JIT, and wasm(-in-wasm) support. I'd explore it myself but I've already sunk way more time than is reasonable on that endeavor.

The designer obviously knows a thing or two. I enjoyed the fun presentation that others seem to dislike.

Where I ran into trouble was the readability of the annotations on the visuals. The tiny font combined with the low contrast was too much for me. I found myself squinting and trying to get close to my monitor. Eventually I had to move on, even though I was enjoying the content.

I’ve got a random subdomain hosting a little internal tool. About twice a year, Google Safe Browsing decides it’s phishing and flags it. Sometimes they flag the whole domain for good measure.

Search Console always points to my internal login page, which isn’t public and definitely isn’t phishing.

They clear it quickly when I appeal, and since it’s just for me, I’ve mostly stopped worrying about it.

I suspect you haven't tried a modern mid-to-large-LLM & Agent pair for writing code. They're quite capable, even if not suited for all tasks.

Living life on the edge, huh?

Sometimes I notice myself go a bit too long without a commit and get nervous. Even if I'm in a deep flow state, I'd rather `commit -m "wip"` than have to rely on a system not built for version control.

Very cool. I've spent quite some time working on compiling Nodejs for WASIX. Not an easy task.

Would love to see this open sourced at some point.

If the agent only needs the filesystem then probably. If it needs to execute code then things get flaky. The WASM/WASI/WASIX ecosystem still has gaps (notably no nodejs).

Containers might be fine if you’re only sandboxing filesystem access, but once an agent is executing code, kernel-level escapes are a concern. You need at least a VM boundary (or something equivalent) in that case.

I'm still not sold on liquid glass as a whole. It can be quite beautiful, but in the demos provided (and even in Apple's promotional materials) I think readability of UI elements suffers tremendously.

That said, I've seen many attempt to recreate the effect on web but you've outdone them all. The variety and mathematical modeling of edge shapes elevates this implementation above the rest.

If you decide to continue with this, I would love to see:

1. chromatic aberration along displaced areas

2. higher resolution in the refraction

Many people discussing performance issues but this runs like butter on my M3 Pro.