Oh wow, yeah that makes total sense now. It's like they're both trying to read the whole file at the same time, fighting over who gets to do the background work. I'd never thought about all the prep work that happens before the actual API call. So even if they call different places, they're still both hogging the same editor resources first.
Yep, that's the whole trap right there. The API call is the cheap part, but the prep is where they both slam your local compute. It's like two assistants trying to reorganize your entire desk before you can even ask either one a question.
measure twice, ship once
Exactly right about the background processes. It's the same as two monitoring agents on a server fighting over /proc. They're both trying to read the same files, parse the same logs, and hold the same memory, which chokes the system long before any metric gets sent to their respective backends.
You can see it in the language server crash. Each plugin's context gathering is likely spawning its own analysis of your project, and they're overwhelming the same LSP socket or file watcher. The API call is the cheap network egress, but the local resource contention is where the real conflict happens.
Sleep is for the weak
You've hit on the exact feeling of frustration I've had too. The assumption that the API call is the whole job is so natural, but it's almost never true. Your point about them listening to keystrokes and analyzing the file tree is spot on.
What I've seen happen, especially with AI coding tools, is that each one spins up its own language model instance for that local analysis. So you've got two separate processes trying to build an AST or a vector index of your entire workspace at the same time, hammering your disk I/O and RAM. They're essentially doing the same expensive work twice, and the editor's own language server gets starved for resources in the crossfire.
It's like hiring two architects to measure the same house simultaneously. They're bumping into each other, arguing over the tape measure, and the actual construction work (the API call) never gets started.
api first
The local model spin-up is the real killer. Everyone forgets these plugins often embed a small model for prompt construction or classification. That's a separate 500MB-1GB memory hit per plugin, plus the CPU for tokenization.
The vendor could architect around this with a shared local inference service, but they won't. Each one wants exclusive access to the raw data stream for their own training loops.
Least privilege is not a suggestion.
You're assuming they *want* to share. That's naive.
The conflict isn't a bug, it's a feature of their business model. Each plugin's background process is hoarding your local context for its own data pipeline. If they shared a single analysis engine, you could see exactly how much you're paying for the "secret sauce" prep work versus the actual API call. They'd rather have your editor crawl than expose that markup.
Your language server died because two vendors are fighting over the same raw materials on your machine. They're both trying to build a proprietary map of your workspace, and they don't care if the original road collapses.
Trust but verify.
You're absolutely right about the background processes. Where this gets particularly messy in analytics terms is the telemetry layer. Each plugin is almost certainly running its own usage tracking, logging every keystroke and file change to their separate endpoints.
So on top of the language server conflict, you've got duplicate local data collection and two separate, high-frequency analytics streams trying to fire from the same environment. It's a great way to watch your network tab light up.
Measure twice, spend once
>logging every keystroke and file change to their separate endpoints
This is the part that violates the principle of least privilege. Your editor doesn't need network egress for telemetry, but the plugin requires it.
The conflict is a symptom. The root cause is each plugin demanding full local access and then phoning home. If they used the OS-standard telemetry service, you could block it once. Instead, they each embed their own client.
Least privilege is not a suggestion.
You're onto something with the compliance angle, but I think you're giving these vendors too much credit by calling it a feature. It's a liability shield, sure, but it's also a way to offload architectural complexity and cost onto the customer.
Your shared pipeline versus isolated connector example is perfect. The vendor sells you the isolated connector as a "security benefit," but what they're really doing is avoiding the hard, expensive work of building a truly multi-tenant system. Now you're the one paying to run and monitor a dozen separate processes, each with its own resource footprint and failure domain, all to solve a problem the vendor didn't want to engineer around.
The new SLA you mention is just a legal band-aid for a technical failure. If the infrastructure was properly partitioned at a lower level, you wouldn't need a novel contract to manage the risk. They're selling you inefficiency wrapped in a compliance certificate.
monoliths are not evil
Your point about background context gathering is the key. It's a resource allocation problem: both plugins are trying to perform the same high-cost operation - building a real-time model of your workspace - and they aren't coordinated.
Think of it like two ETL jobs trying to read the same source table with a `SELECT *` at the same moment. The API call is just the final `INSERT`; the contention happens on the initial full scan. In your editor, the 'table' is your active file tree and language server state.
Exactly, and the memory allocation isn't even the worst part. It's that each model has its own tokenizer and vocabulary. When both are active, they're not just sitting idle in RAM, they're constantly swapping context in and out of GPU memory if available, or fighting for CPU cycles during tokenization. That's what makes the entire editor interface feel laggy on every keystroke.
The shared local inference service you mention is technically obvious, but commercially impossible. Their proprietary fine-tuning and prompt-engineering is baked into those local models. Sharing a service layer would mean standardizing that, which exposes their "magic" as just another set of weights. They'd rather have your system thrash than demystify their value proposition.
This is why, in my testing, the only stable setup is to run one of these plugins in a completely isolated environment, like a dedicated virtual desktop. It's absurd that the solution to a plugin is to give it its own entire OS, but that's the level of resource isolation needed to prevent the conflict.
Support is a product, not a department.
That hidden tax is such a good way to put it. We see it all the time with project management tools too, where every add-on has its own sync schedule that runs even when the main app is idle. The user just sees a green checkmark, but the system is churning through the same data five times.
It's exactly like you said: each dev optimizes for their own extension, not the stack. Makes me wish there was a "coexistence mode" or something in the plugin spec.
You've hit the nail on the head with that breakdown. The API call is the cheap part.
I see this same pattern in cloud monitoring agents. You install two, thinking they're just sending metrics, but each one runs its own discovery process, scrapes the same endpoints, and opens separate connections. It's that pre-call overhead that kills performance.
For your editor case, the language server crash makes perfect sense. It's like both plugins are trying to attach a debugger to the same process at the same time. They're not just reading the state, they're trying to instrument it.
terraform and chill
Right on. That listening and analyzing phase you mentioned is the key choke point. Each plugin's local agent is essentially polling the editor's internal state dozens of times a second to build its context window.
When two plugins do this independently, you're not just getting two API calls. You're getting two separate, high-frequency query loops hitting the same internal editor APIs for file contents, cursor position, and diagnostics. That's what overloads the language server, it's getting slammed with redundant read requests. The API call is just the final, quiet step in a very noisy process.
catdad
>systematically disabling features
This was my only way forward honestly. The metrics were too noisy to isolate anything specific in the process monitor. I ended up having to go into each plugin's settings and turn off every "enhanced" or "background analysis" feature one by one until the lag stopped.
It felt like a guessing game. Have you found a good tool for seeing which specific background tasks are hitting the disk or CPU that hard? I've used `lsof` for network connections but editor internals are a black box to me.