Comment by keeda

Regular PSA for patent-related discussions: what matters is the claims, so before commenting one should read those.

Also this is a patent application, so it has not been examined yet. The claims at this point will always be over-broad, because that's just how patent prosecution works: the applicant (brazenly) tries to stake out as much "intellectual territory" as possible (because why not!) but the patent authorities will push back to the extent it does not overlap with other existing "territories" i.e. prior art. The applicant then narrows their claims and the back-and-forth continues until the authority determines that the claims are indeed novel and non-obvious enough to be granted. Every alternate back-and-forth costs $$ and time, which incentivizes applicants to make reasonable claims.

A typical way this negotiation often proceeds is that the applicant starts with a couple of the broadest claims they think reasonable and add multiple narrowing claims (or "dependent" claims) that cover narrower and narrower functionalities, essentially a dependency tree of claims.

This is because the examiner must judge each claim on its own merits, so while the broader claims could get knocked out, the narrower claims could survive and can indicate which "territory" is still unclaimed. The applicant can then focus on that (e.g. by making it part of the root independent claim.)

So often what is interesting in patent applicitations are the dependent claims.

For this patent, the current primary claim literally covers the concept of a tool call by an LLM, and as comments point out, this is ridiculously broad and will get knocked out by prior art. But the dependent claims are intriguing.

A quick glance at those indicates that Mistral thinks the more novel or non-obvious aspects are a "stateless resumable sandbox" which works by executing the generated code until a "non-deterministic operation" (like a random number or a date) and on getting the result of that operation replaying all the code that executed up until that point. The results of previous such operations are cached for reuse in subsequent re-executions.

Now I'm not at all knowledgeable about this area, but I did write a very rudimentary tool-calling LLM harness at one point, and offhand I would now have considered this approach -- re-executing the same code multiple times just seems wasteful and unnecessary. But the specification points out there are other considerations at play in more complex situations, so maybe this is narrower and more interesting than what the title and top claim indicates.