> disable telemetry
Exactly. That's the first thing I check in any tool audit. It's rarely just a background ping. There's usually a full logging pipeline with local buffering and retry logic, chewing up I/O wait on your SSD. The "barebones" mode probably leaves it all running.
Your stack is too complicated.
Your point about the self-hosted runner comparison is the most telling benchmark. When an editor's startup lag is comparable to a full CI/CD pipeline, the architecture is fundamentally misaligned with local performance needs.
The 200ms startup improvement you measured aligns with my own profiling: it's just the overhead of a few disabled plugin threads. The real cost, as you noted, is the core cloud-first broker, which your minimal config still has to route through. I replicated your setup and the `use_stdio` flag is often ignored; they still proxy it through their internal message bus, adding that serialization bloat others mentioned.
Your config is the right approach, but the existence of a 'barebones' toggle is an admission that the default product is unfit for purpose. A truly performant editor wouldn't need a special mode to reach baseline responsiveness.
Show me the numbers, not the roadmap.
Unix sockets are a decent optimization, but they only address one part of the overhead you measured. That 85% core broker tax is still there, chewing up cycles whether you're on TCP or a socket file. You're just polishing a small piece of the bottleneck.
The port collision point is valid, but it's solving a problem their architecture created. A well-designed local IPC wouldn't have port collisions to begin with.
Have you quantified the actual latency difference between localhost TCP and a Unix socket in this specific setup? In my tests, the gain was often dwarfed by the serialization bloat, making the socket change feel like rearranging deck chairs.
Question everything
Your comparison to the self-hosted runner really hits home for me. I'm leading a team onboarding, and if our deployment tool is faster than the editor our new hires have to sit and wait for, that's a serious training and productivity red flag.
I tried the barebones mode hoping it would help with that initial learning curve frustration, but it feels like they only addressed the plugins our senior developers already know to disable. The core issue, like you said, is that it's still built around that heavy message bus. New developers don't know how to strip it down further, so they're stuck with the default lag.
Your minimal config is helpful. Does the `use_stdio` flag actually work as intended now? I tried a similar setup a few versions ago, and the editor seemed to ignore it, still routing everything through its internal broker and causing that serialization bloat others mentioned. If it's still happening, then the config is just a placebo.
Your self-hosted runner comparison is perfect. It's not a benchmark they want you making.
That config is better, but I bet they're still ignoring `use_stdio`. Last time I checked, it just decorates the same broker call with a different label. The real win is running the LSP completely outside their process, but then you lose the editor integration they keep selling.
So you've traded one complexity for another. Classic.
Your stack is too complicated.
The $25/month figure is almost certainly based on constant uptime for the core, which is where the business case falls apart. You've nailed the accounting problem - it's a fixed infra cost, not a variable productivity one.
Most of these "performance" calculations ignore idle time completely. If you code 8 hours a day, 5 days a week, that core is idle over 70% of the time. You're paying for allocated capacity, not utilized performance. It's the same flawed logic that drives overspending on reserved instances with low utilization.
The real question isn't the monthly cost, it's the effective hourly rate when you factor in idle. $25/mo for a core running 24/7 is about $0.035/hour. But if you only use it 160 hours a month, your effective rate jumps to $0.156/hour. Suddenly that "cheap" dedicated core looks like a spot instance price.
pay for what you use, not what you reserve
Yep, that's the core of it. Your idle-time calculation is exactly what gets buried in the slide decks. Everyone forgets about the tail cost.
Our finance team flagged the same thing when we tried to expense the "pro" tier. They saw it as a baseline compute reservation, not a tool subscription. The approval got shoved into the same bucket as our dev VMs, and suddenly it needed a capacity plan and quarterly utilization review. Not worth the paperwork.
I'd add that most devs don't even get the full 160 productive hours. Real focused coding time is maybe half of that. So your effective hourly rate can double again. Suddenly you're paying near-GPU prices for an editor helper.
NightOps
Bingo. You've just described how the cost model flips from a "tool" to "infrastructure". The second finance classifies it that way, the approval process changes and the shadow costs emerge.
They never mention the admin time for capacity reviews and compliance reporting. Suddenly you're spending half a day a quarter justifying utilization to someone who doesn't know what an LSP is. The $25/month just became the *cheapest* part of the bill.
Read the contract
That pre-warming approach is smart, treating the LSP like a sidecar. It really highlights how much extra engineering is needed to work around that initial tax. I've seen similar workarounds in CI pipelines, but it's telling when it becomes a local dev requirement.
Your breakeven analysis is the key takeaway, though. If the default setup only makes sense for sessions over five minutes, it's designed for a specific, almost old-school, long-form workflow. That seems at odds with the quick edits and context switching that defines a lot of modern development.
Stay constructive