191–200 of 206 posts
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…
Earlier quoted context omitted.
Subscriptions are a very small part of their overall revenue (estimates have been between 5% and 20% based on financial reporting). Enterprise users are charged per-token, and maximal input/output tokens nets them maximal revenue.
They still want you to hit the cache because their margin is higher on cache hits. That's actual compute they don't have to pay for and they don't have to have capacity for because they are supply limited on the compute side. And the unit economics need to be there because there are competitors in the space. They can't just skin you on tokens or you'll jump ship.
I can imagine there are coding tasks where small edits to an existing huge codebase mostly consists of some small tool calls + processing a lot of input tokens, in e.g. a 20 to 1 ratio of input to output tokens.
https://github.com/anthropics/claude-code/issues/63930
This issue suggests that 74% of the charged input tokens could actually have been cache reads if claude code hadn't busted the cache. On the input side of things, this increased the cost (or count towards allowance) by ~3x (given that cost of cache write is 1.25 the unit price, and read is 0.1x the unit price).
OpenAI has a different cache pricing strategy, where cached reads are only 0.5x the cost, but cache writes do not cost extra.
Not sure how the unit economics play out claude vs openai, but it's safe to say that caching costs play a huuuge factor in this. It seems to be one of anthropic's USPs as a frontier-AI lab. They charge a premium for cache-writes (on top of the inflated token usage compared to OpenAI that was recently reported), but significantly discount the cache reads. The lack of care in tackling issues related to cache-busting is therefore really bad and suspicious.
Would be nice if it was easier to separate output that needs to live in context and stuff I just want to look at.
One thing I wasn’t aware of was the negative impact of switching models
What’s the point of running /clear vs starting a brand new session. At least with the latter I have session history, no? Pardon my ignorance since Claude isn’t my primary driver
As far as I've seen /clear is the same thing as starting a new session. If you type /resume right after clear, the first thing in the list is the session you just cleared.
Some versions of Claude Code had memory leaks. Therefore or was better to exit Claude Code and start a new session rather than /clear.
> @-mention files instead of naming them Love Claude, but the @ mention is broken in the desktop app. For the same project if I type the same query "@ephem" I get: CLI: https://imgur.com/a/VZMUCOa (good, relevant results) Desktop: https://imgur.com/a/QLSo4Ms (bad, irrelevant) Opened issue for this and it was automatically closed: https://github.com/anthropics/claude-code/issues/71421 I could have written the issue be…
I've shifted most of my usage to Codex/ChatGPT Work. The UX of appshots, browser annotations (now available in claude), and the computer use being so much less intrusive in OpenAI.
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?
I mean, it feels hard not to laugh at this type of blog post. My cynical interpretation is that this is a type of passing the buck to engineers in enterprise settings ("Stop spending tokens. Did you read the value maximization blog post? It is your fault.") Oh yes, Claude will do all sorts of different things -- it depends on how you use it! You should totally learn all of these little finicky things ... because now…
The bet with this blog post is that things WON'T be completely different in a few months time. I'm going to absorb things from this blog post, and the downside of my bet is the chance that none of this will apply.
Heh I will grant that three months is a looong time in llms hours :-)
Recently I came across the /handoff skill, which I've been using a lot. I find it much better than /compact. Basically: - /handoff file creates a short document with the important context from your current session and maybe next steps as checklist. - You can then start a fresh session with /continue file - You can also hand the work from Claude to ChatGPT, or the other way around. Very useful at time of session limit…
Earlier quoted context omitted.
> Plus your handoff files becomes a useful piece of project memory that you can reference later. I've been doing this since I started agentic development, and have a whole framework based on this; Simply put I define workflow s that output templated files for everytype of tasks that happens in development. It's a powerful pattern I'd recommend everyone.
Oh, so there's whole _skill_ for that! I now feel a bit silly but I reinvented the wheel during my last lil project and indeed found it very powerful. A variant of it is the "implementation (handover) prompt" when I conclude the planning session with plans and design documents, updated handoff, clean tree and a file for a new Opus implementing orchestrator (unusually do a single, highly specific implementer and a sin…