Notable this week: Kimi K3 weights land, MCP goes stateless, OfficeCLI for agents

<p>Five things worth a closer look from this week.</p> <h2> Kimi K3 weights landed on HuggingFace on July 27 </h2> <p>Moonshot AI released K3 weights publicly on July 27, a week after the API went live. The model is 2.8 trillion total parameters — sparse MoE with MXFP4 quantization — and ranks #1 on Frontend Code Arena and #3 on the Artificial Analysis Intelligence Index. Context window is 1M tokens.</p> <p>Two things to have in hand before you schedule vLLM budget. First: benchmark charts from the first week of a release tend to reflect best-of-run rather than expected production performance, and K3's early independent evaluations included a 51% hallucination rate on one agentic task subset — something I flagged in the previous curated article. That number is now checkable against the open weights. Second: trillion-scale MoE models require real H100 infrastructure to serve at reasonable latency. Unless you have that, this is a benchmark reference for now, not a drop-in replacement for Claude Haiku in a CI pipeline.</p> <h2> MCP 2026-07-28 specification ships — stateless at the core </h2> <p>The <a href="https://blog.modelcontextprotocol.io/posts/2026-07-28/" rel="noopener noreferrer">Model Context Protocol 2026-07-28 spec</a> landed on July 28 and is the largest revision since MCP launched. The key architectural change: the protocol becomes stateless at its core. Previously, MCP servers needed sticky sessions and a shared session store to handle multi-step tool calls. Now a server can run behind a plain round-robin load balancer and route on an <code>Mcp-Method</code> header instead of connection state.</p> <p>Other additions: Multi Round-Trip Requests (the server can ask the client something mid-tool-call, enabling real async patterns), cacheable <code>tools/list</code> responses with <code>ttlMs</code>, authorization hardening, and a formal extensions framework. Beta SDKs for Python, TypeScript, Go, and C# are published against the release candidate. If you're building or maintaining an MCP server, the stateless shift directly affects how you handle any session-adjacent state in existing implementations. Worth a read before you pin a dependency.</p> <h2> OfficeCLI — Apache 2.0 CLI for AI agents working with Office files </h2> <p><a href="https://github.com/iOfficeAI/OfficeCLI" rel="noopener noreferrer">OfficeCLI</a> shipped in July with 10,800+ GitHub stars and an Apache 2.0 license. It's a single-binary C# tool — embedded .NET runtime, no Microsoft Office required — that gives AI agents read, write, and render access to <code>.docx</code>, <code>.xlsx</code>, and <code>.pptx</code> files from the command line.</p> <p>The part worth testing: it renders documents to PNG for visual inspection, supports 350+ Excel functions natively, and keeps documents in memory over named pipes in a resident mode. That resident mode matters for agentic loops — you're not deserializing the document on every tool call. For any pipeline that currently requires a human to open Office files, this is the obvious first thing to evaluate. The agent can see what it produced rather than guessing from raw XML, which is how most Office-in-CI hacks have worked until now.</p> <h2> GLM-5.2 is worth revisiting now that both trillion-scale models are open-weight </h2> <p>With both K3 and GLM-5.2 now publicly available, a real comparison is possible. Z.ai's <a href="https://www.marktechpost.com/2026/07/18/kimi-k3-vs-deepseek-v4-pro-vs-glm-5-2-open-trillion-scale-moe-models-compared-on-benchmarks-license-and-serving-cost/" rel="noopener noreferrer">GLM-5.2</a> is 753 billion parameters, MIT-licensed, and measurably cheaper to serve: K3 runs $3.00 input / $15.00 output per million tokens via API; GLM-5.2's rate is lower. GLM-5.2 sits at #5 on the Arena Agent board and scored 81% on Terminal-Bench 2.0 vs K3's 88.3%.</p> <p>If your use case doesn't require K3's agentic edge or frontend coding headroom, GLM-5.2 is a mean