reddmachine

I'm unclear about how exactly we tax AI. Do we do it per token? Do we tax the companies that use AI? Or provide AI? Do you tax training data brokers or training/inference compute providers? It's unclear who you want to tax.

I don't think this is real. Twitter readers flagged the OP as fabricating statements. I wouldn't believe this until it was corroborated by someone more legitimate.

That's really impressive for the model class. Almost like Sonnet 5.5. I'm yet to try this out though. What do other people think about this?

This seems like a good idea. Essentially back up your Claude and Codex apps with a mini-cloud of sorts with auth, storage and compute standardized. I'd built something similar at my old company for TPMs to build simple CRUD applications.

That being said, how do you differ from something like Charming which is a similar offering? Or even a more E2E offering like a Replit or Lovable?

Oddly enough, deciding to not have any more original thoughts going forward is an original thought.

That being said, every new idea I've had seems to have already been executed successfully 3 months ago by someone else, so I get what you're trying to say.

But to an extent you need to be delusional enough to believe in yourself in order to have an original thought.

Thank you kind Sir. You are a gentleman and a scholar.

I don't think the problem with healthy food is that it's out of reach of most people's budgets, it's likely that takes time to break out of bad habits. Junk food is too chemically perfect to be easily replaced, in some cases not having it can create withdrawal. Not too many people have the will or desire to cook and eat healthy food at all to begin with.

This is a well written piece with thorough analyses. Thanks for the datapoint about Jev not working well for Entity matching use cases, it likely that it wasn't trained on this specific use case. It's possible that a 2-tower architecture works well for this case as compared to Jev's noul type.

You might have better success using a network of multiple decision models as compared to a one-shot since that you have more of a budget compared to the GPT models. That being said, you could try fine-tuning Laya models or some Qwen 4B models. Also, did you try the GPT-6-Luna decisions API?

This looks promising. I'd like to see something around potential cost savings for a typical end-user. The permissions section of the README could be made more user-friendly as well. Good work otherwise!

There will be a point when something breaks, right? There will be a point when some feature bloats UX tests, breaks existing features or takes up too much space.

At some point you will see a decline or even silence from your user base since the experience changed too quickly or their workflows broke. That when you'll need to cut back and argue about what really makes sense.

Since you're in a growth phase(looking at your star counts), keep going until you spot the signs I guess.

Play/pause functionality seems like a good use case for this button. Congrats on finding a way to re-map it.

If I were you I'd map it to either: 1. New terminal 2. New agent 3. Switch desktop window/workspace

That being said, I love what you've done already.

This seems really cool. A simple syntax, a cool display layout and in general a better customer experience. I think agents could better operate these style of commands as well.

If this is kinda backward compatible with bash or zsh, it would be a drop in replacement for me.

This looks interesting since there's no guarantee that current models set up linters. This would be cool if it exists as a bot on GitHub.

That being said, please pick a better name!

I think this should kick in before any code is written not before any code is pushed. It's an odd thing to check before pushing new code.

Also, from my experience implementing something similar, an MCQ style makes people guess without really understanding.

I feed it back to AI to respond with em-dashes, en-dashes and clearly Claude-like writing.