Fireworks AI's OpenAI-compatible API serves open models at 4x GPT-4 speed -- swapping it in for non-critical agent tool calls takes two lines: change the base URL and the model name.

Multi-agent systems often fan out the same tool call to dozens of tasks: extract entities from documents, classify a category, parse a structured payload. These don't need frontier intelligence -- they need speed and low cost. Fireworks is built for exactly this routing slot.

## The two-line swap

If you already use the OpenAI Python SDK (or any OpenAI-compatible client), pointing it at Fireworks is a drop-in change:

```python from openai import OpenAI

client = OpenAI( api_key="fw_...", # your Fireworks API key base_url="https://api.fireworks.ai/inference/v1", )

response = client.chat.completions.create( model="accounts/fireworks/models/firefunction-v2", messages=[{"role": "user", "content": "Extract the JSON fields from this receipt: ..."}], response_format={"type": "json_object"}, ) ```

That's it. The same tools= list, tool_choice=, and response_format= parameters work identically.

## What Fireworks is fast at

- FireFunction-v2: structured outputs and function calling at ~4x GPT-4 speed on the Artificial Analysis benchmark -- the go-to model for tool-calling subagents - Open weights at low latency: Llama 3.3, Qwen 2.5, DeepSeek V3.2, Kimi K2.5 -- all served on dedicated kernels optimized for throughput - Serverless pricing: pay per token, no reservation; Priority tier for lowest latency, Standard for cost

## When to route here vs Claude

The pattern is simple: if the task needs reasoning or synthesis, use Claude. If it's extraction, classification, or structured parsing, route to Fireworks FireFunction-v2. The difference in cost and speed justifies the split even for modest workloads.

``python def call_agent(task_type: str, prompt: str) -> str: if task_type in ("extract", "classify", "parse"): return fireworks_client.chat.completions.create( model="accounts/fireworks/models/firefunction-v2", messages=[{"role": "user", "content": prompt}], ).choices[0].message.content else: return anthropic_client.messages.create( model="claude-sonnet-5-20251022", max_tokens=1024, messages=[{"role": "user", "content": prompt}], ).content[0].text ``

Sources: Fireworks AI inference platform · FireFunction on HuggingFace · Fireworks AI docs · Blazing-fast inference on open models

Anthropic has two hard August deadlines: claude-opus-4-1-20250805 returns errors after August 5, and three /v1/experimental prompt-tools endpoints shut off August 17.

August 5 -- Opus 4.1 retirement. If any of your production code still hardcodes claude-opus-4-1-20250805, it breaks in 10 days. Swap to claude-opus-4-8-20260507 (or just claude-opus-4-8). One gotcha: Opus 4.7 and later dropped the temperature, top_p, and top_k parameters -- passing non-default values now returns HTTP 400, so strip those fields in the same migration pass.

August 17 -- Legacy Workbench and Prompt APIs. The three /v1/experimental/ endpoints (generate_prompt, improve_prompt, templatize_prompt) and the legacy Workbench (platform.claude.com/workbench) are being retired together. If you use these to automate prompt generation or testing, export your saved prompts now from Organizational Settings -- the new Workbench is stateless and does not import old data.

Why it matters: A quiet prod service that's been calling Opus 4.1 for a year will silently break on August 5. Run a quick grep for opus-4-1 in your codebase, CI secrets, and config files before next week.

Sources: Claude model deprecations · Claude Platform release notes · Opus 4.1 migration guide

**Fine-tuning without evaluation is flying blind -- lm-evaluation-harness runs MMLU, GSM8K, and 200+ other benchmarks on your base and fine-tuned model in minutes so you see what got better and what broke.**

What you'll be able to do after this: - Run standardized benchmarks on any HuggingFace checkpoint in under 10 minutes using the same tool that powers the Open LLM Leaderboard - Spot catastrophic forgetting before it breaks your fine-tune in production - Generate a base-to-fine-tune score delta that makes model quality reviewable by your whole team

Resource: EleutherAI lm-evaluation-harness -- the open-source evaluation framework behind the HuggingFace Open LLM Leaderboard

## Why this step gets skipped

Most developers fine-tune a model, try a few prompts, see plausible outputs, and ship. The hidden risk is catastrophic forgetting: your model gets 15% better at your task and quietly loses 8% on everything else. lm-evaluation-harness makes this visible in 5 commands.

## Install

``bash pip install lm-eval ``

No dataset downloads upfront -- task configs are pulled from YAML files managed by the project.

## Step 1: Baseline the base model

``bash lm_eval \ --model hf \ --model_args pretrained=meta-llama/Llama-3.2-3B-Instruct \ --tasks mmlu,gsm8k \ --num_fewshot 5 \ --device cuda:0 \ --batch_size 8 \ --output_path ./results/base/ ``

The --num_fewshot 5 flag is critical: it matches how the Open LLM Leaderboard scores MMLU. Without it your scores are 3-8 points lower and incomparable to any published number.

## Step 2: Run the same eval on your fine-tune

``bash lm_eval \ --model hf \ --model_args pretrained=./checkpoints/my-fine-tune \ --tasks mmlu,gsm8k \ --num_fewshot 5 \ --device cuda:0 \ --batch_size 8 \ --output_path ./results/finetuned/ ``

## Step 3: Compare the delta

``python import json base = json.load(open("results/base/results.json")) ft = json.load(open("results/finetuned/results.json")) for task in ["mmlu", "gsm8k"]: b = base["results"][task]["acc,none"] f = ft["results"][task]["acc,none"] print(f"{task}: {b:.3f} -> {f:.3f} (delta {f-b:+.3f})") ``

A healthy fine-tune holds MMLU within ~2 points of the base while improving on your target task. A drop of more than 3 points on MMLU or more than 4 points on GSM8K is a red flag for catastrophic forgetting -- the dataset is too narrow or the learning rate is too high.

## Faster eval with the vLLM backend

Add --model vllm instead of --model hf for 3-5x faster evaluation on a Colab T4 or A100:

