which reminds me of building breadboard RF sensors (using fixed caps with variable for calibrating parasitic capacitance) and since these are just oscillators you can calibrate a beat frequency (heterodyne mix) in audible range that has the theremin timbre of a squarish sine wave that you can plug straight to a speaker
> Because expansion can recover arbitrarily large volumes of earlier conversation, this tool is restricted to sub-agents spawned via the Task tool; the main agent cannot call it directly. This restriction prevents uncontrolled context growth in the primary interaction loop.
What if the lcm_expand is called for a summary that has 1000s of messages that immediately floods the sub-agent's own context window?
Does lcm_expand only unroll one "layer" of the DAG and unrolls more if needed by another subagent?
By construction, individual summaries are not typically large enough to overload the context window when expanded.
The reason that the volume is potentially arbitrarily large is that one sub-agent can call lcm_expand multiple times - either vertically or horizontally. But that's a process that occurs gradually as the tool is used repeatedly.
This has not been a problem in our testing, but if it were a problem it would be easy to prevent sub-agents from invoking lcm_expand once their context buffer has reached a specified threshold.
Summary A = summarise(message 1 to P)
Summary B = summarise(Summary A, message P+1 to Q)
Summary C = summarise(Summary B, message Q+1 to R)
What does calling lcm_expand(Summary C) do? Does it unroll all messages from message 1 to message R or does it unroll to Summary B and message Q+1 to R?
> volume is potentially arbitrarily large is that one sub-agent can call lcm_expand multiple times - either vertically or horizontally
I'm assuming from this that it's the latter? In that case, that addresses my concern about not blowing up the context window immediately.
Another question is, why would earlier conversations need to be stored and recalled? They're irrelevant. Only records of the initial requirements and the work done, or work in progress, needs to be stored.
You could definitely build a coding agent that way, and it sounds like you've done it. We store the conversation history because:
1. In our use of coding agents, we find that there are often things referenced earlier in the conversation (API keys, endpoint addresses, feedback to the agent, etc.) that it's useful to have persist.
2. This is a general-purpose LLM memory system, which we've just used here to build a coding agent. But it is also designed for personal assistants, legal LLMs, etc.
This is really cool and something I've envisioned building for a long time!
There is a bug in the entity tracking. For the entity "github", it shows a positive sentiment. HN does NOT like GitHub (for reasons good or bad). If you click on it, it shows you stories about other seemingly unrelated stories.
Thank you. I believe this is because it's not properly aggregating the story title, content, and comment hierarchy. There are going to be cases where the LLM does a poor job of understanding the conversation, but I think right now the information isn't being sent to the prompt.
Right now it seems to be only using one level of the parent comment hierarchy.
The Count of Monte Cristo was published in serial form. Daily from 1844 to 1846.
That explains a lot the format, which tended to try to retain the audience.
Also, the author wrote in advance of the daily publication, but the book was written "live", answering to public perception and response. This is a reason why the book is so "good": the author had the chance to adjust the story based on data from sales and feedback from readers.
Of course Dumas was a great writer too, but this live writing, data based is probably why the book resonates so well with audiences.
So, as a joke, if you read count of monte cristo in 3 weeks, you did the equivalent of bing reading it.
This happens with soap operas too. 10 years ago, they lasted 1 year. They had an initial structure, the story, the characters, but responded in "real-time" to audience feedback.
For those willing to read the book, give yourself some time. Try to read it over a course of some years. Read a little, come back to it.
There are several famous books written in the same form, like Crime and Punishment or The Three Musketeers.
Oh, and also authors got payed by installment, so that explains the lenght lol
Loved the stranger, I read it for the first time this year too. I read plenty of sub culture (mostly modern; Irvine welsh etc) but the stranger was just so different than anything I’ve ever read. Like the language is so olan yet it works so well, and then you have this great finish, it’s a weird masterpiece.
I'm confused by what Cursor is trying to be. They shipped plan mode and debug mode which are developer focused tools and I'm happy about them.
On the other hand, features like these are kinda distracting to me. I wouldn't mind if it wasn't for the core product and developer features getting buggier day by day.
I've been facing a number of rough edges lately. The plan mode's support for multiple plans in a single chat breaks often, todos don't get created or marked properly, the new changed files UX is atrocious (just take me to the file), it's not able to adhere to simple prompts in a low context window usage chat (Sonnet 4.5), etc.
It sucks to try different editors every few months but I might have to do that if this continues.
> We’ve seen 2x speed improvements in type checking times for internal projects when using TSGO.
That's a lot less that what TSGO promised when it was first announced (A 10x faster Typescript¹). Hopefully this is just the result of it being experimental.
The article is measuring full project build performance. That includes type-checking and compilation.
Maybe the `tsc` type-checker was already fast (so we only get some speed improvements in `tsgo`), or the `tsc` compiler was not that fast (so we get a lot of speed improvements in `tsgo`)?
*Update:* There was a performance regression in incremental type-checking between `tsgo` preview 20251209 and 20251211 [1]. But `deno` is using `tsgo` 0.1.11 which was already released last week (before this regression). So, does not seem to influence the type-checking times here.
- Smallest animal: Myxobolus Shekel. Smaller than a WBC at 10 micrometeres.
- Biggest butterfly: Queen Alexandra's Birdwing. Bigger than human brain at 18cm.
- Largest insect to ever live: Meganeura (283 MYA). At 40cm long, a dragonfly larger than a house cat.
- Rafflesias are larger than German Shepherds
- Earth's largest crab: Japanese Spider Crab. 1m, legs pan of 3.75m. More than half the size of a human.
- Always thought Mososaurs were largest animal to ever live but it's the Blue whale at 26m. I don't think I ever appreciated how unfathomably huge they are. (The largest Mosasaur found was 13m. There's a speculated size of 17m as well.)
- World's largest living tree: Hyperion - a giant redwood in california at 115m.
Love seeing something so polished and inspiring. Amazing illustrations and even better music.
I added a bit more information about Bun compatibility:
> While Bun is supported and Bun does support the `using` keyword, it's runtime automatically creates a polyfill for it whenever Function.toString() is called. This transpiled code relies on specific internal globals made available in the context where the function is serialized. Because the worker runs in a different isolated context where these globals are not registered, code with `using` will fail to execute.
A linter rule provided by the library could be helpful here. I know it's just a workaround but probably easier than going for a solution that does compile time checks.
