felixrieseberg

Ironically, this is the only part I was supposed to do by hand and didn’t give to Claude - making sure the HTTP redirects are setup correctly. Can’t believe I didn’t notice that. Anyway, you can blame dumb dumb me, not Claude.

I think we probably disagree on what level of abstraction means “personal”, but this website feels deeply personal to me. It existed in my head before it existed on a computer. I understand the argument that any form of expression needs to involve labor closer to the raw source material, but then again, I’ve never bought the argument that painters need to mix their own colors for a painting to be theirs. Having worked various layers of the web rendering stack, it also never made a lot of sense to me that you must use a certain layer to be considered “low enough”. Whenever someone claims that it’s JavaScript in Three.js, I immediately suspect, maybe unfairly, that the person has only the faintest idea of how many systems turn their loose instructions and turned them into pixels on their screen.

Hi, this is my team! Happy to answer any questions.

There's a lot in this launch, but the core idea is to simplify the product while giving users access to more capabilities. You no longer need to know ahead of time how much work a conversation might involve. If you're at your computer, Claude can use your local files and apps. If you close your laptop, Claude can keep working on its own computer.

This launch also lets you use Claude Design, Claude Docs, and Claude Slides directly from conversations. That's possible because we made Artifacts much more powerful: whenever Claude makes you an app, website, design system, or anything else, it can deploy an artifact with multiplayer features and databases.

As many of you probably know from your own work, giving users more power while making the experience simpler is really, really hard. It took many iterations to get to this version. We're far from done, but I expect people will be able to do much more while having to think about it less.

(I work at Anthropic)

Beyond all the benchmarks, I think Fable 5.1 is a big improvement in writing style. It sounds a lot less stereotypically like other Claude models, has (imho) a much more natural style, and responds to my style instructions more reliably. More work to be done (and we will!) but reading better prose makes me so much happier.

Another point I expect not to get much attention until it all happens at once is science. People have been correctly excited about the many "sudden" breakthroughs LLMs are making in Maths, but some of the science benchmarks make me believe we'll soon see similar developments in other scientific domains. Fable 5.1 more than doubled Fable 5's Terminal-Bench-Science [1] score, which I think is meaningful.

[1] https://github.com/harbor-framework/terminal-bench-science

I'll use this post as a shameless opportunity to tell more people about a little side project, I made:

http://languagemodelbuilder.com teaches you (in a few hours to days) how to build an LLM from scratch. It's entirely free, without accounts, and without data collection.

This is beautiful, the title alone gave me a good chuckle.

Thank you! I'll fix both of these pronto

Hi, Felix from Anthropic here. I work on Claude Cowork and Claude Code.

Claude Cowork uses the Claude Code agent harness running inside a Linux VM (with additional sandboxing, network controls, and filesystem mounts). We run that through Apple's virtualization framework or Microsoft's Host Compute System. This buys us three things we like a lot:

(1) A computer for Claude to write software in, because so many user problems can be solved really well by first writing custom-tailored scripts against whatever task you throw at it. We'd like that computer to not be _your_ computer so that Claude is free to configure it in the moment.

(2) Hard guarantees at the boundary: Other sandboxing solutions exist, but for a few reasons, none of them satisfy as much and allow us to make similarly sound guarantees about what Claude will be able to do and not to.

(3) As a product of 1+2, more safety for non-technical users. If you're reading this, you're probably equipped to evaluate whether or not a particular script or command is safe to run - but most humans aren't, and even the ones who are so often experience "approval fatigue". Not having to ask for approval is valuable.

It's a real trade-off though and I'm thankful for any feedback, including this one. We're reading all the comments and have some ideas on how to maybe make this better - for people who don't want to use Cowork at all, who don't want it inside a VM, or who just want a little bit more control. Thank you!

Hi, Felix here - I'm responsible for said Electron app, including Claude Code Desktop and Claude Cowork.