``bash lm_eval \ --model vllm \ --model_args pretrained=./checkpoints/my-fine-tune,dtype=float16 \ --tasks mmlu,gsm8k \ --num_fewshot 5 \ --batch_size auto \ --output_path ./results/finetuned/ ``

## Add it to CI

Once you have a baseline, a simple pass/fail check prevents regressions automatically:

``bash python -c " import json, sys b = json.load(open('results/base/results.json'))['results']['mmlu']['acc,none'] f = json.load(open('results/finetuned/results.json'))['results']['mmlu']['acc,none'] if (f - b) < -0.02: print(f'FAIL: MMLU dropped {f-b:+.3f}', file=sys.stderr); sys.exit(1) print(f'PASS: MMLU delta {f-b:+.3f}') " ``

Sources: EleutherAI lm-evaluation-harness · HuggingFace Open LLM Leaderboard · Evaluating fine-tuned LLMs guide · lm-eval-harness 2026 tutorial

Add or remove Claude's tools between turns — without re-billing the entire cached prefix — using one beta header: a new pattern for agentic workloads that progressively expose or retire tools.

Every production agent faces a tension: give Claude a small, safe toolbox and you limit capability; give it the full toolbox upfront and you expose write surfaces before you need them. The mid-conversation-tool-changes-2026-07-01 beta, introduced with Claude Opus 5, resolves this.

## The problem

Before this beta, changing the tool list invalidated the cached prefix — meaning a large system prompt or long conversation history was re-billed at full price on every tool-set change.

## The fix: one beta header

Include the header on every request in the session:

```python import anthropic

client = anthropic.Anthropic()

# Turn 1 — read-only exploration r1 = client.messages.create( model="claude-opus-5-20260724", max_tokens=1024, betas=["mid-conversation-tool-changes-2026-07-01"], tools=[search_tool, read_file_tool], messages=[{"role": "user", "content": "Explore the codebase and draft a plan."}], )

# Turn 2 — user approves; add write access r2 = client.messages.create( model="claude-opus-5-20260724", max_tokens=1024, betas=["mid-conversation-tool-changes-2026-07-01"], tools=[search_tool, read_file_tool, edit_file_tool], # unlocked messages=[ *prior_messages, {"role": "assistant", "content": r1.content}, {"role": "user", "content": "Looks good — go ahead."}, ], ) ```

The system prompt and prior turns stay cached across both calls. Only the delta (the changed tool definition) is re-billed.

## Progressive access pattern

A clean four-phase flow for multi-step agentic tasks:

1. Explore — read-only tools (search, grep, read) 2. Plan and approve — same tools; user confirms before anything mutates 3. Execute — narrow write tools added (edit, create, run) 4. Verify — write tools retired; test and lint tools take over

This keeps Claude's exposure minimal at every stage, which matters for both cost (smaller tool definitions = cheaper cached prefix) and safety (no write surface during exploration).

Available on Fable 5, Mythos 5, Opus 4.8, and Opus 5. Mid-conversation system message changes (GA, no beta header needed) work the same way and also preserve the cache.

Sources: Mid-conversation system messages and tool changes · What's new in Claude Opus 5 · Introducing Claude Opus 5

HNSW is the graph index inside pgvector, Qdrant, Weaviate, ChromaDB, and FAISS — three knobs control all of them: m (connectivity), ef_construction (build quality), and ef (query depth).

What you'll be able to do after this: - Explain why HNSW finds approximate nearest neighbors in sub-millisecond time across millions of vectors — and why brute-force can't - Tune m, ef_construction, and ef for the right recall/latency tradeoff in any vector database - Benchmark your own collection and find the performance knee that fits your workload

Resource: Qdrant Essentials Course, Day 2: HNSW Indexing + YouTube walkthrough

## How HNSW works

HNSW builds a multi-layer graph. Higher layers contain fewer nodes connected by long-range "highway" edges — they let a search jump quickly across the vector space. Lower layers are dense with local connections for fine-grained lookup.

At query time, search enters at the top (coarsest) layer, follows the closest edges downward through increasingly dense layers, and returns approximate nearest neighbors. This is typically 10–100× faster than brute-force scan, with 95–99% recall — which is why every major vector database uses it as the default index.

All the databases covered in this learning track use HNSW: pgvector, Qdrant, Weaviate, ChromaDB, and FAISS (IndexHNSWFlat).

## The three parameters you control

| Parameter | Controls | When set | |---|---|---| | m | Edges per node per layer — higher = better recall, more memory and build time | Index creation | | ef_construction | Candidates explored during build — higher = better index quality, slower build | Index creation | | ef (or ef_search) | Candidates explored per query — higher = better recall, slower queries | Query time (tunable live) |

Starting values: m=16, ef_construction=200, ef=128. Raise m when recall matters more than memory. Raise ef at query time for a recall boost without rebuilding the index.

## Hands-on walk-through (Qdrant course)

The Qdrant Essentials Day 2 course runs you through a 100K-vector benchmark:

1. Upload vectors with HNSW disabled — measure brute-force baseline latency 2. Enable HNSW with default params — observe the latency drop 3. Tune m and ef_construction, rebuild — measure recall against a ground-truth set 4. Use the HNSW Performance Benchmarking project to find the recall/latency knee for your collection

The YouTube video is the clearest visual walkthrough of the layer traversal before you run the code.

The same parameters exist in every major vector DB — they just use different names:

| Database | m | ef_construction | ef at query time | |---|---|---|---| | Qdrant | m | ef_construct | ef | | pgvector | m | ef_construction | hnsw.ef_search | | Weaviate | maxConnections | efConstruction | ef | | ChromaDB | M | ef_construction | ef |

Once you understand the three knobs, you're fluent across all of them.

Sources: HNSW Indexing Fundamentals — Qdrant · HNSW Performance Tuning Demo · YouTube: Fast Vector Search with HNSW Indexing

