High
Claude Code v2.1.157 โ Local Plugin Auto-Load, `claude plugin init`, Agent Settings, and 20+ Bug Fixes
What changed
Plugins in .claude/skills directories now auto-load without marketplace registration. Previously, skills were installed through the Claude marketplace or required manual configuration; now any plugin placed in the .claude/skills directory is automatically discovered and loaded at session start. Added claude plugin init <name> scaffold command. The agent field in settings.json is now honored for dispatched sessions (override with --agent <name>). EnterWorktree can switch between Claude-managed worktrees mid-session. tool_decision telemetry events now include tool_parameters when OTEL_LOG_TOOL_DETAILS=1.
TL;DR
Claude Code v2.1.157 removes marketplace dependency for custom plugins โ any .claude/skills directory is auto-loaded, enabling teams to ship and iterate on local skills without waiting for marketplace approval.
Developer signal
If you're maintaining custom Claude Code skills or evaluating the skills system for your team, this is the release to test against. The auto-load change means you can: (1) claude plugin init my-skill to scaffold a new skill in .claude/skills/my-skill/, (2) restart Claude Code โ the skill loads automatically with no registration step. The agent field in settings.json is now meaningful for agentic workflows: set "agent": "my-agent-profile" in your project's settings.json to make dispatched sessions always use that agent configuration, with --agent <name> available as a per-invocation override. Separately, EnterWorktree mid-session switching means you no longer need to restart Claude Code when moving between Claude-managed worktrees in the same project. The 20+ bug fixes in this release include: WSL image paste (alt+v), Windows 11 screenshot paste, Windows Explorer drag-and-drop, right-click paste duplication in VS Code/Cursor/Windsurf, background session orphaned worktrees, sandbox network permission prompts in auto mode, literal markdown markers appearing in fullscreen mode, and terminal freezing after managed-settings security dialogs. Update: npm update -g @anthropic-ai/claude-code.
Affects you ifYou are building or using custom Claude Code plugins/skills; you are running Claude Code in agentic workflows with dispatched sessions; you are using Claude Code on WSL or Windows with integrated terminal issues.EffortQuick (update Claude Code; place plugins in .claude/skills/ โ no registration needed)
Medium
Claude Code v2.1.158 โ Auto Mode Available on Bedrock, Vertex, and Foundry for Opus 4.7/4.8
What changed
Auto mode โ which dynamically selects between fast completion and deep reasoning based on task complexity โ is now available for Opus 4.7 and Opus 4.8 on Amazon Bedrock, Google Vertex AI, and Microsoft Foundry deployments. Previously, Auto mode was only available through the first-party Claude API and Claude Code Max plan. Opt in via CLAUDE_CODE_ENABLE_AUTO_MODE=1.
TL;DR
Claude Code v2.1.158 extends Auto mode (adaptive fast/deep switching) to Bedrock, Vertex, and Foundry for Opus 4.7 and Opus 4.8 โ enterprise deployments on cloud platforms now get the same adaptive reasoning depth as first-party API users.
Developer signal
If you're running Claude Code through Bedrock, Vertex, or Foundry and have been using Opus 4.7 or 4.8 with static effort settings, Auto mode lets the model self-select reasoning depth per turn rather than requiring you to choose between fast and careful modes up front. Enable with CLAUDE_CODE_ENABLE_AUTO_MODE=1 in your environment. Note that Auto mode on cloud platforms still doesn't include fast mode (the 2.5ร speed acceleration at 2ร price) โ fast mode for Opus 4.8 remains Claude API-only per the May 28 release notes. If you're on the first-party Claude API and Claude Code Max plan, Auto mode was already available; this release adds parity for enterprise cloud-platform deployments. Useful for agentic coding loops where simple navigation turns don't need Opus-level reasoning but complex refactoring turns do.
Affects you ifYou deploy Claude Code via Amazon Bedrock, Google Vertex AI, or Microsoft Foundry and want adaptive reasoning depth without manually switching effort levels per task.EffortQuick (set CLAUDE_CODE_ENABLE_AUTO_MODE=1 โ no code changes, no config migration)
High
vLLM v0.22.0 โ EAGLE 3.1 (2.03ร Throughput), 28.9% FP8 Latency Improvement, DeepSeek V4 Hardening, Rust Frontend Preview
What changed
vLLM v0.22.0 ships EAGLE 3.1 speculative decoding (previously in preview, now integrated as config-driven extension with full backward compatibility for EAGLE 3 checkpoints), batch-invariant Cutlass FP8 inference (28.9% e2e latency reduction), CutlassFP8 padding preprocessing (+13.5% TTFT), padded NVFP4 quantization (+2.4โ5.7% e2e), Model Runner V2 advancement (Qwen3-dense-by-default oracle, sleep-mode weight reload, shared KV-cache layers), DeepSeek V4 with NVFP4 fused MoE and full CUDA graph, and an experimental Rust frontend. New thinking_token_budget API parameter and API-key authorization for /v2 endpoints are also included. Breaking: removed old get_tokenizer and resolve_hf_chat_template import locations; removed deprecated MLA prefill arguments; environment variables for backend selection now replaced by --moe-backend / --linear-backend flags.
TL;DR
vLLM v0.22.0 delivers 2.03ร per-user output throughput via EAGLE 3.1 speculative decoding at C=1 (1.66ร at C=16), 28.9% end-to-end latency improvement via batch-invariant FP8, and DeepSeek V4 with NVFP4 fused MoE in 459 commits from 230 contributors.
Developer signal
This is the most impactful vLLM upgrade in several months. Three distinct things to act on: (1) EAGLE 3.1 โ if you're running Kimi K2.x, Qwen3, or other models with available EAGLE draft checkpoints, upgrading to v0.22.0 and enabling EAGLE 3.1 via the config extension delivers 2.03ร per-user throughput at concurrency 1 (1.71ร at C=4, 1.66ร at C=16) on SPEED-Bench. The key technical fix vs. EAGLE 3 is FC normalization after each target hidden state plus post-norm hidden state feeding โ this eliminates attention drift that was causing acceptance length degradation in long-context workloads. EAGLE 3 checkpoints remain fully compatible. (2) FP8 improvements โ the batch-invariant Cutlass FP8 path yields 28.9% e2e latency reduction and the CutlassFP8 padding preprocessing delivers +13.5% TTFT improvement; no config changes needed if you're already using FP8 quantization โ the improvements apply automatically. (3) Breaking changes: if your codebase imports get_tokenizer or resolve_hf_chat_template from old vLLM locations, you will get import errors on upgrade; check your import paths before deploying. MLA prefill arguments deprecated in v0.21.x are now removed โ use --moe-backend and --linear-backend flags instead of the old environment variable equivalents. CUDA 12.9 wheels now use PyTorch manylinux_2_28 base โ verify your base image is compatible. FlashInfer bumped to v0.6.11.post2 and nvidia-cutlass-dsl to 4.5.2.
Affects you ifYou are running vLLM for inference serving (FP8 improvements apply broadly); you are using speculative decoding with EAGLE models (EAGLE 3.1 upgrade available); you are importing from vllm.utils.tokenizer or vllm.chat_template old paths (breaking change on upgrade); you are using DeepSeek V4 via vLLM (NVFP4 fused MoE now supported).EffortModerate (upgrade package; verify import paths; check CUDA wheel compatibility; configure EAGLE 3.1 via config extension if using speculative decoding)