HN user

wild_egg

1,126 karma
Posts6
Comments371
View on HN
Kimi Work 2 days ago

Is there a link anywhere for a docs site for this? Really curious to know what "deep data sources" they have set up for the Native Global Market Data feature.

"The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry."

— Henry Petroski

If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work.

You are really, really not. Not at LLM inference speeds at least. Frontier models output maybe 200 bytes per second on the fast end. I guarantee you that idle BSD box is still processing more than 200 bytes of whatever at any point in time. Streaming 200 bytes of LLM output through syntax highlighting, markdown rendering, and diff formatting, will still leave the box basically idle if done correctly. Claude Code has not done it correctly.

Early 2000s tech could absolutely handle LLM agents as a client. They output like 1-2kbps and even dial up modems would have plenty of capacity for other traffic.

The UI itself requires laughably simple tech. The idea that a markdown renderer that can produce HTML at 50MB/s would use much CPU to process incoming hundreds of bytes per second is insane. CPU should be idle even if doing that constantly. Nevermind that between turns it has nothing to do whatsoever and should use zero CPU at all.

There are two different arguments here.

These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown.

The first argument is that these are expensive operations. They are not. And the second argument is the assumption that these are desirable things for an agent system to be doing. That's a personal preference but, personally, I don't want them and would appreciate a way to disable all of that to reduce CPU use.

No, the fundamental problem of these apps is that they are, for no reason, pretending they need a high powered game engine rendering loop. They don't. It's a text printout of history with some hotkeys for mode switches and such. "rendering in a single thread" should never be an issue because it should never be "rendering". It needs to stream text to stdout. That's been a solved problem for 50 years and now it takes 2GB of memory to be done poorly with broken scrollback.

SQLite definitely seems like a poor choice for dealing with many concurrent requests

Can you qualify "many"? SQLite easily handles 100k+ writes per second and it's not hard to have app layer code serialize and batch writes to take advantage of that speed. Concurrent writes require a ton of overhead and your system and code can be quite a lot faster and simpler if you just skip the idea of them altogether.

There are a ton of optimization opportunities that hinge on the intent of a piece of code which static compilers can never detect at scale. LLMs can actually navigate that and write surprisingly optimal assembly.

I've had all my side projects being written in x64 for the last 6 months and it is shockingly effective.

There is an amount of brute forcing that becomes possible at those speeds that I think could even take us beyond 80%. If we could have Qwen3.6-27B running at 15k t/s, run 100 attempts concurrently, select top-K solutions and synthesize a final result from them.

There was a paper a while back that showed top-K selection like that with tiny models was able to reliably solve some 1M-step Tower of Hanoi when no frontier model could. Very big level up in capability just from horizontally scaling compute.

You're not wrong. I did a similar agent in lisp back with Sonnet 3.5 and had a wow moment, but the wow was mostly for seeing an agent working effectively at all at that point in time.

The part that killed it for me was losing everything if the lisp crashed (sonnet 3.5 was prone to doing that) and solving persistence had too many edge cases and confused the model.

Later realized that writing the agent as 20 lines of bash was equivalently powerful to the lisp agent, but made persistence trivial from the easy file system interop.

Why does having. GC mean not thinking about memory? I think about memory constantly in GC languages because I still want it to perform well.

The biggest difference is the failure modes. If I'm not thinking about memory, my RSS is higher or a bit of extra CPU time goes to GC. Both of those are radically better than UAF or buffer overruns. Good trade IMO.

unless you literally have written a new type system and compiler

This is entirely possible with plain lisp macros. See https://coalton-lang.github.io

Having that natively available as plain Common Lisp code is a very different thing from your "just read a text block and compile it as rust code!" concept. Or at least, the tool chain gymnastics required to make a C program emit its own source in another language... Why?

GPT-5.6 13 days ago

Can anyone explain this "quietly quantized" model idea to me from a business perspective?

Coca-Cola doesn't "quietly water down" its product to save a few bucks. They know people will take a sip, say "oh that's not what i wanted", and go buy a Pepsi.

If they serve me a quantized Fable, I'm just going to think Fable sucks and go get my tokens elsewhere. What's the point?

There's a bit of a mental model flip to make maybe.

they're code that's generated at compile time

They're code that generates code at compile time. Macros can actively walk the AST of the parameters they process and rewrite them completely into new shapes. That transformed AST is what then actually gets compiled.

check out tsnet if you are building on tailscale anyways. your app can then be a tailnet node that can read tailnet WhoIs data and have access controlled via tailnet ACL

Fable 5 Is Back 21 days ago

Really depends what you're working on. GLM 5.2 is doing excellent webdev work for me but really faffed up when working on a custom garbage collector that Opus has no problems with.

LLMs do not produce a usable result

At this point, this is categorically false. Your mental model is very out of date.

The results may not be ideal but I can't say I've had a single output so far this year that wasn't usable.