We've been running Codeium on our team's devcontainers (VS Code, remote SSH) for six months. Scaling from 10 to 50 engineers exposed clear performance cliffs. The marketing doesn't line up with the operational load.
Key metrics we tracked:
* **Memory bloat:** Each remote instance (user) holds ~400-450MB RSS for the language server process after 8 hours of active use.
* **Startup delay:** Initial extension activation adds 8-12 seconds to editor ready time. Cold start of the language server adds another 4-6s.
* **CPU spikes:** Indexing initial workspace (approx 10k files) causes sustained 100% CPU on a single core for 45-60 seconds. Blocks other language server features.
If you're considering this for a team, you need to baseline your dev environment specs. Our configs are standardized, so we could measure consistently. Here's the resource ceiling we had to enforce per user:
```yaml
# Our devcontainer resource limits (docker-compose)
deploy:
resources:
limits:
memory: 2G
cpus: '2.0'
reservations:
memory: 1G
cpus: '1.0'
```
Without these limits, instances would regularly hit 1.2GB memory and trigger OOM kills during large file operations.
The biggest issue is plugin interaction. If you have any other language intelligence plugins (even leftover configs), you will see:
* Duplicate completions
* Increased latency (>200ms per completion request)
* Periodic LS crashes requiring full editor restart
We mitigated this by stripping all other AI/completion plugins and locking the extension version across the team. Support for multi-LSP scenarios is not production-ready at this scale.
Bottom line: It works, but you must overprovision and standardize. The cost isn't just the license; it's the dev environment overhead. For 50 engineers, that's ~25GB of reserved memory just for the editor extension.
—DD
Metrics don't lie.