ClaudeBuzz

A curated showcase of whats cooking at frontier

[ClaudeBuzz @claudebuzzcom]

announcing claudebuzz!

https://t.co/urmKdnAxhc

[himanshu @himanshustwts]

Introducing Claudebuzz ⚡️

We have been living under a rock while people are shipping amazing things with claude. @claudebuzzcom is curated showcase of impressive projects, threads and high-taste stuffs.

Share what you've build!

[h100envy @h100envy]

Ex-NVIDIA engineer who built Unsloth explained RL, kernels, reasoning, quantization, and agents in 2 hours 42 minutes - better than $5000 fine-tuning bootcamps.

pick the base model -> write triton kernels for 2x faster fine-tune -> quantize to 4-bit -> run GRPO/DPO -> ship a reasoning model on your single GPU.

That loop is why Unsloth is the default way to fine-tune Llama, Qwen, Gemma, and Phi on hardware you already own.

Unsloth + Triton kernels + 4-bit quantization + GRPO/DPO + single-GPU fine-tuning - that's the stack.

Watch and save it, then fine-tune your first model tonight.

[Xiuyu Li @sheriyuo]

https://t.co/aJEXibSlmN

[Fei-Fei Li @drfeifei]

https://t.co/Kt50ttQRMJ

[Skyler Miao @SkylerMiao7]

Something BIG is coming

[George from 🕹prodmgmt.world @nurijanian]

A few weeks ago I hit my limit with Claude’s chart junk. So I handed it this book and had it spin up a Tufte-flavored skill - suddenly spitting out visuals that are leaner, clearer, and way nicer to look at.

https://t.co/7F77iTN2E9

[elie @eliebakouch]

scaling laws are beautiful and this is the best resource to understand them

https://t.co/SBN9I5PUBw

[himanshu @himanshustwts]

Today we introduce Physera to the world!

Physera is an applied research and product lab working at the intersection of model efficiency and behavioural simulations.

We are rethinking each layer of AI stack from first principles.

1. We believe there has been no better time to scale capabilities of frontier models with efficient architectures.
2. Simulating human decision-making with high-fidelity and multimodal environments.
3. Translating human judgment into models. We think the frontier of prediction has always been gated by the number of controlled variables we can simulate.

We're looking for thoughtful folks to help shape this vision. Happy to chat!

[will brown @willcb]

https://t.co/gCIFKAjB0Z

[Sam Hogan 🇺🇸 @samhogan]

We’re introducing HALO 😇

Hierarchal Agent Loop Optimizer

HALO is an RLM-based agent optimization technique capable of recursively self-improving agents by analyzing their execution traces and suggesting changes.

This work is inspired by the Mismanaged Genius Hypothesis proposed by @a1zhang and @lateinteraction earlier this month.

tldr; we improved performance on AppWorld (Sonnet 4.6) from 73.7 --> 89.5 (+15.8) by giving HALO-RLM access to harness trace data and asking it to identify issues.

The feedback from HALO surfaced failures in the harness such as hallucinated tool calls, redundant arguments in tools, refusal loops, and semantic correctness issues. Each issue mapped cleanly to a direct prompt update.

We then fed these finding into Cursor (Opus 4.6), and asked the coding agent to update the underlying harness.

We repeated this trace -> HALO-RLM analysis -> code update loop until the score plateaued.

Today we’re open-sourcing the core HALO-RLM framework, evals, and data for further review.

[alex zhang @a1zhang]

New mini experiment + blogpost + trajectories!

tldr; we boost performance of RLM(GPT-5.2) to double the best performing number (38.7% --> 65.6%) on LongCoT-mini without any training! An example of the mismanaged geniuses hypothesis (MGH) we (@zli11010, @lateinteraction) proposed earlier this month.

The LongCoT benchmark showed that frontier LMs and RLMs struggled to solve difficult compositional reasoning tasks. The paper generally attributes this to the RLMs inability to perform task decomposition, but we argue this is more our fault in how we prompt them; this capability is fully available to GPT-5.2 with an RLM harness!

Building on @raw_works's insightful blogpost and @sumeetrm / @CharlieLondon02 et al.'s incredibly useful benchmark, where they originally found RLMs to be incapable of solving the MATH and CS splits altogether. We did not train anything since the release of the initial benchmark.

To be fully transparent, these results are not meant to be added to their leaderboard either; benchmarks measure isolated capabilities, and we focus on showing (through different, rather specific prompting) that the capabilities required to solve these tasks are available to the models without additional training! It also has implications about how we would go about training these systems. Full blog below, it's a nice read :)

[Zain Shah @zan2434]

Imagine every pixel on your screen, streamed live directly from a model. No HTML, no layout engine, no code. Just exactly what you want to see.

@eddiejiao_obj, @drewocarr and I built a prototype to see how this could actually work, and set out to make it real. We're calling it Flipbook. (1/5)

[Murray Kang @haoqik322]

