InvidFlower

I did try Herdr but found too many things I expected it to have and just didn't. Right now I've been switching between two different approaches for combined local and remote work.

There's the more traditional tmux/zellij way. I have a tailscale and mosh and a script where I can say something like "cw api do-this-feature" and it'll go into the folder of my api, create a worktree, and fire up claude code to use it (and another tab with lazygit and delta so I can do side-by-size diffs). And modified tmux's defaults so the session & window names are more targeted. Then can have it in Ghostty locally or Moshi (https://getmoshi.app/) on my phone. Moshi is basically a terminal for iOS but geared toward doing agentic stuff. Has a lot of shortcuts you can add for common commands of tmux, CC, can pinch to change font size, has a built-in diff tool, etc. Also has a small hook you can put in your agent so you get notifications on your phone. And it can directly open the particular tmux/zellij/herdr pane from that (has specific support for those three).

So that approach is nice in that you get full access to the harnesses, with no worries that a wrapper has a bug or doesn't support some new feature. But it still doesn't flow as well for me as a "real" wrapper does.

For the real wrapper approach, I started with Happy (https://happy.engineering/) and currently am using Happier (https://happier.dev/). Unlike Moshi, these are open source and basically control the various harnesses and have their own UI. Also have a relay so tailscale isn't necessarily needed, along with encryption in such a way that the person owning the relay can't decrypt the sessions. Happier even has a desktop app. Right now I'm running the dev version of Happier from source on my own machine w/ tailscale, with the testflight version of the app. There's various rough-around-the-edges aspects (and they're currently in the middle of a re-write), but it is nice to have a real UI with tabs for all your sessions, can click in to expand tool calls, to start a new session just select the harness, folder, type a new worktree name, etc and it starts going.

So I don't know. I like aspects of both of these and kind of depends on what I'm up to and my current mood. Nothing feels totally perfect yet IMO.

Don't forget the employees doing the actual model training and research are not the same ones coding Claude Code. CC was a side-project by one employee that ended up hitting it big and is now one of the core parts of their income. They were never a software company per se. This is like how MidJourney was just on Discord forever, because no one on the team was a real web developer. Discord made it easy to get something out there, scale up to many users, etc.

As the other person mentioned, they have said they are restricting third-party agent systems like OpenClaw and Hermes from using the monthly plan. But yeah, this seems like the wrong way to handle it, trying to detect those other harnesses via clues, and auto-changing billing. Instead, seems like it'd be better to allows vs block, like require some special encrypted signature system or similar that only Claude Code and their desktop app implement. Any other requests just get immediately blocked. Then there's a separate key for normal pay-by-the-token usage that is just unrestricted. Would make things waaaay clearer.

I'm not sure if the context limit on the $25/m, and model-size limit on the $100/m would make it not work well enough for OpenCode, but Featherless AI seems a bit unique in terms of how they handle their inference plans.

They've said publicly that they don't want apps like OpenClaw (Hermes is a variation) being used with a monthly plan vs per-token billing. The problem is this was implemented pretty badly (trying to regex??). And they should put a firm boundary between the two. It shouldn't be trying to switch over to a different billing plan automatically using the same api key.

I think they wanted to try not to totally lock down the monthly plan for non-agent uses, but that makes it all too fuzzy. They should use some specific method like encrypted signatures or something, so that anything sending to the monthly plan that isn't Claude Code or the desktop Claude app just errors out and be done with it.

Yeah, at the least it should alert the user that it is happening. Maybe the thinking was alerting it gives people signal on how to get around the restrictions, but having it silently charge from a different bucket isn't the answer either.

I think part of the issue is they were letting people use plan's API for random stuff, so people could do testing or small projects. Then the agents came along and exploded the cost, so they want to restrict those but still let some other usage, which I don't think is tenable.

I'm sure there is some way that they could enforce that all calls are coming from the Claude app or Claude Code. It might be hard to 100% enforce, with stuff running on a user's machine, but they could still could make it quite difficult, where someone has to be intentionally trying beat the system (like stealing encryption keys out of the Claude Code binary or something).

Also could run on a more generic cloud inference or gpu site. At least to see how well it works for your use-case before spending on hardware.

For the topic of remote control, Happy seems to be working pretty well for Claude Code but is also supposed to support Codex. It's a bit rough around the edges, but nice that it is open source: https://github.com/slopus/happy

I'm not so sure about that. Like we're using Claude Code with Bedrock and have most things on AWS with SOC2 compliance and all that. Normally switching to Codex would have a ton of friction in terms of separate contract and billing, worrying about data retention, etc.

But with Codex and GPT5.5 having generally good reviews, when it goes on Bedrock, it would be very simple for us to just try it out. Obviously there's the general friction of knowledge and comfort of Claude Code vs Codex, but that seems possible to overcome depending on the differential of the models and also of the features. Like if Codex gets remote control for Bedrock, that'd be a big advantage over Claude Code on it.

No, you definitely don't have access to the weights. The raw weights are secret enough that when a model hits a certain level of capability, their guidelines are that they need enough procedures in place to try to keep nation states from being able to hack in and steal the weights.

I think cost is fairly similar. As for who wants it, enterprise stuff is a big thing, but it also seems very reliable. Have never had any rate restrictions or had it just be down, which it sounds like a lot of people have issues with for Anthropic's servers.

Besides what the other person mentioned about being more useful for enterprise, I also heard mentioned on a podcast that gpt-image-2 uses the same general architecture as the LLM models, while Sora was a very different architecture. So they don't need two different sets of everything by shutting down Sora.

Given the topic of this article, we've been using Claude Code pointed at Bedrock and have never had any scaling issues. Obviously it is more expensive paying by the token than a monthly plan, but I sometimes have 2 or 3 instances chugging along with Opus 4.7 or Sonnet 4.6 and have never had it be down or error out due to usage limits.

While that is cool in principal, I'm not sure how well it'd actually work in reality. First, there is the technical challenge. My understanding is the weights can have a lot of fluctuation, especially early on. How do we actually determine how much influence a given piece of content has on the final weights?

Then if we get past that, my suspicion is that you could game the training. Like have as much of the process happen via public domain sources or pay-once licenses. That would cover a lot of the fundamental knowledge and processes. Then you could fine-tune on copyrighted data. That might actually make it easier to see how much influence on the final weights that content has, but is also would probably be a lot less influence. There's a big difference between a painting of an apple being the main contribution to the concept of "apple" in an image model, vs mention of that painting corresponding to a few weights that just reference a bunch of other concepts that were learned via open data.

There's been some work on memory lately like Transformer² and Titans. But that may not be necessary for decent agents. Even the "context in a loop" is getting better as general reliability of tasks increases, and as people find better ways to manage context. Like Cline has the Memory Bank prompt where there's a folder of markdown files at diff levels of abstractions of info on the project, current feature, current task progress, etc. And so it can update those files and read from them as a consistent memory.

I think you'll get a lot of use from this video from Andrej Karpathy: https://www.youtube.com/watch?v=7xTGNNLPyMI

It is long, but don't get scared off. He goes over a ton of different stuff related to model training, but makes it very easy to understand.

We've already seen Qwen's new QWQ 32B (not distilled) model doing impressive things on benchmarks. It'll definitely be interesting to see how just good small models can get. When combined with rag and large context window for expanded knowledge, might be able to get pretty far.

Well, not sure if that part matters as much (from first principles). But the more important part being that RL lets a model figure out which methods are effective for it. Most of the time it probably has the tools already from pre-training, but doesn't "make the connection" to use them (or at least not often enough).

While it is nice to have more options, it still definitely isn't at a human level yet for hard to read text. Still haven't seen anything that can deal with something like this very well: https://i.imgur.com/n2sBFdJ.jpeg

If I remember right, Gemini actually was the closest as far as accuracy of the parts where it "behaved", but it'd start to go off the rails and reword things at the end of larger paragraphs. Maybe if the image was broken up into smaller chunks. In comparison, Mistral for the most part (besides on one particular line for some reason) sticks to the same number of words, but gets a lot wrong on the specifics.

It is confusing, but they have diff calls for pdfs vs images. In their example google colab: https://colab.research.google.com/drive/11NdqWVwC_TtJyKT6cmu...

The first couple of sections are for pdfs and you need to skip all that (search for "And Image files...") to find the image extraction portion. Basically it needs ImageURLChunk instead of DocumentURLChunk.