jswny

Does anyone do TLA style distributed systems verification with Lean? Curious the experience there and how well supported it is

Unfortunately I’ve used Claude and GPT models for a long time in a variety of harnesses and I agree with you and I think it’s the compaction.

For some reason, codex compaction is like black magic. I’ve never felt like I can just one one continuous thread with other models, Claude I carefully curate when I compact

I agree with some of Kelley’s takes, but the issue is the tone.

Does anyone think that if Bun had been rewritten from Rust to Zig that a member of the Rust core team would have written a personal hit piece against Sumner (while pretending it isn’t a hit piece)? Probably not.

Kelley can write what he wants, but as the BDFL of a rising programming language, people are allowed to react if they don’t agree with the public image being portrayed by Zig.

What’s the advantage of that for building?

Why not WASM?

Codex is fully open source…

You want to use the model that is potentially giving your data to the government vs the one that’s openly rejecting that partnership?

Package a skill with your CLI itself and give users instructions on how to install the skill properly. That allows the agent to read the instructions in a context efficient way when it wants to use the CLI

Plenty of MCPs require you to install and run them locally, like I said remote MCP has a real advantage over CLI tho

MCP loads all tools immediately. CLI does not because it’s not auto exposed to the agent, got have more control of how the context of which tools exist, and how to deliver that context.

MCP is fine, particular remote MCP which is the lowest friction way to get access to some hosted service with auth handled for you.

However, MCP is context bloat and not very good compared to CLIs + skills mechanically. With a CLI you get the ability to filter/pipe (regular Unix bash) without having to expand the entire tool call every single time in context.

CLIs also let you use heredoc for complex inputs that are otherwise hard to escape.

CLIs can easily generate skills from the —help output, and add agent specific instructions on top. That means you can give the agent all the instructions it needs to know how to use the tools, what tools exist, lazy loaded, and without bloating the context window with all the tools upfront (yes, I know tool search in Claude partially solves this).

CLIs also don’t have to run persistent processes like MCP but can if needed

Can you explain what’s so different about pro?

I’ve used everything frontier model and had Pro a while ago but it seemed to just be the same models served faster at the time.

How do you get sub agents to work?

That’s just spawning multiple parallel explore agents instructed to look at different things, and then compiling results

That’s a pretty basic functionality in Claude code

What’s the point of having a public GitHub repo with PRs enabled if they will never merge any of them?

How do you know/toggle which API path you are using?

How does this work for other models that aren’t OpenAI models

Ah I think it’s because I was testing with an external library in the top level TOML metadata

The problem is that only Deno can type check single file scripts. Otherwise with Node and Bun you need a project to use tsc. Python can type check single file scripts (even with PEP 723 deps) with ty. Otherwise, I love TS for scripting, especially with Bun shell

I wish this was faster, in my tests it’s about 200ms startup consistently on my M4 MacBook. Otherwise very cool

Bun has a lot of this built in, plus Bun shell

Not memory, I just instruct it to freely experiment with temporary scripts and artifacts in a specific folder.

This helps it organize temporary things it does like debugging scripts and lets it (or me) reference/build on them later, without filling the context window. Nothing fancy, just a bit of organization that collects in a repo (Git ignored)

Can you give an example of how beads would be used by Claude to do something it otherwise couldn’t? I can’t quite tell what it is useful for

I also specifically instruct Claude how to use a globally git ignored scratch folder “tmp” in each repo. Curious what your approach is

Very interesting project! I have 2 questions:

1. How has it been working with ACP? Is it anywhere near feature parity with Claude code’s native interface?

2. I see your repo is written in Python which is interesting to me for a responsive TUI. Is it snappy and performant and if so what gave you done to make it feel native? And why did you choose Python?

So only opportunities with a path to economic profitability should be researched?

That is a very narrow view of advancing society

I would not recommend this. A hook that modifies files causes Claude to have to re-read the file before modifying it again, which can build up your context window fast

They have an entire feature for this: https://www.claude.com/blog/skills

CLAUDE.md should only be for persistent reminders that are useful in 100% of your sessions

Otherwise, you should use skills, especially if CLAUDE.md gets too long.

Also just as a note, Claude already supports lazy loaded separate CLAUDE.md files that you place in subdirectories. It will read those if it dips into those dirs

Can’t any donation platform you don’t fully control cut you off at any point?

What exactly is different about GitHub sponsors here?

I don’t think people are questioning the move away from a gigacorp owned platform, but it’s the approach, the alternative chosen, and the brash language that are being questioned