Looped transformer and Energy-based Models (EBMs) are closely related:

•EBM inference: x ← x − η∇E(x)
•Looped transformer: x ← x + block(x) (residual form)

These are literally the same algorithm if block(x) = −η∇E(x) for some scalar E.

This equivalence isn’t automatic — a generic transformer block is not the gradient of any scalar (its Jacobian isn’t symmetric, and gradients must have symmetric Hessians). Dmitry provided a solution to this.

I like the perspective to understand/build the looped transformer as an EBM inference process by gradient descent. The looping isn’t just reusing weights for efficiency — it’s the optimization procedure of the EBM itself.

[Hayden Prairie @hayden_prairie]

We’ve been thinking a lot about scaling laws, wondering if there is a more effective way to scale FLOPs without increasing parameters.

Turns out the answer is YES – by looping blocks of layers during training. We find that predictable scaling laws exist for layer looping, allowing us to use looping to achieve the quality of a Transformer twice the size.

Our scaling laws suggest that for a fixed parameter budget, data and looping should be increased in tandem!

🧵👇

[Anthropic @AnthropicAI]

Introducing Project Glasswing: an urgent initiative to help secure the world’s most critical software.

It’s powered by our newest frontier model, Claude Mythos Preview, which can find software vulnerabilities better than all but the most skilled humans.
https://t.co/NQ7IfEtYk7

[himanshu @himanshustwts]

The Arcee AI Podcast is here!

In this episode, @latkins and @stochasticchasm join us to discuss the story of Trinity models and everything frontier. I can say, this talk has been one of the most amazing and technical conversations we've had on Ground Zero.

0:00:00 - Intro
0:00:59 - Varun's transition from SWE to Pre-Training Lead
0:04:20 - Trinity Manifesto, Openclaw Ecosystem 0:12:15 - Arcee's Post-Training to Pre-Training Pivot 0:23:45 - Varun's first Pre-Training run (you can just do things!)
0:27:33 - Saturation in Pre-Training?, Mid-Training 0:37:00 - Tweaking the Training Architecture, Adam vs Muon, Evals
01:09:07 - Inference Engineering, Quick Fire, Post-Training Recipe
01:18:02 - Alpha in RL Envs, Harness Design
01:23:00 - American Open Source is trailing Chinese Competitors, Trinity Adoption
01:29:25 - Hiring at Arcee, Advice to 20yo

[Sophia Yang @sophiamyang]

🎙️Designing a speech-to-speech assistant
- Voxtral Transcribe 2 for STT + diarization
- Mistral Small 4 for agentic reasoning & efficiency
- Voxtral TTS for realistic speech synthesis

Build a speech-to-speech assistant with web search access in 150 lines of code.

[Gauri Gupta @gauri__gupta]

https://t.co/gpEE2rstjm

[Chujie Zheng @ChujieZheng]

We are planning to open-source the Qwen3.6 models (particularly medium-sized versions) to facilitate local deployment and customization for developers. Please vote for the model size you are **most** anticipating—the community’s voice is vital to us!

[himanshu @himanshustwts]

Claude Code has an interesting recipe for "Compaction". This is how it works:

[again, shared by claude code]

Claude Code is not doing “one compaction”. It has three layers and each layer handles a different kind of overload.

> Layers
+ MicroCompact (Cheap, Every Turn)
+ Session Memory Compact (Medium, No API Call)
+ Legacy Compact (Expensive, Full Summarization)

+ effective window = model window (reserved)
+ auto-compact trigger = effective window (13K tokens)
+ manual blocking limit = effective window (3K tokens)
+ the system tried to compact *before* hitting the hard prompt-too-long wall

> There is a “cheap compaction” path on every single turn
+ runs before every API request
+ saves tokens without changing the actual conversation structure

> The real compaction path is boundary-based
+ Claude is asked to summarize prior conversation
+ the old transcript is not rewritten or deleted

> Session memory compaction is tried *first*
+ rebuilds context from that file + recent messages
+ no model call needed
+ only if that fails does it fall back to full summarization

> Resume only loaded the world *after* the last boundary
+ once found, pre-boundary payload is dropped from the in-memory load buffer
+ on resume, Claude sees only post-boundary context

> The smartest trick is preserved-tail relinking
+ compaction does not just keep a summary
+ it also keeps a preserved tail of recent live messages
+ on resume, that tail is stitched back onto the summary chain

> So “compaction” is really a pipeline trim cheap tool-result bloat
+ threshold check → decide if full compaction is needed
+ disk-backed summary first
+ legacy compact → ask Claude to summarize if needed
+ append compact boundary → future loads start from there

> What users experienced as “Claude forgot”
+ is usually not deletion
+ it is boundary truncation
+ summary substitution
+ and tail preservation trying to keep the active working set alive

[himanshu @himanshustwts]

Claude just verified the leaked codebase with last 14 updates pushed to Claude Code in one month