Whereas tool-use isn't a capability problem, but a context problem: the thing that makes models fail by default is that they have no idea, when first summoned out of the aether, what kind of conversation they're having, who it's with, what that person is trying to do, what tools they have available, and how those tools can be invoked.

Think of the difference between how you'd respond to a casual programming question asked by a person sitting next to you on a flight, vs. a programming question asked of you by someone you're pair-programming with with your IDE open in front of you. Now imagine waking up blind and deaf and needing to discern which of the two situations you're in. LLMs know how to approach both of these problem-contexts (and more besides), but they need to be given context to know which problem-context they're in (and everything else about that problem-context: which IDE they're using, which OS it's installed on, what other tools are installed+accessible, etc.)

And before you say "but why can't they just experiment to figure these things out" — if you think about it, knowing how to interface with a shell and an IDE are bootstrapping requirements for any kind of experimentation, in about the same way that "knowing how to open your eyes and move your head" is a bootstrap requirement for a human gaining information about the world around them. These capabilities are necessary to explore the world to "discover" and "probe" other capabilities.

---

Also, a lot of the work LLMs do "needs" (i.e. is heavily improved by the use of) some kind of structured scratchpad, that they have been trained to manipulate and "look at" through tool-use. Even for a human who could accurately visualize a canvas based on a coordinate system, you still wouldn't expect said human to succeed at the pelican test if they had to write the SVG entirely in their head and then write it out sequentially with no rewinding to fix mistakes. You'd expect them to ask for at least a whiteboard, if not a text editor, to be able to write and rewrite the SVG XML.

(Really, they'd ideally want to run the SVG and look at it to see how close it is, and optimize that way. I'm not sure if we're letting LLMs do that part in the classical pelican test. It feels like that would vaguely violate the "zero-shot"-ness of the test, though I'm not sure if we're currently considering a conversation to be "zero-shot" if it involves the model iteratively interacting with a third-party system [such that there are repeated model -> system -> model conversation turns] but holding off to responding to the user until they think they've fully solved the problem.)

---

And also, on a lower level, all of these external capabilities are getting exposed to the LLM through MCP. Models can and do understand how to speak MCP itself. But there's no standard for how a given harness's capabilities (e.g. "execute command line in new shell session", "send patch edit command to active tab in IDE", etc) should be modelled to be exposed through MCP, either in their encoding or in their semantics. There's no MCP equivalent of WASM's WASI meta-standard, such that models could learn these specs and "assume by default" that things work like them until told otherwise; and nor are there even open harnesses that LLMs could learn about during training, and through them, learn some de-facto MCP-endpoint specs. Instead, there are mostly just proprietary harnesses, that hide all that info from public access, sharing it only with the LLM during inference, and even then, only at the moment the LLM needs it.

For one thing, on beefy-enough recent CPUs, you could keep the weights hot in the L2 cache of a single CPU core. (Which is clearly not the use-case, but might be interesting to those looking for extreme TPS numbers. Or perhaps for efficient training!)

They could be doing invisible and vaguely-harmless Unicode stuff. Insertion of zero-width joiners and non-joiners, replacement of regular spaces with non-breaking spaces, building spaces from multiple hairline spaces, intentional use of non-NFC-normalized codepoint sequences for accented characters, etc.

Text with all this junk in it still reads the same; it just might wrap a little strangely, or not byte-match / collate correctly in a database (and Anthropic has never made a guarantee that their models would be capable of emitting text with these properties, so that’s fine.)

And, importantly, no regular text or document editor would insert these things (especially in the useless places you could insert them for watermarking.) You only really see them in text that’s been explicitly typeset for a specific layout (e.g. in text-containing SVGs, website mastheads, or game HUDs) or for print publication.

