> tool call pruning breaks cache and people will tell you this is horrible and expensive
> except i looked at some anthropic data and real user behavior ends up with better cache hits and 30% less spend
> even this is needs to be analyzed further, it's just not simple
> for openai data it's inverted! cache hit ratio is actually better [sic: I think he meant worse based on the screenshot] with tool call pruning turned on
> but the net $ saved is only 5%
> kimi is a funny one - it has better cache hits with pruning on...but is also more expensive!
There was also another thread recently where he discussed that pruning improves user experience (models are smarter with less context) but I can't find it.
Again, did you read the order? The judge's order explicitly said this would be legal and cites the law permitting it, then goes on to explain why this action did not satisfy it:
> Covered procurement actions include “[t]he decision to withhold consent for a contractor to subcontract with a particular source or to direct a contractor . . . to exclude a particular source from consideration for a subcontract.” 10 U.S.C. § 3252(d)(2)(C).
They can say "sorry Palantir, we will only sign a contract with you if you commit not to use Claude to provide services" and then Palantir is free to decide if they want to accept the terms of the contract or not. This is how business works.
Did you read the order? It directly addresses your comment:
> More importantly, as discussed above, no one is entitled to conduct business with the Federal Government, see Perkins, 310 U.S. at 127, and irrespective of the challenged actions, DoW and other federal agencies are free to terminate its contracts and agreements with Anthropic, as Anthropic readily admits.
It essentially depends on how many back-and-forth calls are required. If the model returns a request for multiple calls at once, then the reply can contain all responses and you only pay once.
If the model requests tool calls one-by-one (e.g. because it needs to see the response from the previous call before deciding on the next) then you have to pay for each back-and-forth.
If you look at popular coding harnesses, they all use careful prompting to try to encourage models to do the former as much as possible. For example opencode shouts "USING THE BATCH TOOL WILL MAKE THE USER HAPPY" [1] and even tells the model it did a good job when it uses it [2].
That's correct. Input caching helps, but even then at e.g. 800k tokens with all of them cached, the API price is $0.50 * 0.8 = $0.40 per request, which adds up really fast. A "request" can be e.g. a single tool call response, so you can easily end up making many $0.40 requests per minute.
An interesting thing to understand about Klarna and other buy-now-pay-later products is that a major part of their profit is the very high merchant fees they charge; retailers have to pay ~2-4x what they do for credit cards if they want to offer Klarna. 57% of Klarna's profit comes from these merchant fees compared to just 24% from loan interest [1].
It turns out it's worth it to merchants because when you're not paying now, you end up buying more than you would otherwise. Order sizes are ~15% higher [2]. Probably similar to how it hurts more to pay with cash than debit because it's so tangible.
I view it kinda similar to gambling apps with their endlessly optimized special offers designed to exploit the human monkey brain.
The main other problem is that the kernel doesn't register default signal handlers for signals like SIGTERM if the process is PID 1. So if your process doesn't register its own signal handlers, it's hard to kill (you have to use SIGKILL). I'm sure anyone who has used Docker a lot has run into containers that seem to just ignore signals -- this is the usual reason why.
> also, why can't the real pid1 do it? it sees all the processes after all.
How would the real PID 1 know if it _should_ reap the zombie? It's normal to have some zombie processes -- they're just processes whose exit statuses haven't been reaped yet. If you force-reaped a zombie you could break a program that just hasn't yet gotten around to checking the status of a subprocess it spawned.
This is a neat visualization. It makes me want to build something like this with actual screenshots (scraping from places like old forums, image hosting sites, etc.) rather than web page renderings.
One of my most prized possessions is my collection of personal screenshots -- I've managed to save basically every screenshot I've taken over the past ~20 years. It's very nostalgic to put them on shuffle and see how my desktop has changed over time, remember what random thing I was working on, etc.
Could be cool to extend the concept beyond one user.
> Lina Khan and the US government in general blocked all kinds of tech acquisition and merger to the point that companies got creative and as a result many Windsurf employees got screwed. On the other hand, it's totally normal that a handful companies control our food supply chain.
Lina Khan's FTC also successfully sued to block the Kroger-Albertsons merger...
Knowing you will get paid back (i.e. credit worthiness) is part of it, but another part is that the currency holds its value, and the global demand for dollars is an important part of that. If the global demand for dollars decreases, then borrowing is more expensive because you need to offer a higher interest rate to entice people to purchase bonds, because they have other more attractive options to store/grow their money than US bonds.
One way to think of it is that the US benefits from the current world order by essentially taxing the rest of the world to pay for its spending by devaluing their currencies relative to the dollar.
Sorry but your point is just completely wrong and I am not sure why you have this belief. It is extremely normal and safe to backup SQLite via block device or filesystem snapshots. Are you under the impression that SQLite cannot recover from a power loss...? The whole point of using a log is that you can recover from crashes mid-way through updating the database file by replaying the writes from the log.
If it will convince you, I went and asked ChatGPT like you recommended and it agrees:
> If you want to use snapshots:
> Use a filesystem or block-level snapshot tool that guarantees a point-in-time, atomic snapshot (e.g., LVM snapshots, ZFS snapshots, Btrfs snapshots, or VSS on Windows).
If you were going to "Tell SQLite to create checkpoint (write the WAL contents to the main DB) and suspend writes" as you suggest is necessary, why even bother with a snapshot at that point?
> There are plenty of competing browsers and search engines, they all suck.
Maybe our difference in viewpoint is that I see this fact and wonder why it's seemingly impossible for anyone to build a financially viable alternative, and I'm at least open to the idea that it's very difficult to compete with Google when they can leverage their successful ads business to subsidize the investment into their browser.
Yes the alternatives are worse, but is that because Google is inherently smarter, or because the newcomers have a tiny fraction of the investment and usually fizzle out within a year or two? Google doesn't have to be actively trying to kill the competitors for it to have an anti-competitive effect in the market.
Isn't "monopolies suppress competition" one of the classic reasons people think they should be broken up? I'm not saying you have to agree with that theory, but just observing a current lack of competition doesn't by itself seem like an argument against breakup.
It would probably be more accurate to say that LastPass has the information to decrypt your vault if they can guess your password. By contrast 1Password would need to both guess your password and guess your personal secret key. The latter is effectively impossible assuming the key generation was well-implemented. The trade-off is that users must keep track of their own secret keys.
LastPass does not use the secret key concept that 1Password uses, it only uses a key derived from your password. After the breach they rushed to increase the hash iterations [1] and added features to let enterprise admins set minimum iterations [2] but of course it was too late at that point.
I have the exact same issue too and wish I had a name for it. I had been assuming it was related to astigmatism since I also have issues with low-light environments especially with reflections (e.g. hate watching TV in a dark room, don't like driving at night especially in rain) but it seems like others who have this issue aren't mentioning it so now I'm doubting that.
A little bummed seeing how hostile most of the comments here are but I guess it's to be expected if most commenters are seeing very differently than how I and the author are.
> tool call pruning breaks cache and people will tell you this is horrible and expensive
> except i looked at some anthropic data and real user behavior ends up with better cache hits and 30% less spend
> even this is needs to be analyzed further, it's just not simple
> for openai data it's inverted! cache hit ratio is actually better [sic: I think he meant worse based on the screenshot] with tool call pruning turned on
> but the net $ saved is only 5%
> kimi is a funny one - it has better cache hits with pruning on...but is also more expensive!
There was also another thread recently where he discussed that pruning improves user experience (models are smarter with less context) but I can't find it.
This can also be disabled in the config: https://opencode.ai/docs/config/#compaction