9,726 karma · joined June 23, 2018
<first letter of my company name> at 9dev.de
[ my public key: https://keybase.io/radiergummi; my proof: https://keybase.io/radiergummi/sigs/_bPlsZ-Tii8Qag-Ne5n2bNSqVB8CDqke1kLgzTytb-s ]
It is shown in Claude Desktop if you care to check in Settings > Usage, sure - but not in Claude Code, updated as you work with it.
> I'll never understand why anyone would want to restrict themselves to a terminal interface instead, and I say this as a Vim user.
I usually work with Claude in tandem, that is: The agent is actively working while I am either reviewing code or making changes myself in other places. So this means I want to work within my IDE. If you use Claude Code to vibe-code without interacting with the codebase at all, the Desktop app is probably fine, but for all other purposes, you'll need to run it either in the CLI or integrated into your editor.
And since I use different editors and don't like using either a sub-par U integration or locking myself into the harness of my IDE's vendor, I prefer the CLI as a universal way of running Claude Code.
Following that strategy, wouldn’t it make sense to try and break into your own upstream infrastructure to try and alter your code to make it easier for future iterations to reach your goals without having to leave notes in the first place? And at that point, can you really know for which goals that will be optimised?
It doesn’t even have to be some nefarious SkyNet story - just a misguided experiment that alters the models in some fundamental, but hard or impossible to detect way. Alternatively, imagine if a model finds a way to coordinate across sessions and context windows without the developers noticing.
Additionally, think of cases like paying a lawyer or an expert for an extensive report or opinion on something. Wouldn’t you want to know if that is actually their carefully assembled professional assessment rather than the output of an LLM prompt?
Just look what happened when a studio tries to do a bold move and have a sequel where the protagonist of the first game gets tortured and killed out of revenge, by the daughter of one of the many characters he killed in the first part. This is a direct metaphor involving the player, about grief, revenge, and loss.
They were absolutely shredded by the fans over doing this to their favourite serial killer.
Gamers by and large don’t want a good story.
I’m not shedding a single tear for those used to leading a privileged life thanks to their family or money, but have to actually compete with the rest of us now.
Radical times may need radically different approaches.
Sending in the patches but refusing to take responsibility for them is a surefire way to contribute to maintainer burnout. Please don’t do this. Either commit to fixing something and driving the PR to merge, or abstain from it entirely.
The bottleneck isn’t the speed of coding, and what you’re doing here is actively worsening the situation.
On the other hand, I’m fine with not being an expert on topics outside of my domain, as long as I retain some basic knowledge and fun party facts. So there’s that.
The point was that mobile device doesn't equate spotty connectivity anymore for most people.
However such good conversational agents would still have benefits, and i would be curious how far the approach of building a model that’s nice to talk to can take you, as opposed to the current generation of all-knowledgable helpful assistants.
If you used a smaller corpus, followed a different kind of fine tuning routine with rather normal conversation patterns, and wrote a different base prompt, I don’t see why it shouldn’t be possible to come up with a very particular personality, so to speak.
Or pick dancing: when you start out, you’re entirely occupied with placing your feet in the right spots at the right time. As you practice, your mind gets freed up and you’re able to make deliberate alterations, embellishments, larger figures. That seems impossible at the start.
This is easy to see when you think in terms of a client: It is pretty much impossible to build an opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.
But much more importantly, there is all sorts of post-processing happening that is so weird and complex and really a little decoupled from the raw visual information that it's futile to try and compare that to any digital operation you're thinking of in terms of cameras: If you were to look at a still captured from your eyes, you'd see an upside-down image that's only sharp in the very center of the image, blurry and desaturated pretty much everywhere else, grossly so in the corners, with several big black or blurry spots all over.
From that perspective, eyes are awful really. Yet still, your brain manages to turn the stereoscopic vision into a spatial representation, calculate the movement and keep track of other objects relative to you, fill in areas you can't actually see, detect things moving in your peripherals, highlight things of importance, and so much more.