AI Weekly Malaysia

Cloudflare released two Cloudflare-trained "decision models" — Clef and Clef-flash — hosted on Workers AI, open-sourced on Hugging Face under Apache 2.0, and made Jev-API compatible with Typesafe AI's Jev System One. Decision models return bounded, typed outputs with probabilities (e.g. 95% fashion, 85% ecommerce, <1% phishing) instead of open-ended text, and Cloudflare says Clef currently leads the Jev Decision Index. Cloudflare also debuted an RL product for fine-tuning Clef, and reported its own Threat Intelligence workflow classified a domain in 2.2s with Clef versus 4.7s for gpt-oss-120b, which returned only two classifications.

Why: If you are routing tickets, escalations, or domain/page categories inside an agent loop, a classifier that returns typed labels plus probabilities lets your code branch deterministically instead of parsing LLM prose — and since Clef is Apache 2.0 on Hugging Face you can self-host and test it without committing to Workers AI billing. Treat the 2.2s vs 4.7s figure as vendor-reported on Cloudflare's own Threat Intelligence workflow, so benchmark it on your own inputs before swapping out a prompt-based classifier. The new RL fine-tuning option is the piece to evaluate if your label set is domain-specific and you don't want to retrain a full classifier each time categories change.

Cloudflare released Vinext 1.0, a Vite-based runtime that runs existing Next.js apps (both Pages and App Router) and deploys them to Cloudflare Workers' free plan, Netlify, or AWS Lambda. It began in February as a week-long AI-driven experiment and now reports over 99% test compatibility with Next.js, excluding cache components. Migration is two commands: `npx vinext check` and `npx vinext init`.

Why: If you run Next.js on Vercel and your bill or platform lock-in is a concern, this is a concrete escape hatch with a measurable compatibility claim you can test on your own repo in minutes via `npx vinext check` before committing to anything. The honest caveat is the one that matters most: the 99% figure excludes cache components, and the post itself admits replicating cache entry, rendered page, and future-request behavior around things like `revalidatePath` was the hardest part — so ISR/revalidation-heavy apps are exactly where you should verify manually rather than trust the number.

Cloudflare published the first public experimental preview of first-class support for the Emscripten wasm32-unknown-emscripten target in the wasm-bindgen toolchain, letting native Rust and Tokio-based applications run on Workers. The effort was started by Google over a year ago and later reviewed and supported by the Cloudflare engineers who maintain wasm-bindgen. To demonstrate it, the team got the Rust-native Minecraft server Pumpkin running inside a Durable Object with TCP ingress using real TCP sockets via Tokio; experimental patchsets and example repos are available now (Building Emscripten Rust Workers, running the Tokio async runtime in a Worker, TCP sockets with Emscripten and Tokio).

Why: Emscripten support uses Node.js compatibility flags to virtualize timers, filesystem operations, and sockets on Workers, which is the missing piece if you previously ruled out Workers for a Rust crate that needs std::net, file I/O, or a Tokio runtime. It is pre-release, so treat the patchsets as a prototype path for a Tokio service or a TCP-ingress Durable Object, not a production migration; if you have a Rust service you wanted at the edge but kept on containers because of missing native platform features, this is the moment to spike a port. No Malaysia-specific detail appears in the post, so local relevance is limited to teams already weighing Workers versus container hosting.

Cloudflare launched Workers KV Instant, a new mode of Workers KV that keeps the same get()/put()/list()/delete() API but runs on Quicksilver v2, the internal key-value store Cloudflare previously used only for its own products. Cloudflare reports p99 reads of 1.62 ms (vs 287 ms for classic KV across all reads, 160 ms cached), p99 write replication of ~256 ms (vs 4.38 s in classic mode), and sub-millisecond p95 reads, with writes pushed to 300+ edge locations. Cloudflare positions it for infrequently updated data like feature flags and application configuration, and states it is "not for every type of data"; the article excerpt does not include pricing, limits, or migration caveats.

Why: If you keep feature flags or app config in classic Workers KV, this is an API-compatible switch that removes the TTL wait and cuts p99 read latency from 287 ms to 1.62 ms — worth testing if config reads sit in your hot path. The catch is that Cloudflare itself scopes it to infrequently updated data, and this post gives no pricing or write-volume limits, so check those before moving anything write-heavy rather than assuming a free drop-in.

Cloudflare Workers now exposes post-quantum algorithms through Web Crypto: ML-KEM-768/1024 for key encapsulation and ML-DSA-44/65/87 for signatures, plus encapsulateBits(), decapsulateBits(), encapsulateKey(), decapsulateKey(), getPublicKey(), SubtleCrypto.supports(), and JWK import/export. The feature is opt-in behind the webcrypto_modern_algorithms compatibility flag because the underlying 'Modern Algorithms in the Web Cryptography API' draft community group report is still moving. Cloudflare's post by Thibault Meunier states explicitly that this is not a full migration path, only building blocks for validating an integration, and that ML-KEM output still needs to be fed into a key schedule and AEAD such as AES-GCM via something like HPKE.

