It is not the AI slop, it is the benchmark prepared and done by humans which people like you can't understand. You still keep posting slop comments without ZERO concrete argument.
And also, I'm not saying you said you skimmed my comments. It doesn't need to be said, it is obvious that you wrote those comments without opening the link by just reading other's comments. That's it!
Ok, even though "poorly written" is just your bias to me, at least you could provide some concrete critiques. It seems that you listened to the others, had the AI read the blog post, and asked it to write something concrete based on that.
> Or the point about "measuring cost honestly". It's not clear why you wouldn't be using the published rates and do the basic multiplication yourself. There's nothing subtle about this, and it doesn't need to a whole paragraph.
Because, while Opus provides cost in the API response, DeepSeek doesn't, but just token usage. So, cost is calculated based on used tokens for DeepSeek. We have added this section, because draft version of the post got feedback on this.
It's not too long for humans, but it seems that it's too long for you maybe because you don't know how to read :) You didn't finish it, so you assumed nobody could. Don't speak for all humans based on your own reading.
Haters like you, who skim other people's comments and pass them off as their own thoughts, are everywhere. I don't have time for it. Try you chance with other posts.
Nice try with the metaphor, but it is just useless. I'm pretty sure that you didn't event open the link, but just read the other comments, saw the word slop and wrote something to get attention. There are people like you everywhere. If you had actually read the post, you would point to a real problem in it. You can't, because you didn't read it.
@neetle I get the frustration, but reaching for "slop" as the default reaction to anything you find too long isn't all that natural. Happy to hear specific feedback on what didn't land, that's more useful to me than the label.
Zero engagement with anything the post actually says. You've spent more words performing your distaste than it would've taken to read the thing. Recycling slop as a catch all for "I didn't read it" is the real content free contribution here.
Fair on the length. The verification loop took DeepSeek from ~20 to ~80 on Web-Bench, matching Opus at ~7x less cost. Curious if the method holds up for you.
Yeah, you’re right. The most of the gain is from the execute tool (batching many steps in one call), not from CDP vs Playwright. If Playwright MCP added a similar sandboxed “run script that calls other tools” and the model used it the same way, token use and turn count would likely get much closer. So the win is API design (batching + scoping + lean tool defs), not the protocol. The post is about showing that this kind of design matters, we’re not claiming our stack is inherently lighter.
We ran the same verification task with Claude Code, same prompt, 3 runs per MCP. Browser DevTools MCP: ~330K tokens, 12 turns, ~2m45s. Playwright MCP: ~1.5M tokens, 48–52 turns, ~6m. So 78% fewer tokens, 76% fewer turns, ~57% faster. We compare task-level totals rather than single-turn context size, and the post explains the methodology and how we designed for fewer round-trips (execute tool, scoping). Link in the post.
AI can write code, but testing/debugging still needs humans. This MCP server gives AI a Playwright-powered browser with screenshots, console/network inspection, Web Vitals, ARIA/AX snapshots, Figma compare, stubbing, React component inspection, and OpenTelemetry tracing. Works locally and in production.
The Driflyte MCP Server exposes tools that allow AI assistants to query and retrieve topic-specific knowledge from recursively crawled and indexed web pages. With this MCP server, Driflyte acts as a bridge between diverse, topic-aware content sources (web, GitHub, and more) and AI-powered reasoning, enabling richer, more accurate answers.
Currently there is no CPU limit for any function running on local. Because MerLoc runs functions in embedded mode. But we are working on a solution to be able to run functions on your local Docker. Then you will be able to limit CPU and memory usages per function on your local and total limit will bound to your host machine CPU and memory limits.
This is Serkan. Co-Founder&CTO at Thundra, the company behind Sidekick.
Flight recorder is a very useful tool for profiling your apps running on JVM. But next generation debugging tools like Sidekick allows you to debug your Java applications without stopping at breakpoint (so it can be used even on production)
Sidekick
- gives you local debugging like experience with tracepoints (aka non-breaking breakpoints)
- And allows you to inject logs dynamically to anywhere on the fly without code change, rebuild and redeploy