Yeah, it doesn’t make a whole lot of sense. Over hundreds of hours of Claude Code use, I’ve never had this problem.

I feel like people just jam poorly specified input into LLMs and hope for the best. Then pile more tools on top when they don’t get what they want.

It's not that there's a cost to generating them -- per say. I wouldn't want an LLM generating UUIDs anyways. I think it's the cost of consuming them in conversation context that is the issue.

The problem is really more getting the agent to reliable relay a UUID. For example, we were creating files for visualizations and having the agent reference them in there response with a custom <visualization file=UUID /> and found that it would often fail to accurately return a UUID from a tool response it was previously provided (running sonnet 4.6).

For this use case, our solution was just to use a slug for the filename, but we can control the uniqueness constraint on our backend.

I haven't encountered this exact problem but I have had LLMs make occasional transcription errors when "copying" hex strings around (e.g. cryptographic constants). They make surprisingly human-like mistakes e.g. a transposed pair of digits, which can be annoying to track down.

But this seems orthogonal to token usage, and if I was designing an "LLM-friendly UUID" it would have some additional checksum data, to detect transcription errors.

I thought the same thing, and was wondering if this wouldn't even cause more drift and hallucination as these tokens will have stronger relations within the model as opposed to the UUIDv4 that probably gets dropped as noise (correctly so).

the machines this is designed for are stupid. this makes them less stupid. do not anthropomorphize.

I can see this being useful when feeding raw table dump csvs into models, isomorphism means it's a simple pre-post processing step which could give you a cheap decrease of tokens and increase in accuracy.