All technology choices are about trade-offs, and while our desktop app does actually include a decent amount of Rust, Swift, and Go, but I understand the question - it comes up a lot. Why use web technologies at all? And why ship your own engine? I've written a long-form version of answers to those questions here: https://www.electronjs.org/docs/latest/why-electron

To us, Electron is just a tool. We co-maintain it with a bunch of excellent other people but we're not precious about it - we might choose something different in the future.

Worth calling out that execution runs in a full virtual machine with only user-selected folders mounted in. CC itself runs, if the user set network rules, with https://github.com/anthropic-experimental/sandbox-runtime.

There is much more to do - and our docs reflect how early this is - but we're investing in making progress towards something that's "safe".

Oh, to be clear, I have a team of amazing humans and Claude working with me!

Hi, Felix from the team here, this is my product - let us know what you think. We're on purpose releasing this very early, we expect to rapidly iterate on it.

(We're also battling an unrelated Opus 4.5 inference incident right now, so you might not see Cowork in your client right away.)

Disclosure: I work at Anthropic, have worked on MCP

I also think this is pretty big. I think a problem we collectively have right now is that getting MCP closer to real user flows is pretty hard and requires a lot of handholding. Ideally, most users of MCP wouldn't even know that MCP is a thing - the same way your average user of the web has no idea about DNS/HTTP/WebSockets. They just know that the browser helps them look at puppy pictures, connect with friends, or get some work done.

I think this is a meaningful step in the direction of getting more people who'll never know or care about MCP to get value out of MCP.

Hey Neil, this is cool! If you package it up as a desktop extension (https://github.com/anthropics/dxt) and send it to me (https://docs.google.com/forms/d/e/1FAIpQLScHtjkiCNjpqnWtFLIQ...), I'd add it to Claude's directory of local MCP servers!

> Instead of competing with hundreds in the application pile, you reach decision-makers directly.

As a hiring manager, my inbox is already drowning. I don't mind the applications, I mind that most of them are _clearly_ not a good fit to the point where I'm confident that they themselves have not looked at the job posting for a single second.

The more tools like yours will be built, the more you'll have to know someone who knows me to even get a chat with me - because I won't browse through hundreds of automated messages just to find the one that isn't. I'll be honest: That'll create a tech world even more hostile to people without "the right connections" - and that makes me sad.

Ah, shoot, I had an error in my build script. That's now fixed!

https://github.com/felixrieseberg/clippy/releases/tag/v0.4.1

Yeah, reproducible builds would be fantastic.

I sign my binaries on macOS with Apple codesign and notarize - and with Microsoft's Azure trusted signing for Windows. Both operating systems will actually show you a lot of warning dialogs before running anything unsigned. It's far from perfect - but I do wish we'd get more into the habit of signing binaries, even if open source.

The real answer is that some of us (the Electron maintainers) have been playing with local LLMs in desktop apps and right now, node-llama-cpp is by far the easiest way to experiment - but it's also not meant for desktop apps and hence has _a lot_ of dependencies.

In general, pruning libraries in Electron isn't as easy as it should be - it's probably something for us to work on.

Daniel, congrats! I'm _so_ excited about everything y'all have achieved in the last few years.

Azure Trusted Signing is one of the best things Microsoft has done for app developers last year, I'm really happy with it. It's $9.99/month and open both to companies and individuals who can verify their identity (it used to only be companies). You really just call signtool.exe with a custom dll.

I wrote @electron/windows-sign specifically to cover it: https://github.com/electron/windows-sign

Reference implementation: https://github.com/felixrieseberg/windows95/blob/master/forg...

As an Electron maintainer, I'll re-iterate a warning I've told many people before: Your auto-updater and the underlying code-signing and notarization mechanisms are sacred. The recovery mechanisms for the entire system are extremely painful and often require embarrassing emails to customers. A compromised code-sign certificate is close to the top of my personal nightmares.

Dave and toDesktop have build a product that serves many people really well, but I'd encourage everyone building desktop software (no matter how, with or without toDesktop!) to really understand everything involved in compiling, signing, and releasing your builds. In my projects, I often make an argument against too much abstraction and long dependency chain in those processes.

If you're an Electron developer (like the apps mentioned), I recommend:

* Build with Electron Forge, which is maintained by Electron and uses @electron/windows-sign and @electron/osx-sign directly. No magic.

* For Windows signing, use Azure Trusted Signing, which signs just-in-time. That's relatively new and offers some additional recovery mechanisms in the worst case.

* You probably want to rotate your certificates if you ever gave anyone else access.

* Lastly, you should probably be the only one with the keys to your update server.

Notion (Editor) | Full-Time | NYC or SF | 2x/week in office

We're looking for a fullstack eng (if you lean FE/BE that's cool) who is interested in working on the product OR foundational layer of Notion's editor. You'll have a lot of opportunities to build expertise and ownership, and work on some of Notion's business critical projects (ask engineers working on Performance, Offline, CRDT, Editor quality, and AI editing).

Why does our team exist?

• We're here to build the best editor in the world. In 2025 we're focused on building an editor that's fast, collaborative, and offline

• We're also on a mission to build a healthy, fun, and collaborative team culture (ask us about karaoke, matcha, or our top spots in Japan)

• We own surfaces like CRDT, contentEditable, snapshot pipeline, slash menu, table blocks, etc.

Please feel free to reach out to me (fr@makenotion.com) if you're interested! If you'd like to learn about culture and day in the life, anybody in the Editor team would be happy to chat with you. You can find more about us on https://www.notion.com/careers.

It sounds like you're looking for CSS frameworks and plenty of them exist - Bootstrap for instance doesn't require you to use the JS part of it.

> In the vast and ever-evolving landscape of web development, certain projects not only capture the imagination of developers worldwide but also redefine the paradigms of design and functionality.

A bit of feedback: Seeing this amount of non-speak and arrogance in the first sentence of the "getting started" readme has me immediately tune out and put this project aside. If there is anything good here, I won't see it.

I wish the industry had a better answer for deterministically profiling the execution cost of JavaScript. Attempts were made in Chromium by hooking into Linux perf, but that change has since been removed.

If anyone has any tips on how to trace JavaScript (not just profile by time, but deterministically measure the cost of it in CI), I'd love to hear tips!

> Electron does not support encryption or protected file locations by default

Jesus, this article is wrong on so many levels. Electron is fundamentally a way to build cross-platform apps with C, C++, and web technologies. It supports anything the operating system supports.

I like 1Password's secure starter kit: https://github.com/1Password/electron-secure-defaults

It's a common test to ensure you're truly comfortable with your decisions and actions: If a major newspaper would describe your actions or quote you directly on their front page tomorrow, would you still stand behind those words and actions?

The "test" is much older than Stripe but we often use it as a shorthand to ask ourselves whether we truly think a certain course of action is the right one.

You seem to misunderstand the original request _and_ the proposal. We so far only have the CCC's request, no further details are known.

If you go by the proposal, FOSS and Open Source is out of scope. In the case of Log4j, companies knowingly selling software that contains in insecure version of Log4j now need to own that defect.

Before you pick up pitchforks, it's important to understand that this has been requested by the reputable Chaos Computer Club for years.

It's targeted at commercial proprietary software with disclosed and unfixed vulnerabilities. In other words, if you're knowingly selling software that materially harms your users, you're on the hook.

As an example: You're buying "Foo Professional" from MegaCorp. It contains an insecure version of Log4j. You're paying MegaCorp $500,000 per year for license fees. MegaCorp refuses to patch the used version of Log4j. With this proposal, you now have a legal basis for arguing that you _deserve_ a fixed version of "Foo Professional" unless MegaCorp told you clearly by which date "Foo Professional" expired.

I think that's a sensible way to think about it.

It's cute. Well done!

James Friend is the one who got the C compiled with Emscripten, and as long as you're able to serve an entire disk image from a server (and don't crumble under the bandwidth), a browser is good enough.

Electron is only here to ensure that state is saved (save a game, quit the app, start the app, your save game is still there) and to make the mounting of disk images and transfer of files from your local machine super easy.