AI Weekly Malaysia

PostHog published Jeeves, an open-source reasoning classifier built on Qwen3.5-9B with LoRA plus a pointer head, trained with SFT and CISPO, and shipped with full training code and train/dev/test data. It reports 0.889 accuracy on held-out out-of-domain test data (vs Kev-9B 0.822 and Jev 0.857) and 0.935 on JevBench's 231 public items (vs Jev 0.866), using a block-4 diffusion drafter and a Jev-compatible API supporting noul/choice/score questions. Latency is about 0.3 s per request without thinking and a 3.3 s median with thinking on a single H100 at --precision fp8; it runs on CUDA bf16, FP8 on compute capability 8.9+, and Apple Silicon MPS. The thread drew 239 points and 93 comments on Hacker News.

Why: The headline numbers hide a regression: Jeeves scores 0.746 on Transfer (MMLU-Pro and buried state) versus Jev's 0.800, and 0.793 on MMLU versus Jev's 0.900, so reasoning-before-deciding helps on the benchmarks it targets and hurts on general transfer tasks. If you currently fall back to a reasoning model when a Jev-like classifier is uncertain, the 3.3 s median thinking latency versus 0.3 s without means that fallback costs roughly an order of magnitude more wall-clock per request on one H100 at fp8 — decide per pipeline whether you truncate the chain, or keep the calibrated classifier and only reason on the hard slice. Because inference also runs on Apple Silicon in bf16 or FP8, you can benchmark it on a local Mac before paying for cloud GPU time.

ServiceNow CoreAI published a Hugging Face article describing AutoSynthData, a pipeline that uses a target model's failures plus a stronger teacher model's successes to pick what the model should learn next, then generates and validates new agentic tasks, shifting the curriculum toward whatever the model still finds hard. Tasks are formalised as a tuple of (system specification, user prompt, verifier), with the system spec covering instructions, environment policies and initialisation such as a seeded database state or knowledge articles, and generated tasks required to satisfy properties starting with feasibility. The pipeline is illustrated on the released EnterpriseOps Gym dataset (cited as Malay et al., 2026). The article text supplied is truncated mid-sentence in the feasibility section, so the remaining task properties and any results or benchmarks are not available here.

Why: The concrete constraint named here is the verifier: every generated task must ship with a reliable way to check whether the agent succeeded, and the post explicitly warns against adding arbitrary constraints just to manufacture difficulty. If you are fine-tuning an agent for a specific environment, that means the work is building a programmatic success check and a feasible task generator before any synthetic task volume is useful - generating hundreds of prompts without a verifier produces data you cannot score or train on. There is no Malaysia- or SEA-specific element in this text.

Ai2 released Olmo-core 3, an open training framework for large mixture-of-experts models that replaces the earlier FSDP setup (gathering and resharding weights each batch) with DDP that keeps experts resident on GPUs and routes data to them. In one benchmark, growing the expert pool from 8 to 128 while still selecting 4 experts per token and holding active parameters near 3.2B raised total capacity from 4.6B to 47B with less than 5% throughput loss; the same stack was benchmarked past one trillion total parameters. A tech report, code, and interactive demo were published with it, and the post positions it against NVIDIA's Megatron-Core.

Why: The usable number here is the ratio: roughly 10x total parameter capacity for under 5% throughput loss, which Ai2 attributes to the DDP resident-expert design rather than FSDP per-batch weight gathering. If you are picking a stack for any sparse/MoE training, that is the specific claim to reproduce on your own cluster before choosing Olmo-core 3 over Megatron-Core, because the routing and communication costs are what decide whether MoE actually saves you compute at your scale. For most readers who never train from scratch, the practical takeaway is narrower and honest: the open code and tech report document how expert-count scaling behaves, and the generation history (OlmoE at 64 routed experts, Olmo 3 dense, now this) shows Ai2 reversing its dense bet.

OpenAI published proposed guidelines for 'safety cases' for frontier reinforcement learning training, arguing that structured, evidence-based risk documentation should be required before continuing any frontier RL training run. The initial list covers three technical areas — alignment training, containment, and monitoring — with concrete practices including agent-driven automated dataset reviews to find broken RL environments, manual dataset review, grader tuning to penalize reward hacking, and classifiers run over traces from prior experiments to check graders behave as intended. OpenAI calls safety cases an 'aspirational north star' rather than a shipped process and invites community feedback; the text provided cuts off mid-sentence in the alignment-measurement section.

Why: This is a position paper from one lab, not a standard anyone must comply with, so nobody has to change a build today. The one reusable detail for anyone running RL or eval pipelines is the reward-hacking loop described here: agents scanning training environments for exploits, manual review of tasks that hand out high reward by accident, and classifiers over past run traces to verify graders. If you train or fine-tune with RL anywhere — including on hosted APIs — that checklist of failure modes is worth copying into your own eval hygiene. There is no Malaysian or SEA hook in this text, and no product, pricing, or API change for builders here.

OpenAI announced a partnership with America's SBDC — a US network of small business development centers that says it serves 1 million entrepreneurs a year — to train roughly 150 advisors through its OpenAI Academy Community Trainer Program, with a stated goal of reaching at least 1,000 small businesses via in-person workshops plus one-on-one advising. Alongside it, OpenAI published a report, 'Small Businesses, Bigger Capabilities', claiming that about 4 million small-firm employees worldwide used OpenAI tools in the single week of September 9-15. The pilot combines an advisor training and credentialing pathway with a separate facilitator pathway and a three-hour workshop module.

Why: This is OpenAI's own announcement about its own program and its own usage report, and it is entirely US-based, so nothing here changes what a Malaysian builder ships this week. The one detail worth extracting is the delivery model: advisors and facilitators get credentialed first, then workshops scale. If you sell AI tooling or run training to Malaysian SMEs, that is a distribution pattern you can copy or compete with — and the closest local equivalents (SME Corp, MDEC, state-level SME digitalisation programs) are the channels to watch for a similar program appearing here.