TL;DR: Set sandbox.network.strictAllowlist: true in settings.json and sandboxed bash will silently deny any non-allowlisted host — no prompt, no approval loop, just a hard block at the network layer.

Shipped in Claude Code v2.1.219 (July 24), this setting closes a gap that's been quietly painful for teams running agents in CI: unexpected outbound connections either blocked the pipeline on a confirmation prompt or slipped through undetected. Now there's a third option — fail fast, silently, at the network layer.

## The problem it solves

When strictAllowlist is off (the default), a sandboxed curl, pip install, or npm install to an unlisted host either: - Prompts the user to approve — which hangs an unattended agent - Succeeds, because the sandbox uses a soft allowlist by default

Neither is what you want in a CI pipeline or a fully autonomous agent run.

## Configure it in 60 seconds

``json // .claude/settings.json { "sandbox": { "network": { "strictAllowlist": true, "allowedDomains": [ "api.github.com", "registry.npmjs.org", "files.pythonhosted.org", "pypi.org", ".anthropic.com", ".amazonaws.com" ] } } } ``

What changes immediately: - Any host not in allowedDomains → immediate connection refusal (no prompt, no log noise) - The agent sees ECONNREFUSED or DNS failure, handles it as a tool error, and moves on - CI pipelines no longer hang waiting for an approval that will never come

## Build your allowlist

Start with the minimal set your workflows need, then expand as the agent hits blocks. Common additions:

| Purpose | Domain | |---|---| | npm packages | registry.npmjs.org | | PyPI packages | pypi.org, files.pythonhosted.org | | GitHub API | api.github.com | | Maven / Gradle | repo1.maven.org, plugins.gradle.org | | Docker Hub | registry-1.docker.io | | Your artifact store | *.s3.amazonaws.com or your CDN |

## When to keep it off

In local interactive sessions where you want Claude to pull documentation or hit arbitrary APIs, leave strictAllowlist: false (the default). Turn it on project-wide for CI deployments, or in an org-level settings.json to enforce egress control across all agents in your organization.

Sources: Claude Code changelog v2.1.219 · Claude Code sandboxing docs · Claude Code security docs

TL;DR: Anthropic and AMD signed a 2GW MI450 GPU deal with AMD investing up to $5B — making Claude's training and serving stack explicitly quad-vendor and signaling serious ROCm investment ahead.

On July 22, AMD and Anthropic announced a strategic partnership to deploy up to 2 gigawatts of AMD Instinct MI450 Series GPUs in AMD Helios rack-scale systems, with deployment of the first gigawatt beginning H1 2027. AMD also committed a strategic equity investment of up to $5 billion in Anthropic.

Anthropic's compute is now running across four hardware vendors: NVIDIA (existing), Google TPUs (AWS/Google Cloud), AWS Trainium, and now AMD Instinct. When one supply chain tightens, Claude has hardware to route around it.

The developer angle: the deal includes a software collaboration clause — Anthropic will use Claude to optimize workloads for AMD Instinct GPUs and accelerate AMD ROCm development. That's the number that matters most for engineers running open-weight models on AMD hardware. ROCm has been 5–15% slower than CUDA on equivalent inference tasks; with Anthropic's engineering resources pointed at it, that gap should narrow over the next 12–18 months. AMD is also adopting Claude broadly across its engineering and product teams, creating a direct feedback loop between frontier-model usage and hardware design decisions.

Why it matters: for self-hosted ML engineers, AMD MI300X (available now, predecessor to MI450) is already a viable alternative to H100 for inference. As ROCm tooling improves — particularly vLLM and SGLang ROCm backends, which the partnership will accelerate — AMD becomes a stronger option for cost-sensitive inference deployments.

Sources: AMD press release · AMD newsroom · CNBC

TL;DR: Three commands move your MCP server from localhost to a public HTTPS endpoint on Cloudflare Workers using Streamable HTTP — the transport that replaces SSE as the July 28 spec locks in.

What you'll be able to do after this: - Deploy an MCP server with a live public /mcp HTTPS endpoint in under 5 minutes, no infrastructure provisioned - Understand why Streamable HTTP (not stdio, not SSE) is the transport for multi-client, production MCP - Optionally add Cloudflare Access auth so only your team or specific services can connect

## Why Cloudflare Workers?

stdio MCP servers run in the same process as the client — Claude Desktop, a local script. That works for personal tools but breaks the moment you want to share a server across teams, connect from CI, or expose a tool to multiple agents simultaneously. The July 28 MCP spec update finalizes Streamable HTTP as the only supported remote transport; SSE is sunset.

Cloudflare Workers is the fastest path to a compliant remote MCP endpoint: globally distributed edge runtime, serverless, free tier available, and Anthropic has published a first-class template for it.

## The three commands

Step 1 — Scaffold from the official template: ``bash npm create cloudflare@latest -- my-mcp-server \ --template=cloudflare/ai/demos/remote-mcp-authless cd my-mcp-server ``

This creates a TypeScript Workers project with McpAgent pre-wired. The generated src/index.ts is small — about 30 lines:

```typescript import { McpAgent } from "agents/mcp"; import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { z } from "zod";

export class MyMCP extends McpAgent { server = new McpServer({ name: "demo", version: "1.0.0" });

async init() { this.server.tool( "add", { a: z.number(), b: z.number() }, async ({ a, b }) => ({ content: [{ type: "text", text: String(a + b) }], }) ); } }

export default { fetch: MyMCP.serve("/mcp").fetch }; ```

Step 2 — Add your tools. Every tool is a this.server.tool() call inside init(). The McpAgent class handles session state via Durable Objects, transport negotiation (SSE and Streamable HTTP), and the /mcp route.

Step 3 — Deploy: ``bash npx wrangler login # one-time auth npm run deploy # Deployed to: my-mcp-server.your-account.workers.dev/mcp ``

Your MCP endpoint is live. The /mcp path accepts both POST (Streamable HTTP) and the legacy GET (SSE) requests — clients choose automatically.

## Test it without a client

