Key points
- Goldman — Goldman Sachs has reportedly pulled Claude Code away from bankers and traders, consolidating coding-agent use back into its engineering organization.
- Willison — Simon Willison says that in a plain Claude Chat, he had Claude Opus 5.5 Medium port a Three.js 3D demo he had written earlier in the same conversation into a native JavaScript and WebGL version.
Your Daily AI Stew from Robin, on Salty Talk.
Goldman Sachs reportedly revokes bankers’ and traders’ Claude Code access, keeping the tools for roughly 12,000 engineers
Goldman Sachs has reportedly pulled Claude Code away from bankers and traders, consolidating coding-agent use back into its engineering organization.
According to the reports, Goldman Sachs is clawing back Claude Code access from bankers and traders, visibly tightening the deployment of Anthropic’s coding agent inside the investment bank. The concerns cited in the reporting include security, compliance, governance, and cost control. To be clear: this item comes from second-hand reporting — there is no first-party announcement from Goldman Sachs, so the exact scope of the pullback, its effective date, and whether an operational incident triggered it cannot be confirmed from the available material. Even so, a strictly regulated financial institution tightening who can use coding agents is a notable signal in itself.
Tools like Claude Code and GitHub Copilot do not just return text in a chat window; they can generate and execute code right on the work machine. Putting them inside a bank means governing execution permissions, data access, account authorization, audit trails, and approval flows. Goldman had previously extended these tools beyond software engineering — bankers and traders used them for market models and client money-flow work — and the reported October guidance narrowed access to roughly 12,000 engineers, moving from a broad pilot to tighter governance.
The reported outcome: Goldman’s bankers and traders lose Claude Code and GitHub Copilot, both advanced tools are reserved for roughly 12,000 engineers, and the bank’s exposure on security, compliance, authorization, and billing goes down accordingly.
Discussion in the comments focused on risk: semi-unattended agents running on financial practitioners’ machines, with reach into sensitive data, email, the internet, and the intranet all at once. One institution said it restricted Claude over recurring billing overruns and prefers Gemini’s more predictable billing and rate-limiting behavior. Others pointed to banks’ requirements around authorization, audit trails, approval chains, and privacy, plus legal and regulatory exposure. Some speculated about an operational loss, or about whether Goldman’s timing was tied to Anthropic’s IPO, but offered no evidence.
Placed into the current enterprise AI picture, this item asks not which model is stronger, but who can account for where a coding agent is running, with what permissions, and touching which data once it enters a regulated business environment. The reporting does not say whether the pullback followed a specific incident, nor what conditions would reopen access; and in the same discussions, operational differences like billing and rate limiting prove just as decisive for how long a tool survives inside a financial institution.
If the reports hold, the key point is not the ban itself but the enterprise redrawing the boundary around agent tools. A coding agent that can execute commands locally and reach the system environment is governed completely differently from a Q&A assistant that only generates text in a web box; fencing the former back into the engineering team is the cheapest defensive move a strictly regulated institution can make against unknown risk. It also suggests that the earlier rollout to business roles was more of a stress test than a settled decision. What to watch next: when Goldman confirms this first-hand, and whether other large financial institutions follow the same tightening.
Kimi-K3.1-Pro-Coder experimental mixed-precision quantization squeezes 1.77TB down to 775GB
The open-source community has published a quantization experiment that compresses the 2.8-trillion-parameter Kimi-K3.1-Pro-Coder from 1.77TB to 775GB.
An author has published an experimental mixed-precision quantization of the 2.8-trillion-parameter Kimi-K3.1-Pro-Coder: size drops from 1.77TB to 775GB, a 56% reduction. The approach stores routed MoE experts at three precision tiers, while shared experts, attention, and embeddings stay in BF16 or F32. The three tiers are 2.81, 2.56, and 1.44 bpw, averaging about 1.92 bpw, versus roughly 4.0 bpw for the base model.
Alongside it comes Strata, an offload engine layered over GPU VRAM, pinned host memory, and NVMe that prefetches using router lookahead, plus dr-triton’s fused dequantization kernels. Testing ran on a single Colab NVIDIA RTX PRO 6000 Blackwell with 96/102GB VRAM and 176GB system memory, covering all 93 layers plus lm_head: AIME 2025 and LiveCodeBench both scored 29/30 — 96.67%; top-1 token agreement was 95.20% and top-5 was 99.92%; throughput was 36.8 TPS at batch and 10.8 TPS single-stream. Perplexity shifts were +1.01% on AIME, +2.02% on hard LiveCodeBench, and +2.67% on LiveCodeBench overall.
The setup is incompatible with stock llama.cpp or vLLM because it uses a custom packed tensor layout. Users can configure Strata to their own VRAM, memory, and NVMe mix, and can plug the standalone dequantization module into their own PyTorch or Triton runners.
Kimi K3.1 Pro is Moonshot AI’s 2.8-trillion-parameter open-weight MoE model, post-trained from Kimi K3 with a 1-million-token context window. Each token activates only a subset of routed experts, but the full expert set still has to be stored, and at inference time it may need to be moved between devices. Mixed-bitwidth quantization assigns different precisions to different experts to compress storage; tiered offloading keeps hot weights in VRAM, warm ones in memory, cold ones on NVMe, and hides transfer latency with prefetching.
The author positions the result as an experimental stress test rather than a deployment recipe: the 775GB download and the hardware bar still stand in the way, and every number is self-reported.
That is why its value is closer to a feasibility proof: the three bitwidth tiers quantify the acceptable quality loss, and tiered offloading turns “not enough VRAM” into an engineering tuning problem — at the cost of replacing the whole toolchain. To actually run these weights, beyond storage and memory, you must accept a weight layout that only a handful of runners understand.
The real merit of this experiment is that the author published a complete ledger of what the compression costs in accuracy and speed instead of shouting a size percentage, leaving a reference frame for later reproduction. Still, because it depends on a custom tensor layout and a bespoke offload engine, no stock inference framework works out of the box, and reproducibility is largely bound to the author’s own companion scripts. What deserves watching next: whether mainstream inference frameworks absorb this tiered-quantization idea, and whether the dequantization module can settle into a standard component on its own.
Community developer ports a Windows AI training stack to Kepler-through-Turing cards, native CUDA Mamba-1 now works
A developer has ported a Windows AI training stack onto old NVIDIA GPUs, letting a ten-year-old Tesla K40c run a native CUDA build of Mamba-1.
A community developer has ported a Windows AI training stack to NVIDIA cards from Kepler through Turing (SM 3.5 to SM 7.5). The package includes a custom PyTorch 2.7.1 wheel compiled with CUDA 11.8 that preserves legacy SASS, plus causal-conv1d 1.7.0, a native CUDA Mamba-1, and NCCL on Windows for distributed data-parallel training across Kepler cards.
The developer reports that the pure-CUDA Mamba-1 implementation works on the target architectures: on a 2013 Tesla K40c, the maximum absolute error relative to the PyTorch reference implementation was 3.8e-06. Mamba-2 and Mamba-3 remain limited to Turing (SM 7.5) and newer because they depend on Triton and TileLang; on older cards they fall back to Mamba-1 automatically when those modules are unavailable.
The project’s author hopes more people will test on Maxwell and Pascal, since local verification only reached Kepler, and no broader benchmarks or performance data were provided. As a self-reported announcement, availability beyond that single K40c — and the claimed performance — still need community validation.
Mechanically, Mamba is a state-space sequence model designed for information-dense workloads like language modeling, leaning on hardware-aware kernels for speed. The native CUDA Mamba-1 bypasses the newer paths’ dependency on Triton and TileLang, which is why it runs on Kepler-through-Turing cards that most modern AI stacks no longer support. The port stitches together legacy-SASS PyTorch 2.7.1 Windows builds with CUDA 11.8, causal-conv1d, and NCCL.
Put another way, the significance of this route is not benchmark glory but bringing a cohort of cards abandoned by the mainstream toolchain back into the training loop: the missing Windows wheels, kernels, and communication libraries were each rebuilt, with their applicability boundaries stated. Whether these machines can actually sustain training throughput, the author gave no data and no cross-arch claim.
The port also makes a reverse point: many old compute cards were retired by modern training frameworks not because the silicon lost its ability to compute, but because the software toolchain selectively gave up on them. Hand-written pure CUDA dodging modern compiler dependencies does open a survival path for old cards, but this reads more like a hacker-style feasibility exploration than a production-safe plan. For labs holding aging compute assets, it offers a low-cost alternative worth trying; what matters next is whether community testing on other architectures can back up its stability.
Simon Willison has Claude port a 3D demo to native JavaScript and WebGL
Simon Willison ran a public experiment, having Claude port his earlier Three.js 3D demo to native JavaScript and WebGL.
Simon Willison says that in a plain Claude Chat, he had Claude Opus 5.5 Medium port a Three.js 3D demo he had written earlier in the same conversation into a native JavaScript and WebGL version. He published all three artifacts: the original 77KB Three.js version, the 98KB port, and the transcript of that conversation. The two outputs are not identical, and Willison says he does not fully understand where they differ.
He did an informal comparison and felt the Three.js version’s code was slightly more readable; he also notes that he rarely reads the code for projects like this anyway, so this is more a personal demonstration than a systematic benchmark.
The paired, directly openable artifacts plus the conversation log make this a checkable case study in AI-assisted porting. The raw material cannot prove the result is reproducible, that outputs are consistent, or that development workflows have changed more broadly.
What is worth noticing is how he recorded the differences: not a line like “the model is strong,” but both versions and the process laid out side by side, letting you judge for yourself which reads better and where the differences appear. This checkable posture says more about what today’s models can do for a person — and where they cannot explain themselves — than any benchmark verdict would.
The core value of this case is the candid presentation of the whole process: conversation context and paired artifacts all published, giving skeptics a rare, complete thread for review. The author himself admits he is not an expert in that stack and that the two outputs do not fully align, which cleanly bounds the demonstration as a single exploratory sample rather than a productivity claim. What deserves tracking next: whether other developers following the exact same prompt and process get consistent outputs on cross-graphics-stack ports.
Willison folds agent-written PR descriptions, leaving only a human-written lead on top
Facing verbose PR descriptions generated by coding agents, Simon Willison now uses collapsible tags to tuck the machine detail under a human summary.
Coding agents like Claude Code and Codex now open plenty of PRs for Simon Willison: packaging commits, recording decisions, writing up verification. The descriptions are accurate and thorough, but their density reads like machine-generated filler that even he does not want to read — so a human-curated layer is needed on top, without losing the useful detail.
His approach: put the agent’s full write-up inside GitHub’s supported details and summary elements, which renders as a collapsible heading you can expand on demand; above it, he picks or drafts a short intro stating what the change is for and why it is worth a look, sometimes adding a screenshot to explain the new feature the fastest way. The detailed description stays in the fold, and the summary names the model — sometimes the effort level too, like Claude Opus 5.5 Medium — so the text’s provenance is always clear.
Recent examples all use the pattern: a redesigned table-row page, clearer pagination, an on-demand loading edit script, a plugin hook, and a command for managing OpenAI-compatible endpoints.
The technique does not discard AI-generated detail; it reorganizes the PR around a human-confirmed summary, keeping completeness while making the page easier to scan — unlike a full page of unreadable generated text.
More worth remembering is his stance on the tools: the agent writes the process down in full, the human decides what readers see first. The first screen a reviewer sees is written by a person, with the machine’s full evidence below — accountability and traceability are not folded away.
The trick is a very pragmatic answer to agent-generated text overload: rather than forcing the model to shrink necessary detail, it restores a human review rhythm with a curated lead plus collapsible tags. More instructive still is keeping the model version and thinking effort inside the fold — effectively a lightweight watermark and provenance mechanism for machine-generated content. Worth watching is whether, as multi-agent collaboration spreads through team R&D, this habit of labeling the responsible party becomes a common collaboration norm.
Today’s five items: on one side, a heavily regulated institution re-measuring the permission boundaries and governance costs of coding agents; on the other, developers squeezing large models to their limits, reviving old hardware for training, and probing the human-machine collaboration boundary in daily work. Technology is sinking in, engineering is getting pragmatic.
🎧 This episode is also available as a podcast: listen to Daily AI Stew · 2026-11-09.