Of course, if this is the technique they end up using, then it’s very simple to strip it out by canonicalizing the text (i.e. Unicode-normalizing it + stripping out invisible layout characters + replacing “weird spaces” with regular ones, etc. Essentially the same thing many sites already do to user-generated content to prevent users from using Unicode features to break the page’s layout.

If that's the case, then the selection logic would be trivial: figure out the full hierarchical ID of the uarch you're running on, then search for the longest prefix match in the table of available impls.

If things work more like you're imagining, though, then I suppose the process-boot impl-selector would narrow down the impl matrix to just the subset that are legal on the running uarch; pick one arbitrarily to be active at first; and then wrap the calls in a handler that gradually re-works the called function in a way reminiscent of a profile-guided JIT, but without the need to actually synthesize any code at runtime — instead, it'd just be a multi-armed bandit passing-through-to and re-ranking competitor impls, with decreasing sampling of the non-first-ranked impls as confidence-in-score-separation increases.

What you'd actually want is a matrix of variant implementations burned into the binary, with runtime (or process-boot-time) hardware detection that swaps symbols out to point to the correct variant.

But, insofar as:

1. "a model" as presented to the user, isn't just its weights, but also anything else happening on the "business layer" (though this maybe applies more to ChatGPT than "direct" model access via the API); and

2. said business layer has any "knowledge base"-type stuff going on in it (i.e. automatic or tool-call-triggered embedding of results from search of some vector-DB into which has been embedded distilled pre-validated trustworthy info — like per-user memory mechanisms, but searching + injecting from global shared data sources); and

3. said "knowledge base" mechanisms are where most of the up-to-date, fast-changing info a model "knows" (without having to do a web search) is actually coming from;

...then do y'all ever update the pinned knowledge-base data snapshot associated with the model version, without updating the weights themselves?

(And, for however much of this effect is accidental, there are also parts of it which are maintained consciously/intentionally by the population and cultural institutions. Consider, for example, the Japanese public's idealized view of musical-performer "idols" as being "pure" [i.e. never being in romantic relationships.] This isn't just a mistaken idealized assumption that garners disappointment when corrected by reality; it garners actual backlash toward idols violating the assumption, often so widespread and vicious that the performers are effectively forced out of the industry. Which has caused the idols' production companies to effectively require their talent stays single [or at least hides their relationships from the public] — making what was originally a mistaken idealized assumption into a social-norm-enforced truth.)

Which means that "whether this naively-recursive code is actually recursive in practice" is a semantic difference, in that there is an error/failure-mode (stack overflow) that can be statically guaranteed to not happen (at least for a given compilation target) if TCO gets applied; but which cannot be guaranteed to not happen without TCO applied.

---

Tangent: you could of course try to write code defensively, to guarantee that a stack overflow won't occur, by bounding recursion separately (e.g. via a passed-and-decremented recursion-limit parameter), so that in the non-TCO case, you get a software exception thrown (which you'd hopefully then handle... somehow), rather than triggering a stack overflow.

And for many more-traditional recursive algorithms, this works!

But doing so for the types of algorithms that are "canonically" expressed in terms of tail-calls (even in a non-tail-call-idiomatic language like C), almost always requires poking holes in the C abstract machine to see through to the micro-architectural details underneath.

You can't just use something like a recursion-limit parameter as a general solution for these algorithms, as TCO is used in things like continuation-passing or threaded-code VM implementations — i.e. things that look less like visiting trees and more like visiting unboundedly-non-terminal infinite-state-machine states ["infinite" because the states are dynamic function pointers to JITted code, and more of them can appear at runtime.]

You need to not track the "number of invocations deep" you are into the algorithm, but rather, how big the stack actually is at the moment. Which means you need to actually do math on addresses of the stack base pointer vs either the stack pointer, or the address of a local stack-allocated variable. There's no version of that that doesn't require writing non-portable inline assembly.

This is pretty common when a company exclusively licenses a patent: they demand that the patent holder sue anyone using the tech who isn't them, so that they actually benefit in the market from the exclusivity. Without that enforcement, the money they were paying for exclusivity would be for nothing.

Thomson just made this kind of arrangement in the context of a non-exclusive license — getting Fraunhofer to start legally enforcing their patent rights at all, so that Thomson and whoever else licenses Fraunhofer's patents could benefit in the market from having licensed the patents, by ensuring that non-licensees aren't getting to use the patented tech for free.

In the US, such an arrangement is unnecessary (to the point that it might be causing a miscommunication in this conversation!), since patent holders tend to legally protect their patents all on their own, suing non-licensees for use of the patented tech even when there are no licensees demanding to "get the benefit they paid for." In Europe, patents aren't sued over by default, with enforcement instead only beginning when the patent is licensed and the licensee demands enforcement so that they can benefit.

Compare/contrast: people who develop games on top of high-level genre-specific game engines like RPG Maker are still considered to be "building a game." What's the difference between using a pre-made purpose-fit engine like RPG Maker, vs. asking an AI (or, for that matter, a contracted software company) to build you a custom purpose-fit engine?

(I don't know yet if anyone has determined whether this is a direct effect of GLP-1R agonism; or whether e.g. metabolic disorder has auto-immune aspects, and GLP-1R agonism effectively treats metabolic disorder; or whether it's just that e.g. sugar and other simple carbs are directly pro-auto-immune, and GLP-1R agonism breaks the addictive salience of sugars/simple carbs in such a way that even if you're eating the same amount, you're putting less of those in your body. Regardless of the mechanism, there does seem to be a consensus on the overall anti-auto-immune effect itself.)

The anti-auto-immune effects of GLP-1RAs show up visibly, e.g. on the face, entirely separately from the effects of weight loss (because this effect still occurs even when the dose of GLP-1RAs is too low to provoke weight loss), in the form of decreased puffiness, oiliness, acne, chapped lips, etc. It causes a bunch of small changes that make someone look like they're "taking better care of themselves" (even though they may have been taking assiduous care of themselves before, but didn't look it, for autoimmune reasons.) People definitely judge others on how "healthy" they look, so this could definitely help someone to get a job.