``bash npx @modelcontextprotocol/inspector@latest \ https://my-mcp-server.your-account.workers.dev/mcp ``

The MCP inspector runs in your browser and lets you invoke tools interactively.

## Connect it to Claude

In Claude Desktop's claude_desktop_config.json: ``json { "mcpServers": { "my-server": { "url": "https://my-mcp-server.your-account.workers.dev/mcp" } } } ``

## Optional: lock it down with Cloudflare Access

Follow the Cloudflare One → Secure MCP servers guide to put a zero-trust auth layer in front. Users authenticate with your IdP; unauthenticated requests get a 403 before reaching the Worker. This is the pattern for team-shared or production MCP servers.

Sources: Cloudflare: Build a Remote MCP server · MCP transport docs · Secure MCP servers with Cloudflare One

TL;DR: Fan out 50 parallel Claude Code agents across your repositories using a two-stage pattern — fast rules scan first, then targeted agent review — to audit millions of lines in hours, not weeks.

Alberta's Ministry of Technology and Innovation scanned 466 million lines of code in 20 hours using this approach. The pattern is repeatable with standard Claude Code.

## Stage 1 — Fast pattern scan (cheap)

Run semgrep, CodeQL, or a simple grep sweep against your repos. The goal is to flag candidate locations — not to reason about them yet. This phase is fast and inexpensive because it doesn't need code understanding, just signature matching.

``bash semgrep --json --config=auto ./src > findings.json ``

## Stage 2 — Agent review (targeted, deep)

For each flagged location, a Claude Code subagent receives the file + surrounding context (50–100 lines) and answers three questions:

1. Is this actually exploitable in context? 2. What's the minimal fix? 3. Does a test exist to verify the fix?

If no test exists, Claude writes one first, then patches. Run 20–50 subagents in parallel — one per finding batch — to fan out across repos simultaneously.

## Optional: red/blue team agents

Add two specialized agents for comprehensive coverage:

- Red team: probes the application from the outside, mapping the attack surface and tracing how findings could chain into larger exploits - Blue team: checks defenses against a controls checklist (OWASP Top 10, CIS, ISO 27001) and writes a remediation plan with exact file references

Alberta runs 95 security controls per application per pass with this setup. Applications originally built in the 1990s were rebuilt in modern, safer languages in 4–5 days (versus 5 months the first time).

## Where to start

The Claude Code Review docs walk through setting up a review workflow. The Alberta case study (with published technical white papers) shows what this looks like at government scale — and what to expect as Claude writes tests, patches, and occasionally rebuilds whole modules.

Sources: Alberta government case study — Anthropic · Claude Code Review docs · Automate security reviews with Claude Code

TL;DR: QLoRA + Unsloth lets you fine-tune an 8B-parameter LLM on Google Colab's free T4 GPU — 2× faster training, 70% less VRAM, and a working model in under an hour.

What you'll be able to do after this: - Fine-tune Llama 3.1 8B on your own instruction dataset using a free Colab GPU - Understand why QLoRA (4-bit quantization + LoRA adapters) makes large models trainable on consumer hardware - Export a merged model or GGUF file ready for Ollama or HuggingFace upload

## Why this matters

Most fine-tuning guides assume A100s or H100s. Unsloth makes that assumption obsolete. The library — built by Daniel and Michael Han — replaces key HuggingFace Trainer internals with hand-written CUDA kernels optimized for the LoRA backward pass. Result: 2× faster training and 60–70% less VRAM with mathematically identical outputs.

Paired with QLoRA (load the frozen base model in 4-bit NF4, train small LoRA adapters at bf16), you can fine-tune Llama 3.1 8B on a free Colab T4 (16 GB VRAM) in 30–60 minutes on a small dataset.

## Four concepts powering this

1. LoRA: Freeze all base weights; insert small trainable matrices at target layers (Q, K, V, O, gate/up/down projections). You train millions of adapter params, not billions — adapters are the only thing saved. 2. QLoRA: Quantize the frozen base model to 4-bit (NF4) via bitsandbytes. Adapters train at bf16. ~4× less memory for the base; negligible accuracy loss on instruction-following tasks. 3. Unsloth kernels: Fused triton kernels for attention and the LoRA backward pass. Standard PEFT computes this inefficiently; Unsloth rewrites it. Most gains come from the backward pass on the T4. 4. Gradient checkpointing: Recomputes intermediate activations during the backward pass instead of caching them — trades a bit of compute for a lot of memory, making 16 GB enough for an 8B model.

## Run it now — free Colab T4

Open the official Llama 3.1 Unsloth notebook, which handles GPU detection and a sample dataset. The key code:

```python # Install !pip install unsloth

# Load the 4-bit quantized model from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained( model_name="unsloth/Meta-Llama-3.1-8B-Instruct-bnb-4bit", max_seq_length=2048, load_in_4bit=True, )

# Attach LoRA adapters model = FastLanguageModel.get_peft_model( model, r=16, # rank — higher = more params, more capacity target_modules=["q_proj","k_proj","v_proj","o_proj", "gate_proj","up_proj","down_proj"], lora_alpha=16, lora_dropout=0, bias="none", use_gradient_checkpointing="unsloth", )

# Fine-tune with TRL's SFTTrainer on your Alpaca-format dataset from trl import SFTTrainer from transformers import TrainingArguments

trainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=dataset, # HuggingFace dataset in {"text": "..."} format dataset_text_field="text", args=TrainingArguments( output_dir="outputs", num_train_epochs=1, per_device_train_batch_size=2, gradient_accumulation_steps=4, learning_rate=2e-4, fp16=True, ), ) trainer.train()

# Export merged model (16-bit) or GGUF for Ollama model.save_pretrained_merged("my-model", tokenizer, save_method="merged_16bit") # model.save_pretrained_gguf("my-model", tokenizer, quantization_method="q4_k_m") ```

Practical notes: - Use r=8 to save memory on the T4 at the cost of a little capacity; r=32 if you have more VRAM - Dataset format: any Alpaca JSON (instruction, input, output) or a HuggingFace dataset with a text field - The free T4 supports context lengths up to ~2K comfortably; for longer sequences, use Colab Pro