Why: If you already bundle a JavaScript or WebAssembly post-quantum library into a Workers project, this is a chance to delete that dependency and test ML-KEM/ML-DSA against the runtime's own implementation instead. But the flag is named webcrypto_modern_algorithms and the spec is a draft, so treat it as an experiment branch, not a production key-exchange swap — Cloudflare itself says there is no complete migration path here. There is no Malaysian or Southeast Asian angle in this text; the relevance is purely for teams already running Workers.

Cloudflare launched Issues, built-in error monitoring for Cloudflare Workers, now in open beta, announced September 30, 2026. Enabling it takes one line of configuration with no SDK or app wrapper: it groups repeated uncaught exceptions, failed invocations, HTTP 5xx responses, console.log/console.error output, and stack-trace logs into a single issue showing first occurrence, frequency count, and trend, and also flags runaway alarm conditions and high-volume logging inside loops. Each issue can forward the error, stack trace, logs, traces, and Worker version to a configured coding agent, which can triage, query more data, or open a pull request — Cloudflare supplies a CF CLI prompt that diagnoses, fixes locally, runs checks, shows the diff, and asks before deploying.

Why: If your team already runs Workers, you can turn this on without adding instrumentation and stop hand-copying logs into your agent — the grouping is the real value, since the example given is one bug producing many different request IDs. If you are not on Workers, nothing here changes your stack. The demo prompt ends with 'Ask before deploying the fix', so if you wire an agent to this, decide the deploy gate yourself rather than assuming the agent will pause.

Cloudflare published a follow-up on Kitesurf, the browser it launched in August that runs entirely on Cloudflare Workers, and the headline change is WebMCP support: sites can expose callable tools (the post uses searchFlights() and Cloudflare Radar's navigate-to / set-location as examples) so agents call functions instead of simulating clicks. Kitesurf also added a batch of browser standards — CSS Layout, CSSOM, CSS Typed OM, custom elements, plus URL-based module resolution, JSON modules, and import map handling — aimed at rendering heavier JavaScript-chunked pages. You can try it in Cloudflare's public Kitesurf playground or point an agent at it via a chrome-devtools-mcp config using a wss:// browser-run devtools endpoint with browser=kitesurf and --category-experimental-webmcp.

Why: If you build or operate agents that touch websites, this gives you a concrete alternative to pixel-clicking: check the Application tab in DevTools on a target site to see whether it already publishes WebMCP tools, and if it does, wire your agent to call them. The MCP config in the post (chrome-devtools-mcp@latest pointed at the browser-run WebSocket endpoint with --category-experimental-webmcp) is copy-pasteable, so you can test tool-calling against Radar without running your own headless browser. Caveat: this is Cloudflare announcing its own product and the post claims Kitesurf is now 'more capable and more efficient' without publishing any benchmark numbers, so treat the efficiency claim as unverified.

Cloudflare announced that EuroLLM, covering all 24 official EU languages among 35 total, and Apertus, Switzerland's fully open model trained on more than 1,500 languages, are coming to Workers AI and can be requested today. It also launched workshops for government cyber agencies and critical infrastructure operators, with the first in Singapore in October, and repeated its sovereign-AI pitch around choice, open standards, and avoiding single-company dependency. The post cites Cloudflare's network running in more than 335 cities across 125+ countries, with AI inference GPUs in more than 230 cities.

Why: If you build multilingual AI for SEA users, the concrete next step is to request Workers AI access and benchmark EuroLLM/Apertus on your actual languages and tasks—Cloudflare gives no latency, price, or accuracy data here, so the sovereignty framing alone is not enough to switch. The October Singapore workshop is the nearest regional item for teams working with government cyber agencies or critical infrastructure, but treat this as a Cloudflare product announcement rather than independent evidence.

On October 1, 2026, Cloudflare announced a competition to build 'the next Git platform' on Cloudflare Workers and Artifacts, its versioned filesystem that speaks Git and can scale to millions of repositories. Artifacts is now in open beta and has added the ability to connect an Artifacts repository to a Worker through Workers Builds. The post argues agents will write code at scale and asks builders to create the coordination, review, and merge layer above Artifacts.

Why: If you build agent coding workflows or vibe-coding platforms, you can now test Artifacts in open beta for per-agent/session repositories and deploy an Artifacts repo via Workers Builds; the competition is a chance to prototype an agent-coordination layer. The excerpt gives no prize, deadline, or judging details, so treat it as an experiment, not a reason to migrate off GitHub.