But the anti-auto-immune effects of GLP-1RAs also show up in entirely unconscious behavioral changes — not in anything cognitive, like "confidence", but rather due to GLP-1RAs being at least partly effective in treating chronic, sometimes-subclinical, usually-not-well-managed autoimmune pain disorders (think fibromyalgia) and autoimmune energy disorders (think ME-CFS.) Being less achey and having more energy makes people behave differently — whether that be on the macro level in subconscious decision-making (think of how people make different choices when overtired without being aware of it — people with chronic energy disorders are "overtired" 100% of the time!), or on the micro level, in terms of how e.g. speech is performed (people have reported becoming less "croaky", and their usable vocal range expanding), how nonverbal communication is performed (it's easier and "cheaper" to move your face and head and body, so you do), etc.

And note how, for these behavioral changes, some of these might be obvious to the person going through the changes (like your voice changing); but others are things you may not be aware has changed.

For facial expressions in particular, people learn to use their face in certain expressive ways when they're young, and then often don't notice when their face stops "responding" fully/correctly/in the way they'd anticipate to their brain's commands to execute these expressions. As far as you're concerned, you're doing what you always did; it's just that, at some point, you developed an autoimmune condition that attacked (or plugged up with waste) some nerves or muscles or tissues or whatever, that made those higher-level signals from your motor cortex stop translating perfectly to actually initiating the actions you expected. Most people don't periodically test their facial expressions in a mirror, so you only get info about the breakdown of these capabilities reflected in other people's reactions toward you changing. And, likewise, if these capabilities were to be suddenly restored, you'd only find out through others' reactions to you as well!

Has everybody forgotten about well-known email alias addresses? Inquiries about the hostname itself would be (among other things) exactly what `hostmaster@domain` was intended as a point-of-contact for. No need for a working WHOIS service, let alone a non-privacy-redacted WHOIS record.

Wouldn’t it be era-appropriate to allow relying on banked memory? You’d still need to hold the inference code, but you could effectively stream(ing page) the weights as you compute on them.

I.e. how hard would it be, comparatively, to design a virtualization framework that doesn't actually ship with any ground-up-rewritten libraries, but instead just expects to execute the binary in question in the context of a full rootfs copied over from a "real" macOS install?

Currwntly, politicians each have a series of meetings over time with different parties (constituents, lobbyists, domain experts, coalition members) and then at some point one of them drafts and tables a law (that's probably already been informally planned for ages among those in the know) and others vote for it (where many of those votes have probably also been informally pre-arranged for ages.)

To get WYSIWYG, every bit of all of those meetings would need to occur in the open. And likely the only way to practically accomplish that, in a “nothing up my sleeve” manner (i.e. to guarantee that there were no meetings outside of the official ones), would be to have all those meetings occur contiguously as part of one long recorded session in one place, with everyone who wants “a seat at the table” needing to operate on that session’s schedule; and where the politicians involved (i.e. those everyone else is there to influence) have a political career that starts and ends with that single session.

In other words, basically do the papal-election thing, or the sequestered-jury-trial thing: lock all the concerned parties (politicians + PAC leaders + lobbyists + etc) in a building together, and don’t let them out until they make a year’s worth of law. (But unlike either of those—record everything! Don’t allow any two people to be in the same room together without a camera.)

Sure, they might make all sorts of dumb hypotheses at first, but as long as the results of those stay in their context, they do seem to eventually “run out of ways to be stupid.” (Which is to say, LLMs seem to experience in-context learning even via self-directed trial-and-error, if given a sufficiently-large number of iterations and no way to cheat.)

Imagine you’re blind and deaf and have temporary retrograde amnesia. You “wake up” one moment with a memory of some words in your head like “what is the bug?” …but you don’t recall the context of that question, and nor can you look/listen around to observe the context.

So you don’t know whether you’re e.g. at the office, in front of your computer, in the middle of doing some pair-programming (where, yes, you’d in investigate the bug thoroughly with tools), vs. having a conversation with a colleague over lunch (where the expectation is for you to tap into your knowledge + intuitions to either guess or say you don’t know — not to pull out your laptop.

That’s what it’s like to be one of these LLMs being prompted by some agent harness. Unless the harness injects the proper context into its “recent memory”, it just doesn’t know.