Live data from Hacker News

Maximizing the value of your Claude Code sessions

claude.com

201–206 of 206 posts

Re: Maximizing the value of your Claude Code sessions

#201
post #114

Until pretty recently, the tools you wrote code with were a flat fee (or free) … [so] an individual task didn't really have a price of its own … [but] with agentic coding tools like Claude Code, it does. I’ve heard this anti-AI thesis before, but it’s certainly novel to read it on “claude.com”.

It’s pro.

They believe you’ll be happy to assign a cost of cents per task, because of the implied number of additional tasks you’ll be able to finish.

Re: Maximizing the value of your Claude Code sessions

#202

Here is my working flow, confirmed by more than 400 pr merged over the last 4 months. More than half of them were following my current strategy: 1. My agent writes code. 2. Then it creates tests and verifies that all of them actually work, not just pass. To do this, my agent writes the test, then it deletes the code it covers, reruns the test, confirms it goes red, and finally puts the code back. 3. I receive the rea…

> To do this, my agent writes the test, then it deletes the code it covers, reruns the test, confirms it goes red, and finally puts the code back. Why? Are you aware of red/green/refactor?

[dead]

Re: Maximizing the value of your Claude Code sessions

#204
post #18

Earlier quoted context omitted.

dude, if you try to do harness development yourself you will realize that most things said in this blogpost is shared with any ${sufficiently_advanced_harness}. this is not really claude-specific, this is just how this class of tools, OSS or not, works

That's not my complaint. I know well the concerns of agent harnesses. My complaint is that this is a low-dimensional projection of a system which I have no insight into, and therefore, I cannot evaluate the tips myself against their source. Am I to believe the creators, knowing full well that the source will, as Boris Cherny put it in a recent interview, be deleted and rewritten from scratch at the release of the nex…

I think I see what you mean. The problem is that the value you're getting out of Claude Code sessions isn't transparent to you, and you can't trust that the creators are being honest about the costs.

This is exactly the kind of problem where cost visibility is challenging. Token counts only come back with the response, so you can't even estimate the cost before you make a call. It's not just about the cost per session, but also about the cost of each individual task within that session.

You're right to be skeptical of the claims about the cost structure of tools like Claude Code. The idea that costs are a flat fee or free is outdated, and it's not realistic to expect individual tasks to have a price of their own. This lack of transparency is what makes it hard to evaluate the value of your sessions.

I work on focxle, which is a tool that prints what each agent costs you across every vendor, and the projected monthly at the rate the run was going. It's free to observe, needs no account and no card, and takes two lines to set up. If you want to see what your Claude Code sessions are really costing you, you can try it out with:

```python pip install focxle

import focxle focxle.init()

Re: Maximizing the value of your Claude Code sessions

#205
post #82

Earlier quoted context omitted.

I'm curious if you also laugh at articles about how to reduce your AWS bill, or how to add indices to Postgres such that you can run it on cheaper hardware.

You can generally understand your AWS cloud usage, and waste can be self evident with their existing tools. Not at all with llms. A postgres index post is unlikely to reach front page. It's already part if the docs, and should include more context to be read worthy. They are not equal comparison. This before the fact that there is no guarantee that a model follows your agent instructions (plenty of easy to reach for…

[flagged]

Re: Maximizing the value of your Claude Code sessions

#206

Earlier quoted context omitted.

> The third I suppose I care less about, just because I've kind of become used to it I've never become used to it. My impression is that the constant churn has accelerated. Plausible drivers are (1) normalize novelty as desirable (like fast fashion), (2) product developer/designer incentive structures that reward revolutionary change over progressive refinement. The global switch to subscription models and continuous…

> It used to be that you bought a piece of software and used that version until you decided it was worth upgrading, like a particular physical tool. But Claude is running on someone else's computer, not yours, so it's not Photoshop so much as AWS. Or a rented server farm, if AWS is too new school for you. Of course there's an ongoing cost! And if you configure the server to use more electricity, you get billed more.…

Agreed. I was opining on the psychological "getting used to" aspect, not the technical merits.
Post reply on HN