Tech Radar - 2026-10-02 08:48

Priority Today

Claude Code 2.1.287 added Claude Mods, 1M context by default for Opus 4.7+, and a shell-write guard

Anthropic shipped v2.1.287 on 2026-10-01, headlined by Claude Mods, which let plugins modify deeper behaviour than before, plus a built-in You should know mod that runs a side agent watching the session. The same release made a 1M context window the default for Opus 4.7+ and Fable on Bedrock, Vertex, Foundry and the Claude apps gateway, with no [1m] suffix needed.

Why it matters: The npm stable dist-tag is still pinned at 2.1.285 while both latest and next point at 2.1.287, so any fleet image or CI job that tracks stable silently misses this build. Separately, if an MCP server stops connecting after this update, the fix is "bareElicitationCapability": true on that server's config entry, not a global setting.

What changed: An n:<text> filter in the agents view that also matches inside collapsed sections. prompt_text was added to the OpenTelemetry user_prompt event as a copy of prompt for backends that nest dotted keys, so it needs dropping or masking wherever you already mask prompt. Opus 4.7+ and Fable now use 1M context by default on Bedrock, Vertex, Foundry and the Claude apps gateway; CLAUDE_CODE_DISABLE_1M_CONTEXT=1 restores 200K. Whole-tool Bash allow rules and allowing hooks now prompt for a shell write rather than running it, when the target is a file Claude Code's own file tools refuse outright. A shell write through a repo-committed symlink onto a sensitive file now names the target and waits for a person.

For me: If you run Claude Code through Bedrock or Vertex you now get 1M context without changing the model string, so set CLAUDE_CODE_DISABLE_1M_CONTEXT=1 explicitly if you did not want that. Run npm dist-tag ls @anthropic-ai/claude-code before mass-bumping fleet images.

Tags: #topic/ai-coding #entity/claude-code #technology/mcp #technology/agent-skills #event/tool-release #relevance/ai-workflow #learning/hands-on

Sources:

Cloudflare released Clef, an Apache-2.0 multimodal decision model that scores every option in one forward pass

Cloudflare announced Clef and Clef-flash on 2026-10-01, releasing the weights on Hugging Face under Apache-2.0 and hosting both on Workers AI. Clef is a 27B model post-trained from Qwen3.8-27B that reads state as text, JSON, images or video and emits one logit per allowed option for every question in a single non-autoregressive pass, with an API fully compatible with Jev and SystemOne.

Why it matters: This is the shape of a decision model now that there are four of them. The mechanism is a small joint schema head on top of a frozen backbone: it reads the final hidden states, routes evidence to each question, and scores all options of all questions jointly, so there is no free-form text generation and no output parsing. A schema you have never used needs no retraining, and the answer cannot come back malformed. What makes these models interchangeable is the interface rather than the weights, which is why a 27B Apache-2.0 model, a 421M model and a closed API can all answer the same suite. The tradeoff is the one Cloudflare's own latency table shows: Laya answers in 5.8 ms, Clef-flash in 38.8 ms, Clef in 209.3 ms and Jev's API in 524.1 ms. Decision quality, calibration and latency are three different purchases.

What changed: Cloudflare reports beating the other decision models across 43 eval benchmarks, with 64k context against Jev's 32k and a vision encoder where Jev is text-only. The backbone is frozen with rank-256 low-rank adapters and a routing head trained on label-smoothed cross-entropy plus a Brier loss for calibration, using RLCD, their Reinforcement Learning for Calibrated Decisions. They also announced an RL service that goes from AI Gateway request capture to Workers AI rollouts to Containers as the scoring sandbox. Those are Cloudflare's numbers from Cloudflare's harness and have not been reproduced independently.

For me: Weights are on Hugging Face with vLLM and SGLang recipes, and the model card is tested on a single H200, so self-hosting the 27B is not cheap. The hosted Workers AI route is the practical one to try first. If you already call Jev, the swap is a base URL change.

