You keep saying that major models have "tool calling built in". And that by giving them context about available APIs, the LLM can "use the API".
But you don't explain, in any of your comments, precisely how an LLM in practice is able to itself invoke an API function. Could you explain how?
A model is typically distributed as a set of parameters, interpreted by an inference framework (such as llama.cpp), and not as a standalone application that understands how to invoke external functions.
So I am very keen to understand how these "major models" would invoke a function in the absence of a chassis container application (like Claude Code, that tells the model, via a prompt prefix, what tokens the model should emit to trigger a function, and which on detection of those tokens invokes the function on the model's behalf - which is not at all the same thing as the model invoking the function itself).
Just a high level explanation of how you are saying it works would be most illuminating.
Rooting your LG TV allows you to install homebrew apps. If you have a device that's at least a couple of years old and has not had its firmware updated, try https://rootmy.tv/
Human recall failure. Probably wanted "seemingly", "apparently", or even "ostensibly", but who's got time for all that when the publish button's right there.
I remember installing the TCP/IP stack from a treasured special floppy onto win 3.11 machines (giving them RIPE addresses and using NT4 as a router to expose the entire network onto the public internet - not a great idea in retrospect, but it was 1994 and everyone seemed so polite).
Meta has just released another in a series of extraordinary models that are already being abused to flood the crawlable web with regurgitated generative uncanny-valley material.
Since Google abandoned their focus on service quality, they are a prime target. The output of these models further hastens Google's decline in utility, and in turn, attractiveness to advertisers. Those ad budgets have to be spent somewhere, though; guess where?
This approach was what we had to use back in the late 90s. We called it "iframe streaming", or "forever iframe" (and years later, as an industry term emerged, "comet"). It worked surprisingly well, except in cases where a client sat behind a greedily buffering proxy. We would send JavaScript statements that invoked callbacks on the client, rather than just JSON, as this avoided the need to parse data to determine which business logic to use on the client. This has the limitation of being "non-cross domain" (i.e. the web page containing the callback functions have to be served from the same domain as the infinite document).
To get around buffering proxies, we optionally allowed our clients to use a JSONP long polling approach instead, whereby the client would dynamically generate a form inside a hidden iframe, and POST a request for JSONP data (JSON delivered wrapped in a callback), and the server would return data as soon as any was available. The client would immediately repeat the process to request more data, an infinitum.
Eventually, the emergence of the XMLHTTPRequest object in IE (and subsequently in other browsers) allowed us to implement cleaner long-poll-style methods, holding the connection open until data was available (and automatically reconnecting on error). This was later enhanced with CORS for delivery of data from arbitrary domains. As support for detecting updates to an in-progress response became available (via XMLHTTPRequest's "progress" event, which for a long time was horribly buggy in IE ) our payloads became infinite streams too (of JavaScript callback invocations). Early versions of approach also required us to reload the entire page from time to time, as IE's underlying implementations of these browser objects appeared to have memory leaks (that we did not see in Firefox, for example).
When IE8 was released, we allowed clients to optionally use its XDomainRequest object to stream a response instead.
Years later, the much cleaner Server Sent Events (SSE) and WebSocket options became possible. Intermediate proxy support was initially troublesome however, and while both of these were our preferred choices from a performance and API perspective, it took several years before we could consider removing support for our earlier approaches. Even today, there are network environments where an infinite sequence of long polls is the only reliable option...
My preference today? The JavaScript fetch API for sending commands, with a simple ack as a response, and an async flow of events over a persistent SSE connection, that feed into a simple JS message bus (implemented using the browser's native event API) for delivery to vanilla JavaScript web components. Simple, clean, and consistent.
If the speculation that the board want to open up everything so that it is truly open/public domain "for the benefit of humanity" turns out to be accurate, I can't see Microsoft being terribly happy about this now that they own 49% of OpenAI and want not only to recoup their investments but make ongoing profit.
An exodus of staff might provoke a very quick release of a lot of code, pipelines, and training data by the remaining board before investors' lawyers have a chance to stop it.
Tesla unilaterally decided to push out a refactored UI to my old Model S a few months ago, changing the location of numerous functions to new sub-menu paths, and rendering years of muscle memory useless.
Not only do I have to re-learn where everything is, but older memories interfere and confuse every time I try to access an infrequently used function.
This experience has been irritating at best. It has felt extremely unsafe on more than one occasion.
But you don't explain, in any of your comments, precisely how an LLM in practice is able to itself invoke an API function. Could you explain how?
A model is typically distributed as a set of parameters, interpreted by an inference framework (such as llama.cpp), and not as a standalone application that understands how to invoke external functions.
So I am very keen to understand how these "major models" would invoke a function in the absence of a chassis container application (like Claude Code, that tells the model, via a prompt prefix, what tokens the model should emit to trigger a function, and which on detection of those tokens invokes the function on the model's behalf - which is not at all the same thing as the model invoking the function itself).
Just a high level explanation of how you are saying it works would be most illuminating.