JoshPurtell

There could be a leak from post-training but not pre-training

gpt oss 20b is not dense

Codex is not far behind Claude Code

You most certainly should not have stuck with Conda

Have been testing this in dev and really like the performance so far

I concede that it is not precisely OSS. But if I tell someone that it is source-available, they will expect some kind of license restriction for any use. If I tell someone OSS, they will expect mostly what the Sentry license entails, unless they are a competitor, in which case I really don't care what they think.

I wish there were a popular term that conveys exactly how Sentry license works. But, there isn't - so I think it's fair to say open source, maybe as a general term. I'll change it from OSS to open source

What compile times do you work with? I use bazel and it still hurts

Billionaires and corporations can hire teams of people to work for them full-time. You, likely, can hire one or two (or zero!). Not to make it personal.

These inequalities already exist

I do both and compile times are very unfriendly to AI!

Why, because of the Sentry license?

Every AI advancement liberates real humans from drudgery and allows them to create what they want more easily.

The invention of the digital calculator turned human calculators into accountants, and that's great! We're contributing to the same process now

rlm-rs: https://crates.io/crates/rlm-rs src: https://github.com/synth-laboratories/Horizons

Monty is the missing link that's made me ship my rust-based RLM implementation - and I'm certain it'll come in handy in plenty of other contexts.

Just beware of panics!

Just like codex or opencode provide strong oss implementations of the core agent loop, our ambition (not achieved! hoping this is a solid start) is to provide a solid oss implementation of the context updating loop, memory, basic database + a backend sync layer. And evals + continual learning + gepa optimization.

Just like everyone can write their own agent, yet many opt for codex/claude code sdk/opencode, we think that at some point in our journey, many will also opt for standard implementations of these patterns, for projects big or small.

Realistically, though, the case for a standardized environment grows a lot stronger when you have multi-agent, permissioned actions, and generally just a lot more state than what you can get away with using only opencode + some glue. Insofar as big teams have ambitious products, they might be more likely to try it

It's 2026, just use Planetscale Postgres

Completely absent of substance

From Sama "More Texans use ChatGPT for free than total people use Claude in the US, so we have a differently-shaped problem than they do"

Facts don't care about your feelings

Important to note Anthropic has next to no consumer usage

This is super cool! Have you tried GEPA?

For devtools cos providing skills - we've found that using GEPA where you optimize the skill content instead of the prompt works really well to make sure the skill actually gets claude code/ codex /opencode to successfully use your service. https://arxiv.org/abs/2507.19457 More here if interesting https://www.usesynth.ai/blog/environment-pools-managed-agent...

As a demonstration, I've built Crafter in lean - and have hosted it on the web using Lithe

https://lean-crafter-production.up.railway.app/ https://github.com/JoshuaPurtell/lean-crafter

At some point in the future (if not already), claude will install malware less often on average. Just like waymos crash less frequently.

Once you accept that installation will be automated, standardized formats make a lot of sense. Big q is will this particular format, which seems solid, get adopted - probably mostly a timing question

lmao

I had a high opinion of PS before this comment.

Now I have a higher opinion of PS

Looks really good!

50% is not a vast majority, so that's a red herring

34% are between 18 and 65

Yeah, exactly, same prompt.

I agree, it's more complex. But, I feel like the potential with a claude code wrapper is precisely in enabling workflows that are a pain to self-implement but nonetheless are incredibly powerful

Something I'd consider a game-changer would be making it really easy to kick off multiple claude instances to tackle a large researched task and then to view the results and collect them into a final research document.

IME no matter how well I prompt, a single claude/codex will never get a successful implementation of a significant feature single-shot. However, what does work is having 5 Claudes try it, reading the code and cherry picking the diff segments I like into one franken-spec I give to a final claude instance with essentially just "please implement something like this"

It's super manual nd annoying with git work-trees for me, but sounds like your setup could make it slick

FWIW, if this sounds like arcane academic musing ... applied mechanism design for a while was essentially just the study of google ad auctions, and Google invested very very heavily in researchers to figure out how to do this for them