Tags: #topic/ai-models #entity/cloudflare #entity/huggingface #technology/structured-output #technology/finetuning #event/model-release #relevance/developer #learning/deep-dive

Sources:

K3s will pull its own system images from GHCR instead of Docker Hub in v1.40

K3s maintainers announced on 2026-10-01 that from v1.40, expected July 2027, the images K3s deploys itself move from docker.io/rancher/... to ghcr.io/k3s-io/.... That covers CoreDNS, Traefik, local-path-provisioner, metrics-server, klipper-helm, klipper-lb and the pause image. The images keep being published to Docker Hub under rancher/; K3s just stops pulling from there.

Why it matters: The trigger is rate limiting. The paid SUSE and Docker arrangement covering the rancher organisation is ending, so every K3s system-image pull will start counting against Docker Hub's pull limits. Only K3s-deployed images are affected, so your own workloads keep pulling from wherever they do now, and nothing changes on a cluster until you upgrade it to v1.40.

What changed: Four configurations need edits at upgrade time. --system-default-registry now resolves to <registry>/k3s-io/<image> instead of rancher/, so those images must exist under k3s-io/ before the upgrade. Anything mirroring or proxying docker.io in registries.yaml needs a ghcr.io entry added, and that file has to be updated on every node with K3s restarted. Airgap tarballs from older releases will not work with v1.40, because they carry the old rancher/ names and land as <registry>/rancher/... while K3s asks for <registry>/k3s-io/.... Setting --system-default-registry to an empty string now means ghcr.io, where it previously meant docker.io.

For me: If you run K3s with defaults and can reach ghcr.io, nothing to do. Audit now if you mirror, set --system-default-registry, run air-gapped, or restrict node egress, because the post gives you several releases. Staying on docker.io/rancher/ is still possible but needs both a ^k3s-io/(.*) to rancher/$1 rewrite and an explicit https://index.docker.io endpoint, since rewrites are not applied to the default Docker Hub endpoint.

Tags: #topic/devops #entity/k3s #technology/containerization #technology/self-hosting #event/api-change #relevance/infrastructure #learning/hands-on

Sources:

K3s System Images Are Moving to GHCR

Microsoft shipped its first streaming transcription model alongside two MAI voice models

Microsoft announced MAI-Transcribe-2-Streaming, MAI-Voice-2.1 and MAI-Voice-2.1-Flash on 2026-10-01, available the same day through Microsoft Foundry, the MAI Playground, Vercel AI Gateway and Azure Voice Live, with LiveKit listed as coming. The transcription model accepts continuous audio over a WebSocket and sends incremental transcript updates before confirming a final segment, covering more than 60 languages with automatic detection.

Why it matters: This is the listening half of a voice agent, and it is the half that forces the usual latency tradeoff. Returning provisional hypotheses while audio is still arriving is what lets an application render live captions or start acting before the speaker finishes, which is exactly where batching transcription usually gives up responsiveness.

What changed: Microsoft reports first transcript hypotheses within 320 ms on average, caveated that end-to-end latency also depends on the network and the system generating the reply. Vercel's listings price streaming transcription at $0.54 per audio hour, MAI-Voice-2.1 at $22 per million characters and the Flash variant at $15 per million characters. Both voice models cover 23 languages across 26 locales from a single voice identity. The model debuted at number one on Artificial Analysis for both partial and final transcript accuracy.

For me: The batch sibling MAI-Transcribe-2 was $0.10 per audio hour as a limited-time offer through the end of 2026, so streaming is priced well above it, and the cheap rate is not a permanent benchmark for the family. If you are assembling a voice agent, the three-model split is now purchasable per stage rather than bundled.

Tags: #topic/ai-models #entity/microsoft #technology/llm-api #event/model-release #relevance/developer #learning/understand

Sources:

AI Coding and Agents

DSCODE is a macOS terminal coding agent where sessions are visible to each other and an independent reviewer approves changes