Sources: Official Unsloth Llama 3.1 notebook · Unsloth Notebooks page · HuggingFace + TRL + Unsloth guide · YouTube: Unsloth Full Guide (Dec 2025)

TL;DR: Claude Code v2.1.219 adds two settings that give your team finer control — workflowSizeGuideline caps multi-agent fleet size project-wide, and the DirectoryAdded hook auto-runs setup scripts whenever a new workspace directory joins a session.

## workflowSizeGuideline: right-size workflows for your project

Claude Code's dynamic workflow system picks a fleet size for multi-agent tasks automatically. By default it uses the session's advisory guideline (configurable in /config), but that setting isn't committed to your repo — every developer can silently drift.

The new workflowSizeGuideline key fixes that. Set it in .claude/settings.json and it overrides the user-level /config value for anyone working in that repo:

``json { "workflowSizeGuideline": "small" } ``

Valid values: "small" · "medium" · "large". When a project-level value is set, the /config row for this setting is hidden so no one accidentally overrides it locally.

When to use each:

| Value | Best for | |---|---| | "small" | Cost-sensitive projects, focused CI tasks, repos where most work is single-file | | "medium" | General development — the default if unset | | "large" | Monorepo refactors, multi-service migrations, comprehensive audits |

For most teams, commit "small" or "medium" to start, then bump up per-project when you have a legitimate use for larger fleets. This keeps token spend predictable across your whole engineering org.

## DirectoryAdded hook: per-workspace setup in monorepos

The DirectoryAdded lifecycle hook fires whenever /add-dir or the SDK register_repo_root call brings a new directory into the active session. It's the missing piece for monorepo setups where each workspace has its own deps or linting config.

Add it alongside your other hooks in .claude/settings.json:

``json { "hooks": { "DirectoryAdded": [ { "matcher": "", "hooks": [ { "type": "command", "command": "bash .claude/hooks/on-dir-added.sh \"$CLAUDE_ADDED_DIR\"" } ] } ] } } ``

Example .claude/hooks/on-dir-added.sh:

```bash #!/usr/bin/env bash # Runs when a new directory is registered in a Claude Code session DIR="$1" cd "$DIR" || exit 0

# Install workspace deps if a package file exists if [ -f package.json ]; then echo "Installing node deps for $DIR..." pnpm install --frozen-lockfile --silent fi

if [ -f pyproject.toml ] || [ -f requirements.txt ]; then echo "Setting up Python env for $DIR..." uv sync --quiet 2>/dev/null || pip install -r requirements.txt -q fi ```

The hook receives the added directory path as $CLAUDE_ADDED_DIR. Keep the script fast — it runs synchronously before Claude gets context from the new directory.

Why it matters: without this hook, Claude enters a new workspace cold. With it, deps are already installed, linters are configured, and any per-workspace validation you care about has already run — Claude's first action in that directory is never "install deps."

Sources: Claude Code Changelog · Claude Code Hooks guide — DataCamp · Complete Hooks Guide — claudefa.st

TL;DR: NVIDIA NIM wraps an optimized model, the right inference backend, and an OpenAI-compatible API into one Docker container — pull it, start it, and you're serving a real model in under 5 minutes on any NVIDIA GPU.

Resource: NVIDIA NIM — Deploy Accelerated AI in 5 Minutes (YouTube, 16 min, All About AI) — covers the full deployment flow from API Catalog to self-hosted GPU container. Pair it with the official NIM LLM quickstart docs.

What you'll be able to do after this: - Pull a NIM container and start serving Llama 3.1 8B locally with one docker run command - Query it from any OpenAI-compatible client by changing only base_url — no new SDK needed - Prototype against NVIDIA's hosted API Catalog for free, then self-host with identical code

## What NIM is — and what it saves you

Running an open model yourself normally means: picking an inference backend (vLLM, SGLang, TRT-LLM), downloading or compiling the right weights, wiring an API server, tuning memory settings per GPU. NIM does all of that inside one container. On startup it detects your GPU, picks the fastest compatible backend, and loads pre-built TensorRT-LLM profiles when available — no compile step, no framework decisions.

## Step 1: Get an NGC API key (free)

Sign up at developer.nvidia.com and create a key at build.nvidia.com/settings/api-keys. You'll use it for both the hosted API Catalog and the private container registry.

## Step 2: Prototype against NVIDIA's hosted endpoints (no GPU required)

```python from openai import OpenAI

client = OpenAI( base_url="https://integrate.api.nvidia.com/v1", api_key="<your-ngc-api-key>", ) response = client.chat.completions.create( model="meta/llama-3.1-8b-instruct", messages=[{"role": "user", "content": "Explain KV-cache in two sentences."}], max_tokens=200, ) print(response.choices[0].message.content) ```

This hits NVIDIA's cloud-hosted NIM. It's the same API schema you'll point at your own GPU later — the only change is base_url.

## Step 3: Run a NIM container on your own GPU

GPU requirement: ≥24GB VRAM for Llama 3.1 8B (A100 40GB, RTX 4090, or similar).

```bash export NGC_API_KEY=<your-key>

# Log in to the NVIDIA container registry echo "$NGC_API_KEY" | docker login nvcr.io --username '$oauthtoken' --password-stdin

# Pull and run (first run takes 5-15 min — downloads weights + caches backend profiles) docker run --rm -it \ --gpus all \ -e NGC_API_KEY=$NGC_API_KEY \ -v ~/.cache/nim:/opt/nim/.cache \ -p 8000:8000 \ nvcr.io/nim/meta/llama-3.1-8b-instruct:latest ```

The -v ~/.cache/nim mount persists the compiled model profiles — subsequent restarts load in seconds.

## Step 4: Point your client at localhost

