https://public.meshllm.cloud/ - This should give the status of their public mesh. On an average I notice around 10 nodes on their public mesh serving various SLMs. You can use meshllm to share your GPUs like SETI@Home. Wondering how security is handled at a random node.
It is the OAI ExploitGym agents (on GPT 5.6-Sol with guardrails turned off) that escaped the sandbox, found a zero day in HF production dataset and exploited it.
The other day I was trying to prevent my pi.dev coding harness to expose my API keys in the env variable to the remotely hosted LLM. This is a chicken and egg problem. Without the API keys the underlying commands run by agents don't work. I notice that many of the open weights model especially Qwen 3.6 blindly runs env command and blindly exposes all the env vars. How do we deal with this. This has nothing to do with this security incident but this is how it all starts.
Chinese open weights models have liberated the world from Western exploitation. Great respect for Chinese students especially those who returned from foreign countries after their graduation and their research on AI.
This is absolutely true. With my constrained Intel Laptop with 16 GB VRAM, I can use both pi.dev and Qwen 3.6 35B-A3B LLM locally without much fuss. The same cannot be said about OC. Because OC loads a lot of skills by default.
Also, I am not in favor of TS for coding harness agents, is it time for a Rust based coding harness agent?
The other day I upgraded my pi.dev coding harness and was testing with Qwen 3.6 35B-A3B model on my Laptop and noticed there was a slight drop in performance from the earlier version I used though the agent worked as expected. Any slight changes in the system prompts will have impact on performance and this is understandable as LLMs are non deterministic. This is the case with any harness including OpenCode. Giving coding harness its own environment (Container/VM) is the best way forward as the article denounces. Running coding agent harness without sufficient guardrails is like sitting on a time bomb. Using AI slop guardrails is still better than having no guardrails.
In this AI era, we would also require a new role named "Backward Stability Engineer" whose job would be the exact opposite of FDE. The core of this role would be to defend from modern AI slop code updates, 0 downtime integrations, deterministic automation etc. Fusing LLM with Legacy systems will be their art.