Smart idea but the concern can be that in the future, tokenization techniques and libraries may change. And also this looks like a very edge optimization to me. But overall, it deserve to exist. Good job.

i would be afraid of accidental prompt injection

any plans for a python port?

Is this just a reinvented humanhash?

Benchmark comparing conventional UUID and AID across models, hallucination rate, token usage, would be cool!

Nice package, not only is using words more token-efficient [saving time and money], but weaker models are also less likely to make mistakes when providing the key, at least in my tests.

That said, for `createAliasMap`, don't you think you could create a deterministic mapping from and to UUIDs <-> word chains? That way, no additional state would be needed. [Might require fairly long word chains...]

An even better solution is to present the AI with local IDs and map those to UUIDs outside of its context. So when giving a list of items for the LLM to choose from, just list them with incremental numbers (1, 2, 3...) and ask for these numbers in tool schemas.

Hello HN,

I have built id-agent to solve the 3 major pain points with using UUIDs with LLMs:

1. Increased token usage 2. Incorrect ids in the output tokens because of hallucination 3. Poor readability when debugging prompts and traces

While building agent-qa, I encountered challenges with ids, since each test, suite, and run artifact has a UUID associated with it. The AI agents often made mistakes and referenced incorrect entities. With id-agent, I was able to achieve a token-efficient way of defining unique ids which can be easily differentiated. The prefixed id path drastically reduces the hallucination rate.

Do check out agent-qa: Open-source Agentic QA Harness with Memory https://vostride.com/

Why do people choose the hyphen ("-") as the separator in an identifier? When double-clicking, the ID does not select completely, unlike when an underscore ("_") is used.

I don't like that they're not apples to apples; less bits so of course it'll take less tokens.

> Where UUIDs cost ~23 tokens and get hallucinated by LLMs

How does this solve the hallucination problem?

Just removing the - from the example UUID takes it from 26 tokens to 18

Can someone explain why this would even be needed? Why is there a cost to generating say and UUIDv4? E.g. Claude Code has some regex in the client side code that filters out "bad words", so why can't the agent just generate UUIDs client side, using zero tokens.

I sort of get the "problem", but the fact that this is even needed is stupid.

Isn't this solving a subproblem of the overall issue of uncompressed tool call polluting context?

Furthermore, this could be compressed even further with a dynamic legend of every UUID in the context. So UUID@Bravo and UUID@Delta would be the actual symbols in the context but dynamically replaced when calling tools.

Neat idea! I'd argue that the collision risk is basically zero because even though the entropy is lower, because you must validate the LLM-output anyways for two reasons:

1. LLMs might lack intrinsic entropy and reuse some UUIDs much more often.

2. Referential integrity is as important as collision resistance. An LLM must be able to reuse the correct id in the correct place.

On the other hand, using a dictionary for the ids helps with readability, but depending on the models strenghts, it might also add a confounder. After all, tokens that represent real words will probably influence the attention in a different way than random numbers.