DSCODE is a MIT-licensed terminal coding agent for macOS built on DeepSeek Harness, released at version 0.7.32. It assumes the opposite of most coding agents: sessions on the same machine can read each other's transcripts and hand work over, /btw runs a side question in a read-only child session that answers in its own panel without entering the main conversation, and after a change passes its checks the diff goes to a separate read-only model that can block the turn.

Why it matters: Approval is decided by an independent reviewer model from your instruction rather than from a rule table, and dscode exec "prompt", or git diff | dscode exec "review this", runs a full turn in scripts and CI with the exit code reflecting the turn. That is what makes a coding agent usable as infrastructure rather than an interactive toy. Sub-agents that edit can work in Git worktrees created from a clean HEAD, and /delegate turns the main agent into a coordinator that plans onto a board and runs ready parts as children.

What changed: The reviewed permission preset auto was renamed auto-review in 0.7.28 because the harness now reserves auto for its own integration, so existing configs using auto need updating. Version 0.7.31 and 0.7.32 add an OpenCode Go route: /opencode login signs in with an OpenCode account and /provider opencode-go serves Go's chat-completions models. Qwen, MiniMax and Go's Grok and GPT models use other protocols and are not offered on that route.

For me: macOS 14+ and Node 22.19+ or 24+, so there is no Linux build. If you already pay for an OpenCode Go subscription, 0.7.31+ will spend it as an inference provider.

Tags: #topic/ai-coding #entity/dscode #technology/agent-orchestration #technology/multi-agent #event/agent-release #relevance/discovery #learning/awareness

Sources:

qiz029/dscode repository

Models and Capabilities

OpenDecider released Apache-2.0 decision models at 400M and 4B with a Jev-compatible server

OpenDecider shipped a family of open decision models on 2026-09-27 under Apache-2.0: opendecider-nano at roughly 400M parameters on an Ettin encoder and opendecider-small at 4B as a LoRA on Qwen3-4B. From version 0.3.0 it can serve Jev's /v1/systemone API directly, so existing Jev clients and TypeSafe's SDK work against it unchanged.

Why it matters: This is the third independent implementation of the SystemOne shape after TypeSafe's closed Jev and Laya's open weights, and the first built so the benchmark can be audited. The author ran every system on the same questions with the same scorer, published every logged answer, checked training pools for text overlap with all test sets and found zero overlaps, and removed a non-commercial dataset found during that audit.

What changed: On the 2,000-question typed-decisions suite scored with the published Jev-vs-Laya harness, the fine-tuned nano scores 0.796 against Laya's typed-decisions checkpoint at 0.766, a paired bootstrap 95% confidence interval of +0.014 to +0.044, and Jev at 0.754. Median latency is 17 ms on an L40S against 404 ms for Jev's API. The author's own caveats are load-bearing: opendecider-small is zero-shot on that suite and scores only 0.672, Jev still leads Laya's own application battery at 0.774, phishing is OpenDecider's weakest task at roughly 0.63, results are single training seeds, and the evaluation is English-only while Laya ships a multilingual checkpoint.

For me: The number worth reading is calibration, not accuracy: 0.087 to 0.092 ECE against Jev's 0.164. These models are meant to be thresholded, so on the most confident half of typed-decisions OpenDecider is 94 to 95% accurate against Jev's 88%. Note Laya's confidence barely separates right from wrong at any threshold, about 0.55 throughout, which is a warning about thresholding on confidence alone.

Tags: #topic/ai-models #entity/opendecider #technology/structured-output #event/model-release #relevance/discovery #learning/understand

Sources:

Open Source Momentum

Two separate analyses found a third of agent frameworks have not committed to their default branch in six months

An analysis published 2026-10-01 covering 669 open-source AI agent tools found 213 of them, 32%, with no commit on their default branch in six months or more, including 68 projects above 5,000 stars, among them MetaGPT at 70.7k stars last committed January 2026 and gpt-engineer at 55.1k last committed November 2024. It found the opposite failure mode too: hermes-agent with 32,240 default-branch commits in 90 days, OpenHuman 21,133, elizaOS 19,953, DeepSeek Harness 19,798 and LiteLLM 13,153, which is 150 to 360 commits a day. An independent August 2026 analysis of a different sample, 1,092 AI repositories above 10,000 stars, reached the same conclusion: 26%, or 223 repos, silent for over a month, and 63 silent for over a year while still holding 1.27 million stars between them.

