xcodevn

Install the latest claude code to use opus 4.7:

`claude install latest`

I have a strong feeling that this website was designed by Claude Code using the /frontend-design skill.

Example run: https://asciinema.org/a/udK1O06TS8f7kXNO

A Claude Code setup that implements ML papers from arxiv. Give it a paper, it orchestrates a team of AI agents to read the paper, plan the implementation, write the code, verify correctness, optimize performance, train, and compare results against the paper's claims.

The official document from Anthropic:

> Fast mode is not a different model. It uses the same Opus 4.6 with a different API configuration that prioritizes speed over cost efficiency. You get identical quality and capabilities, just faster responses.

They failed to grasp the very fundamental point of batching, which is sharing model weights between requests. For more context, this wasn't just one person's mistake, several AI twitter personalities proposed this 'Claude Opus fast = small batching' hypothesis. What I find funny is how confident these AI influencers were, while the people who actually work on LLM serving at frontier labs said nothing. The people who genuinely understand this and work at frontier labs stay quiet. The rest is simply noise.

I do think Claude Code as a tool gave Anthropic some advantages over others. They have plan mode, todolist, askUserQuestion tools, hooks, etc., which greatly extend Opus's capabilities. Agree that others (Codex, Cursor) also quickly copy these features, but this is the nature of the race, and Anthropic has to keep innovating to maintain its edge over others

I did something similar in Python, in case people want to see a slightly different perspective (I was aiming for a minimal agent library with built-in tools, similar to the Claude Agent SDK):

https://github.com/NTT123/nano-agent

For one, these models should be able to understand the physical world via images, audio, and video. I do agree that current models are quite good at coding, but that's mainly because coding is entirely text-based and easily verifiable. It's not obvious that this capability will transfer to other domains that aren't text-based and aren't as easily verifiable.

> we may have AI that is more capable than everyone in only 1-2 years

There's no evidence this will be the case...

I'm not familiar with these open-source models. My bias is that they're heavily benchmaxxing and not really helpful in practice. Can someone with a lot of experience using these, as well as Claude Opus 4.5 or Codex 5.2 models, confirm whether they're actually on the same level? Or are they not that useful in practice?

P.S. I realize Qwen3-Max-Thinking isn't actually an open-weight model (only accessible via API), but I'm still curious how it compares.

IIRC, the Claude Code creator mentioned that all the PRs are reviewed by humans, just like normal human PRs. So yes, humans still look at the code at the review stage. Though I still consider this to be level 3, but anyway, this is just a matter of definition.

I believe Anthropic is already doing Level 3 vibe coding for >90% of their code.

My observation is that vibe-coded applications are significantly lower quality than traditional software. Anthropic software (which they claim to be 90% vibe coded) is extremely buggy, especially the UI.

Over the weekend, I wrote this small Python library to teach myself the core idea behind modern agentic systems. This kind of software sits at the core of Claude Code, Codex, etc. I wanted to see if I could build it from scratch, so this is mostly educational for me.

The result is a surprisingly simple piece of software. At its core are immutable DAGs, which keep the design simple and easy to reason about.

I also added a set of built-in tools that are inspired by Claude Code's built-in tools.

A bonus point: it can also capture Claude Code auth tokens, so you can use it with your Claude Code subscription. However, there is a chance that Anthropic will ban you if they detect this, so use it at your own risk.

P.S.: One additional point I also want to mention is that Claude Code (SDK) is closed-source, so I cannot modify it for my use case or fix its buggy UI on my own. This is one of the factors for why I'm creating this library.

> only ~1/3 of sessions see at least a flicker.

...after many months, for such a visible bug, is such a crazy thing to say.

In case the above comes across as too hostile, to balance this, I would say thank you to the claude code team for such an amazing product!

I have a hypothesis: they haven't fixed this because they're using Claude Code to develop Claude Code. I'm a fan of Claude Code, but it isn't good enough to fix tricky issues like this. And because no one looks at the codebase themselves, they haven't been able to fix it after many months. Sometimes, all we need is an engineer to sit down for the weekend and fix the damn bug, not spin up 9 different Claude Agents prompted to fix itself.

Interesting, i can see this being very similar to Nvidia's CUTE DSL. This hints that we are converging to a (local) optimal design for Python-based DSL kernel programming.

> Once the model is fully released, scientists will be able to adapt and fine-tune it on their own datasets to better tackle their unique research questions.

This is in the press release, so they are going to release the weights.

Author here: (1) We didn't remove the stddev term. (2) We use token-level loss (every token has the same weight), which is very similar to what Dr. GRPO does. However, we compute the mean gradient per token, while Dr. GRPO computes the sum. Typically, these are equivalent. However, since we're also doing gradient accumulation over micro-batches to reduce memory usage during training, this led to a bug in our implementation: it gives more weight to tokens in short sequences than to those in long sequences.

Interestingly, this is the same bug that most open-source LLM training frameworks (such as HF Trainer) had and only recently fixed.

In short, I'm working on a quick fix, after that, using sum or mean should yield equivalent results.

P.S. Fixed!

On a very similar theme, here is the work from World Lab (founded by Fei-Fei Li, ImageNet dataset, et al.) about creating 3D worlds:

https://www.worldlabs.ai/blog

Who cares? If it brings benefits to the people who paid for the service, duh!

He plays an essential role as the model for NotebookLM. As Raiza Martin, the PM for NotebookLM, mentioned on a recent podcast, Steven is the product. The NotebookLM team essentially emulated his workflow, how he conducts research and compiles information on a particular topic.

For context, the author is Steven Johnson, one of the key people behind Google's latest hit, NotebookLM.

For those who are curious, how can we technically support really long context window (like in the millions or even billions)? The short answer is simple: we can just use more GPUs. The long answer is detailed in my recent note here: https://neuralblog.github.io/scaling-up-self-attention-infer...

During inference, it is not a matrix x matrix operation, but rather a weight matrix x input vector operation, as we are generating one token at a time. The bottleneck now is how fast we can load the weight matrix from memory to tensor cores, hence the need for weight quantization.

Look from a different point of view: this is a feature, not a bug. With this, every example has equal weight, while with the fix, every token has equal weight.

Looking forward to Hinton receiving a Fields Medal for inventing backpropagation.

If you're reading this, you may be interested in my other work on "Exploring Llama-3 MLP Neurons" as well.

https://neuralblog.github.io/llama3-neurons/

Yes, you're correct. The tokens are highlighted based on the neuron activation value, which is scaled to a range of 0 to 10.

On a related note: recently, I released a visualization of all MLP neurons inside the llama3 8B model. Here is an example "derivative" neuron which is triggered when talking about the derivative concept.

https://neuralblog.github.io/llama3-neurons/neuron_viewer.ht...