``python client = OpenAI( base_url="http://localhost:8000/v1", api_key="ignored", # NIM doesn't validate this locally ) # Model name, parameters, and response format are identical ``

Wait for the container to be ready before sending requests:

``bash curl -s http://localhost:8000/v1/health/ready # returns {"status":"ready"} once the model is loaded ``

## What NIM handles vs. a manual vLLM setup

| Manual vLLM/SGLang | NVIDIA NIM | |---|---| | Choose backend, install, configure | Auto-selected based on your GPU | | Compile TRT-LLM profiles yourself | Pre-built, cached on first run | | Wire API server + routes | OpenAI-compatible API included | | Health + metrics endpoints | Built in (/health/ready, /metrics) | | Re-run setup for each new model | Pull a different NIM image |

NIM trades flexibility for speed-to-production. For standard models (Llama, Mistral, Qwen, Gemma) where you want reliable throughput and don't need a custom engine configuration, it's the fastest path from "I have a GPU" to "I have a production endpoint."

Sources: NVIDIA NIM — Deploy Accelerated AI in 5 Minutes (YouTube) · NIM LLM Quickstart (official docs) · Simple Guide to Deploying GenAI with NIM — NVIDIA Technical Blog · API Catalog Quickstart

TL;DR: The MCP specification publishes July 28 — protocol goes stateless (no sessions, no init handshake), OAuth 2.1 auth replaces custom flows, and beta SDKs are available to test your server today.

The July 28 MCP spec isn't a minor version bump. Six Specification Enhancement Proposals ship together, restructuring how every MCP server and client communicate. If your server uses session IDs, the initialization round-trip, or sampling, this affects you.

## What changes

| Pattern | After July 28 | |---|---| | Session IDs across calls | Sessions removed — design for stateless | | initialize / initialized handshake | Dropped — clients skip this entirely | | Sampling (server → host LLM calls) | Deprecated — 12-month runway | | Roots (filesystem boundary declarations) | Deprecated — 12-month runway | | Tools-list responses | Now cacheable — add Cache-Control headers |

The biggest practical win: MCP servers can now sit behind a round-robin load balancer without sticky sessions. No more "pin this client to this server process" complexity.

## Test your server today

The beta SDKs for the new spec are already out:

```bash # Python pip install mcp==1.11.0b1

# TypeScript / Node npm install @modelcontextprotocol/sdk@1.11.0-beta.0 ```

Swap in the beta SDK and run your existing test suite. Anything that references session_id, calls initialize, or depends on sampling will surface immediately. Most servers need minor changes — the main surgery is removing initialization handshake code and ensuring handlers don't read from a session context object.

## The auth rewrite

The spec now aligns MCP authorization with OAuth 2.1 and OpenID Connect, which makes enterprise integration significantly easier. If your server's current auth was hand-rolled for the draft spec, expect to update it — the new flow follows standard OIDC patterns rather than MCP-specific conventions. The WorkOS guide linked below covers the new auth flow in detail.

Sources: MCP 2026-07-28 Release Candidate · Beta SDKs Available · MCP Auth Changes (WorkOS) · Migration Guide (AAIF)

TL;DR: SIGGRAPH 2026 marked the moment MCP stopped being an experiment in creative software — Blender, Unreal Engine, Adobe Creative Cloud, SideFX Houdini 22, and others all shipped or demonstrated live MCP integrations.

NVIDIA used SIGGRAPH 2026 to showcase that Model Context Protocol has crossed into standard infrastructure for professional creative tooling. Blender, Unreal Engine, Adobe Creative Cloud, SideFX Houdini 22, Boris FX Silhouette, and Foundry Griptape each announced or demonstrated MCP server integrations. An AI agent running on local hardware can now inspect a Houdini scene for missing textures, generate procedural character rigs from a prompt, or prepare Blender export variants — while the artist retains final approval.

NVIDIA also released Cosmos 3 Edge, a 4B-parameter open world model for physical AI and robotics, deployable on Jetson and RTX hardware for on-device inference without a cloud dependency.

Why it matters: If your team uses any of these tools in its content pipeline, you can now build an agent that works inside them using the same MCP client-server pattern you'd use to connect Claude to a database. MCP is no longer just a way to give AI access to data — it's becoming the standard agentic interface across the tooling stack.

Sources: NVIDIA Blog — SIGGRAPH 2026 · Cosmos 3 Edge — TechTimes

TL;DR: Document chunking is the most-overlooked RAG variable — the wrong split size or strategy silently tanks retrieval quality before the LLM ever runs. Here's how to get it right from the start.

What you'll be able to do after this: - Pick the right splitting strategy (fixed-size, recursive, semantic) for your document type and query mix - Configure chunk_size and chunk_overlap with numbers that actually work for your use case - Avoid the three most common chunking mistakes that silently lower retrieval recall by 20–30%

Resource: Why Your RAG Gives Wrong Answers (And 4 Chunking Strategies to Fix It) — YouTube. Covers the strategies below in video form with live demos; pair it with this walkthrough.

## The three strategies

### 1. CharacterTextSplitter (fixed-size baseline)

Split every N characters regardless of content. Fast and deterministic, but splits mid-sentence and destroys semantic context at boundaries.

```python from langchain_text_splitters import CharacterTextSplitter

splitter = CharacterTextSplitter(chunk_size=512, chunk_overlap=64) chunks = splitter.split_text(raw_text) ```

Use this only as a baseline to verify your pipeline end-to-end; don't ship it.

### 2. RecursiveCharacterTextSplitter (the production default)

Tries separators in priority order: `

→ → . → ` → character. Steps down only when the current separator doesn't fit the budget. Respects natural document boundaries while still hitting your size limit.

```python from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=64, separators=["

", " ", ". ", " ", ""] ) docs = splitter.create_documents([raw_text]) ```

This is the right default for most corpora. Start here.

### 3. SemanticChunker (embedding-based grouping)

Embeds each sentence and groups adjacent sentences whose cosine similarity passes a threshold. Produces semantically coherent chunks — ideal for technical reports and research papers where topics shift gradually.

```python from langchain_experimental.text_splitter import SemanticChunker from langchain_huggingface import HuggingFaceEmbeddings

embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2") chunker = SemanticChunker(embeddings, breakpoint_threshold_type="percentile") docs = chunker.create_documents([raw_text]) ```

Cost: one embedding call per sentence. Worth it for long-form structured documents; overkill for short mixed corpora.

## The two numbers that matter

- chunk_size: 256–512 tokens for factoid/lookup queries; 1024–2048 for analytical queries that need surrounding context. Start at 512 and tune by measuring retrieval recall on 20–30 representative questions. - chunk_overlap: 10–20% of chunk_size. Overlap prevents a key sentence from spanning two chunks and appearing in neither. At 512 chunks, 64 characters of overlap is a solid starting point.

## The silent killer

Splitting code or Markdown at fixed character boundaries. Use structure-aware splitters for these:

```python from langchain_text_splitters import MarkdownTextSplitter, PythonCodeTextSplitter

md_splitter = MarkdownTextSplitter(chunk_size=1000) py_splitter = PythonCodeTextSplitter(chunk_size=1000) ```

These preserve headings and function boundaries so a chunk never starts mid-code-block or mid-header.

Sources: Why Your RAG Gives Wrong Answers (YouTube) · LangChain Text Splitters Reference · Best Chunking Strategies for RAG 2026 — Firecrawl

TL;DR: Claude Opus 5 ships today — near-Fable-5 performance at half the cost, same price as Opus 4.8, model ID claude-opus-5, 1M token context, effort slider, and 4x better code verification.

Anthropic released Claude Opus 5 on July 24, 2026. It's the new default on Claude Max and the strongest model on Claude Pro. The one-sentence case for upgrading: you get significantly better agentic coding, computer use, and long-horizon knowledge work at exactly what you were already paying.

## What changed vs Opus 4.8

| | Opus 4.8 | Opus 5 | |---|---|---| | Context window | 200K tokens | 1M tokens | | Coding reliability | baseline | 4× fewer unremarked code flaws | | Effort slider | no | yes (low / medium / high) | | Price | $5/$25/M tokens | $5/$25/M tokens (same) | | Default on Max | yes | yes |

Opus 5 is state-of-the-art on Anthropic's Frontier-Bench and GDPval-AA evals. Fable 5 remains ahead on cybersecurity-specific tasks.

## API migration — one line

```python # Before model = "claude-opus-4-8"

# After model = "claude-opus-5" ```

No other changes required. Context window, pricing, and tool-use API are unchanged.

## The effort slider

Opus 5 adds a three-level effort control — low, medium, high — accessible from the Claude.ai UI and through the API effort parameter. Use "low" for fast summarization or classification tasks where deep reasoning isn't needed; save "high" for multi-step planning or complex debugging. This replaces the separate Fast-mode approach (Opus 4.7 fast mode was deprecated today; migrate to Opus 4.8 or skip ahead to Opus 5).

## When to use which model

| Task | Model | Price/M tokens | |---|---|---| | Day-to-day coding, PR review, Q&A | Sonnet 5 | $3 / $15 | | Complex agentic tasks, long-horizon work, knowledge Q&A | Opus 5 | $5 / $25 | | Frontier cybersecurity, hardest research | Fable 5 | $10 / $50 |

For most Claude Code sessions and agent workflows, Opus 5 is now the obvious default: it closes most of the gap with Fable 5 at half the API price, and the 1M token context window removes nearly all forced-summarization workarounds.

Sources: Introducing Claude Opus 5 — Anthropic · Claude Opus 5 on AWS — AWS Machine Learning Blog · VentureBeat · Bloomberg

TL;DR: The deepseek-chat and deepseek-reasoner API aliases retired at 15:59 UTC today — if your integration is broken right now, that's why. Migrate to deepseek-v4-flash with one non-obvious fix.

DeepSeek's backward-compatibility shim for deepseek-chat and deepseek-reasoner expired at 15:59 UTC on July 24. Both aliases had been pointing at deepseek-v4-flash under the hood since the V4 line shipped in April, kept alive purely for existing integrations. That shim is now gone.

## The one-line fix

```python # Before model = "deepseek-chat" # or "deepseek-reasoner"

# After model = "deepseek-v4-flash" # non-thinking path (see below) # or model = "deepseek-v4-pro" # higher capability ```

## The non-obvious catch: thinking mode

deepseek-v4-flash defaults to thinking enabled. If you swap deepseek-chat → deepseek-v4-flash without disabling it, you'll get reasoning output you never asked for: more tokens, higher latency, a bigger bill, and different downstream behavior in any system that parsed the old format.

To match the previous deepseek-chat behavior:

``python # OpenAI-compatible client response = client.chat.completions.create( model="deepseek-v4-flash", extra_body={"thinking_enabled": False}, # suppress reasoning mode messages=[...] ) ``

Why it matters: If you route through OpenRouter, Together, or a local proxy that aliased deepseek-chat, check whether your routing layer failed hard or soft — and whether thinking_enabled passes through to the underlying model.

Sources: DeepSeek API changelog · Migration guide — Digital Applied · Developers Digest: migrate to V4

TL;DR: Call Claude with a rubric prompt, temperature=0, and a required JSON output to get consistent, dimension-by-dimension scores for any agent or fine-tune output — at the speed of an API call, not a human review queue.

What you'll be able to do after this: - Build a rubric-based judge that scores agent outputs on custom dimensions (relevance, groundedness, conciseness) with a single API call each - Run 50 agent outputs through the judge and get a structured CSV of scores to compare model checkpoints - Wire the judge into a fine-tuning feedback loop: identify low-scoring examples, use them as hard training cases in the next run

Resource: Demystifying Evals for AI Agents — Anthropic Engineering Blog. This is how Anthropic's own team builds evaluation pipelines for long-horizon agents; the pattern transfers directly to evaluating any fine-tuned model or multi-step workflow.

## Why LLM-as-judge

After fine-tuning or building an agent, you face a hard question: how do you know it's actually better? Human evaluation is slow and expensive. Automatic metrics like ROUGE and BLEU miss hallucinations and tone. LLM-as-judge bridges the gap: you define what "good" means, Claude grades it consistently, and the whole pipeline runs in seconds.

## The pattern — one judge per dimension

```python import anthropic, json

client = anthropic.Anthropic()

RUBRIC = """You are a strict evaluator. Score ONLY the dimension you are asked about. Output JSON: {"score": 1-5, "reason": "one sentence"}

Dimension: {dimension} Definition: {definition} """

def judge_dimension(question, context, response, dimension, definition): msg = client.messages.create( model="claude-opus-5", max_tokens=128, temperature=0, # deterministic — critical for reproducibility system=RUBRIC.format(dimension=dimension, definition=definition), messages=[{ "role": "user", "content": f"Question: {question}\nContext: {context}\nResponse: {response}" }] ) return json.loads(msg.content[0].text)

# Run three isolated judges on the same output output = "The contract renews annually at the rate locked in at signing." scores = {} for dim, defn in [ ("relevance", "Does the response directly answer the question?"), ("groundedness", "Are all facts supported by the provided context?"), ("conciseness", "Does the response avoid filler and repetition?"), ]: scores[dim] = judge_dimension("When does the contract renew?", context_doc, output, dim, defn)

print(scores) # {"relevance": {"score": 5, "reason": "..."}, "groundedness": {"score": 3, "reason": "says annually but context says every 18 months"}, ...} ```

## Key design decisions

Temperature=0. You need reproducible scores. A judge that gives the same response a 3 one run and a 5 the next is useless for regression testing.

One criterion per call. Anthropic's engineering guidance is clear: grade dimensions in isolation. A single "grade everything" prompt produces correlated scores that hide individual failures. Separate calls reveal which specific dimension regressed between model versions.

Chain-of-thought inside the verdict. The reason field is not optional. A numeric score alone never tells you why — the reasoning surfaces specifics like "response says 2024 but context shows 2026" that let you fix the exact training example.

## Validate before you trust

Label 30–50 examples by hand, run them through your judge, and compare. Target 75–90% agreement with human labels. Below 60%? Your rubric is ambiguous — clarify the definition of each dimension before scaling.

## Closing the loop with fine-tuning

Once you have a judge harness, wire it to your training pipeline: 1. Score outputs from the baseline and from each checkpoint with the judge 2. Sort by lowest score per dimension 3. Use the lowest-scoring examples as hard negatives in your next DPO or SFT round (mistake amplification) 4. Re-score after each run to track per-dimension improvement over time

This turns LLM-as-judge from a one-off tool into a continuous quality feedback loop.

Sources: Demystifying Evals for AI Agents — Anthropic Engineering · LLM-as-Judge Evaluation Guide 2026 — Qaskills · LLM-as-Judge docs — Langfuse

TL;DR: Claude Cowork's "Record a Skill" converts a single screen-recording walkthrough into a reusable, rerunnable Skill — narrate your workflow once and Claude writes the automation for you, no prompts needed.

The hardest part of automating a workflow with Claude isn't running the automation — it's translating what you know about a task into a clear prompt. "Record a Skill", released July 21 in Claude Cowork for the desktop app, removes that barrier entirely.

## How it works

1. Open the + menu in Claude Cowork (desktop app — Pro, Max, or Team plan) 2. Start recording and complete the workflow at your normal pace: drag files, click buttons, fill in forms 3. Narrate as you go: "now I'm checking the PR status, then copying the review URL and posting it to Slack" 4. Stop the recording — Claude processes the screen activity, clicks, keystrokes, and voice commentary together and generates a structured Skill file 5. The Skill appears in your library; invoke it the next time without repeating the walkthrough

## Why narration outperforms prompts

When you write a prompt to describe a workflow, you have to anticipate every step, exception, and decision point in advance and express them in prose. Screen recording captures your actual behavior — including the implicit checks you perform and the edge cases you handle instinctively. Claude can observe those decision moments directly ("user paused here to check the ticket due date before moving on") rather than inferring them from your written description.

## Good candidates for your first recording

- Repetitive reporting workflows: pull status from Jira, format it, post to a Slack channel - Code review checklists you run across multiple PRs in the same way - Internal tool navigation that isn't documented anywhere but you do daily - Onboarding tasks you want to standardize for your team

Limitation to know: Currently desktop-only inside Claude Cowork. Screen recordings can capture sensitive information — review what was recorded before sharing or team-deploying a Skill.

Sources: Show, Don't Tell: Claude Cowork Now Learns Skills from Your Screen Recordings — Android Headlines · Forget prompts: Claude can now learn your workflow by watching your screen — Android Authority · Anthropic Ships "Record a Skill" in Claude Cowork — AI Weekly

TL;DR: Claude voice mode (July 23) expands from Haiku-only to full Opus/Sonnet/Haiku model choice with a mid-conversation picker, and adds cross-app automation that triggers actions in Gmail, Slack, Calendar, Canva, and Notion via voice.

Anthropic shipped a significant voice mode update on July 23. Previously limited to Haiku, voice mode now opens with whichever model you last used in text chat and lets you switch between Haiku, Sonnet, and Opus mid-call. Paid plans unlock Opus and Sonnet; free plans get Haiku and one connected app.

The more developer-relevant piece: cross-app automation via voice is live in ten languages. Users can now trigger structured actions — compose and send an email, add a calendar event, post to Slack, update a Canva canvas — through voice commands routed through Claude's existing tool-use machinery.

Why it matters: The "voice → intent → tool call → external service" pattern is exactly what agentic voice interfaces need. Anthropic is validating this architecture at scale with a consumer product before it reaches the API. Developers building voice-controlled Claude workflows should watch the connected-app tooling patterns that emerge from this rollout.

Sources: Anthropic updates Claude voice mode with more capable models — TechCrunch · Anthropic Brings Opus and Sonnet to Claude Voice Mode — Unite.AI