Why it matters: Star count records past attention and never decays, so it tells you nothing about whether issues get answered or whether the project still works with this month's model APIs. Commit count, the usual alternative, is now unreliable in the opposite direction, because projects whose contributors are agents generate commits at a rate no human team produces and a commit count cannot separate a maintainer from a bot. Both signals only become readable next to releases in the last six months and median issue-close time.

For me: Vet an agent framework on last commit, releases in six months and median issue response, and treat raw commit count as a bot signal rather than a health one. Caveat on the first analysis: it is published by the operator of a commercial agent-ranking site, so its choice of 669 tools is self-serving, though its methodology is disclosed and the numbers are checkable against the GitHub API.

Tags: #topic/open-source #technology/git #event/github-traction #relevance/discovery #learning/understand

Sources:

Security That Affects You

CVE-2026-51874 records an unpatched arbitrary file write in Devika's Patcher Agent

CVE-2026-51874 was published 2026-10-01 for Devika v1.0, where save_code_to_project joins a model-chosen filename onto the project path with no boundary validation, so a crafted path writes files outside the project workspace. The public references are a research gist and GitHub issue stitionai/devika#709, both of which date from April 2026 rather than the October publication, and no patch is listed.

Why it matters: This is the write path, the part of an agent it owns end to end. The path does not come from the user, it comes from the model's own output, so injection upstream becomes a filesystem write downstream. The same repository shows the pattern repeated across the Coder, Feature and Patcher agents in issues #707, #709 and #716, and a maintainer reply on issue #712 in May 2026 states that the earlier CVE-2024-5752 fix applied secure_filename() to the REST endpoints but never to the user-message WebSocket handler. That handler runs with cors_allowed_origins="*", so a web page a developer visits can reach a locally running instance.

What changed: Nothing is fixed yet. The remediation is containment rather than sanitisation: resolve the target to an absolute path, then assert it starts with the resolved project root plus a separator before any open() for write. Rejecting .. or applying secure_filename() alone is not sufficient, which is exactly how the previous fix here came to be incomplete.

For me: Devika is dormant enough that this matters as a pattern rather than as risk in your own stack. It is the cleanest recent example of the write path being the attack surface, and the closest companion to the symlink case where an agent plants a link in its own project folder and mounts any host directory.

Tags: #topic/security #topic/ai-agents #entity/devika #technology/agent-security #event/security-issue #relevance/developer #learning/understand

Sources:

New Concepts

Agent-authored commits. When the contributors to a project are themselves agents, the usual health signals stop measuring what they were built to measure. Stars already record past attention rather than present activity, and commit counts now have the opposite problem, inflating to hundreds per day on projects nobody maintains by hand. Read commit volume as a bot signal, and pair it with release cadence and issue response time before concluding anything about whether a project is alive.

Tag Index

Topics

#topic/ai-agents
#topic/ai-coding
#topic/ai-models
#topic/devops
#topic/open-source
#topic/security

Entities

#entity/claude-code
#entity/cloudflare
#entity/devika
#entity/dscode
#entity/huggingface
#entity/k3s
#entity/microsoft
#entity/opendecider

Technologies

#technology/agent-orchestration
#technology/agent-security
#technology/agent-skills
#technology/containerization
#technology/finetuning
#technology/git
#technology/llm-api
#technology/mcp
#technology/multi-agent
#technology/self-hosting
#technology/structured-output

Events

#event/agent-release
#event/api-change
#event/github-traction
#event/model-release
#event/security-issue
#event/tool-release

Relevance

#relevance/ai-workflow
#relevance/developer
#relevance/discovery
#relevance/infrastructure

Learning

#learning/awareness
#learning/deep-dive
#learning/hands-on
#learning/understand