It's a very common thing. A very unscientific quick search in Google Books led me to the oldest example I could find in a minute or two being a mention in The Dublin Review in 1844 reviewing a book on the correspondence of Edmund Burke talking about the loss of material that would have been indispensable for an authorised biography. It's very unlikely to be remotely the oldest use of the term.
And that mention also gets to why authors often seek authorisation and why subjects often authorise them: Authors gain access to the subject and/or often their material, while the subject or their estates gains some control over how they are portrayed.
I know what you mean, but there is a reasonable distinction to be made especially for living persons. An "authorized" biography would be something like what Isaacson does, where they get exclusive access, anecdotes, and importantly confirmation or denial of certain facts or stories.
An "unauthorized" biography is not necessarily suspect but it is kind of a subgenre. Consider the difference between Isaacson's Musk biography and the work done by Kate and Ryan for Character Limit (https://www.amazon.com/Character-Limit-Elon-Destroyed-Twitte...) - not exactly a biography but the legwork is fundamentally different, reportorial or even adversarial where the narrative gets challenged, as opposed to accepted by the "authorized" Isaacson.
If a biography is authorized, then you can interview the subject, and in some cases those interviews provide a lot of the material. Walter Isaacson's biography of Steve Jobs was like this, for example.
In addition to the direct interview, there are other advantages of authorization that often allow the author a much deeper access to research the subject:
- Access to records, correspondence, and journals in the subject's possession
- explicit endorsement from the subject encourages their family, friends and colleagues to work with the author.
- Opportunities for the subject themselves to fact-check and contextualize the research.
That must be balanced against the fact that authorization also often provides the subject an opportunity to review the content, giving them a hand in crafting the narrative and/or suppressing unflattering details.
This is soooo incredibly cool. Beyond the Tom Riddle diary aspect, I love the idea of this as a new medium for interacting with an LLM. You could gift it to someone and they could just write naturally, their thoughts, questions, notes, and get responses back without typing or speaking. It feels less like a chatbot and more like a journal you can communicate through. You could give it a personality and all.
I mean no offense, but it's kind of crazy that people think that linking handwriting recognition, a technology that was first rolled out 24 years ago in Windows XP, with an LLM is "soooo incredibly cool". I don't get it.
What really irks me about it is that the palm pilot I had 20+ years ago actually had BETTER hand writing recognition than the software on my devices today!
If by hand writing recognition you mean force you to learn their "graffiti" system, and write one letter at a time sure. Lets not even pretend newton did any better.
For the edit tool, you should consider implementing a hash-based approach where each line of code is hashed and referenced by it when doing replacements. You can read up on the approach here: https://blog.can.ac/2026/02/12/the-harness-problem/
I didn't do much benchmarking, but anecdotally, I found it to be making less edit errors. YMMV
Yup, I used this for a while and IME it may get you a few percentages more of useful context initially, so quality feels a bit higher, but things start breaking down in funnier ways when you do run out of that quality for any reason later, so definitely caveat emptor.
It is not quite as rare. I calculated it to be less common than being hit by a meteorite, and added a section about that and the Birthday Paradox to Wikipedia, to the article about UUIDs. It got removed / replaced a few years ago however. (If my source was correct, there was actually a woman hit by a meteorite, but she survived, with a leg injury.)
If you do have a UUID collision, chances are extremely high that it's either a software bug, or glitch in the computer. It could be a cosmic ray. Cosmic rays messing with the computer memory or CPU are actually relatively common.
It's very common if you improperly seed, as others in the thread brought up! Or in your framing, as rare as earth getting hit if it were surrounded by a sci-fi density asteroid field.
For a single database using UUIDs, yes, it's astronomically rare. But it's quite a different thing to say that no computer system on Earth has ever experienced a UUID collision. The number of systems out there is also astronomical.
Initial drop, as people learn to use the tools, and while they keep babysitting their harnesses. Then significant boost once people start getting used to running the agents in the background, especially once they start running multiple sessions in parallel. I'd say you need a ~6 month push of getting people trained if they are not used to this way of working, and to customised setups etc. for your organisation, and then you start seeing significant payoff.
I've never once in 30+ years worked on a project where there weren't a lot of work we didn't get to because of lack of resources. So, yes, there's always been huge backlogs.
I had a chance to look at this and noticed you were sending telemetry to an endpoint you control: https://dirac.run/v1/event. It doesn't seem like you're sending anything obviously sensitive or doing anything in bad faith (though, I do see api errors being sent, which could potentially leak sensitive info), but you gotta admit that that's scary seeing you as the sole dev for this. Plus, it's opt out too. Sorry, it's no go for me.
1. Telemetry to dirac.run/v1/event — Sends machine ID, token usage, model info, events, errors (first 500 chars), and platform info. Hardcoded API key. Defaults to opt-in (setting is "unset", not "disabled").
2. Feature flags from dirac.run/v1/event/decide — Polls every 60 minutes with your machine ID. Always enabled, independent of telemetry opt-out. No way to disable without code changes.
3. Web tools route through api.dirac.run — Web search and web fetch tools proxy through Dirac's own API server, sending your request content plus system headers (platform, version, machine ID).
4. Model list fetches — Calls OpenRouter, HuggingFace, Groq, etc. for model listings even when using the Anthropic provider.
This is something that needs to be deprecated entirely. The web fetch tool no longer is used or works. There is nothing even listening at api.dirac.run. This was the result of me stretching my capacity too thin and bulk renaming cline.bot to dirac.run
UPDATE (+1h): both Web search and web fetch tools are now nuked.
Thanks! Since it is a Cline fork, the telemetry mechanism is inherited. I left it as it might help debug issues. There is no evil purpose behind it nor does it create or store any PII
I haven't tried it, but I'm curious why you decided to implement a whole new harness over just writing extensions in pi. From whatever I've done with pi so far, the extension api is quite extensive. Hash anchored edits, for example, can definitely be implemented in pi. Anyhow, thank you for showing us your project and will be checking it out later. Cheers!
A few months ago one afternoon I was very frustrated with how slow Cline was being so decided to look under the hood. Decided to make a couple of changes. Got sucked in. About 70k lines of change, another 40k lines of deletions and two months later, here we are.
I've been looking into local LLMs and new harnesses recently, how good is Pi compared to OpenCode, I'm seeing that it's a lot better? What are the best models and customizations for it to fully utilize it?
P.S. Love the "bonsai" name btw!
reply