Skip to content

Mistral Patent Code Tool Calls: Hands-On Guide

Mistral's patent for code implemented tool calls just hit HN. Here's the claim sequence, Method A vs B, and a DIY pause/resume host you can run today.

8 min readIntermediate

Here’s the detail most write-ups skip: Mistral’s freshly granted US patent on code implemented tool calls doesn’t only say “the model writes code.” It describes an evaluation stack that replays the whole block from the start every time a client-side tool result lands, so non-deterministic bits stay stable while the LLM still sees only the final answer.

Key takeaway: multi-step agents are a control-flow problem. Put loops, branches, and awaits in a short program the sandbox runs. Fat intermediate JSON stays out of the model context. US 12,670,045 B1 is that pattern on paper – and you can ship the host shape today without anyone’s exclusive runtime.

Pro tip: Generate tiny, pure plans. If the host replays from line 1 on every client hop, a bloated preamble taxes you on every pause/resume cycle.

What just dropped (brief background)

Per the USPTO gazette entry, US 12,670,045 B1 (“Code implemented tool calls”), inventor Gabriel Vergnaud, assigned to Mistral AI, was filed March 4, 2026 and issued June 30, 2026. Claim 1 is a clean pipeline: server gets a user request → LLM emits a code block that wraps the tool calls → server runs it in a sandbox → on a pending client tool, pause and ship the call to the client → substitute the result, resume → hand the LLM the executed block’s result, not the hop-by-hop junk.

The longer write-up on Justia adds the TypeScript example language, the client/server split for local files or UI, and that evaluation-stack replay. The patent text frames the pain as context bloat, token burn, and messy mixed-locality tools when every discrete call dumps state back into chat.

The HN thread blew past 200 points with the usual software-patent food fight. Split: politics vs mechanism. The mechanism is just “code is the orchestrator.”

Method A vs Method B

Two honest ways to drive tools. Neither is magic. Pick on structure, not branding.

Axis Method A – classic JSON tool loop Method B – code-implemented orchestration
What the model emits One (or parallel) tool call object(s) A short program that may call many tools
Who owns control flow Your chat loop / the model turn-by-turn The code + host sandbox
What returns to the LLM Each tool payload in the transcript Preferably only the final block result
Best when 1-2 simple tools, tiny results Chains, branches, filters, mixed client/server tools
Cost center Tokens per hop Sandbox + possible full replay

Method A is what Mistral’s function calling docs teach: JSON schemas in, tool_choice of auto/any/none, optional parallel calls, you execute, you append tool results, model answers. Fine for a single inventory check like “qty left on SKU-4412.” Painful when five dependent calls each drag large payloads through the window.

Method B is the patent family plus the research line opened by CodeAct (arXiv:2402.01030) – executable code as the action space, up to roughly 20% higher success in that paper’s agent benchmarks – and later product patterns like Cloudflare’s Code Mode (Sept 2025: tools become a typed API; model writes code against it). For multi-step work, Method B wins on context hygiene. That’s the path below.

Walkthrough: a host that mirrors the patent sequence

You don’t need Mistral’s courtroom filing to practice Method B. You need: (1) an LLM that can emit a small plan, (2) a sandbox or careful executor, (3) a pause point for tools that must run on the client, (4) substitution, (5) a final-only handoff. Below is a beginner-shaped host in Python. Teaching code, not a production isolate.

Example task: triage a GitHub-like inbox – list open issues tagged bug, keep the three newest, draft one summary comment. Classic Method A would be list → filter in the model → draft, with full issue bodies bouncing through chat. Method B keeps filtering in code.

import json
from dataclasses import dataclass
from typing import Any, Callable

# --- fake tools (swap for real APIs) ---
def list_issues(label: str) -> list[dict]:
 return [
 {"id": 91, "title": "nil panic on export", "label": "bug", "ts": 30},
 {"id": 88, "title": "typo in README", "label": "docs", "ts": 20},
 {"id": 95, "title": "race in cache", "label": "bug", "ts": 40},
 {"id": 70, "title": "slow query", "label": "bug", "ts": 10},
 ]

def draft_comment(issue_ids: list[int], blurb: str) -> dict:
 return {"ok": True, "ids": issue_ids, "body": blurb}

TOOLS: dict[str, Callable[..., Any]] = {
 "list_issues": list_issues,
 "draft_comment": draft_comment,
}

CLIENT_ONLY = {"read_local_git_diff"} # would pause + round-trip

@dataclass
class Pending:
 name: str
 args: dict

class MiniSandbox:
 """Toy stand-in for: run plan, pause on client tools, substitute, finish."""
 def __init__(self):
 self.results: dict[str, Any] = {}

 def run_plan(self, steps: list[dict]) -> Any:
 # steps: [{id, tool, args, save_as}] - LLM would generate this
 env: dict[str, Any] = {}
 for step in steps:
 name, args = step["tool"], step.get("args", {})
 # resolve $refs from earlier saves
 args = {k: env.get(v[1:], v) if isinstance(v, str) and v.startswith("$") else v
 for k, v in args.items()}
 if name in CLIENT_ONLY:
 # PATENT BEAT: pause, transmit pending call, wait for client
 raise Pending(name, args)
 out = TOOLS[name](**args)
 env[step["save_as"]] = out
 self.results[step["id"]] = out
 return env.get(steps[-1]["save_as"])

# Plan a real LLM might emit (you parse code or a strict IR)
plan = [
 {"id": "s1", "tool": "list_issues", "args": {"label": "bug"}, "save_as": "bugs"},
 # next steps would filter/sort in real code; here we pre-filter for the toy IR
]

sb = MiniSandbox()
bugs = [i for i in list_issues("bug")]
top3 = sorted(bugs, key=lambda x: x["ts"], reverse=True)[:3]
ids = [i["id"] for i in top3]
final = draft_comment(ids, "Top open bugs: " + ", ".join(map(str, ids)))
# Hand *only* `final` back to the LLM for the user-facing sentence.
print(json.dumps(final))

Patent beats, mapped once:

  1. Receive request – user wants a triage summary.
  2. LLM generates the plan/code – ask for TypeScript/Python (or a strict IR) that calls named tools.
  3. Sandbox execute – host runs it; server-side tools resolve inline.
  4. Pending client tool – local-only step → raise/pause, send the call, wait.
  5. Substitute + resume – inject the client result; full evaluation-stack semantics replay from the top with cached non-deterministic outcomes.
  6. Return final result to the LLM – one compact object, not four issue dumps.

Want a managed cousin instead of DIY? Mistral’s built-in interpreter is the optional surface – create an agent, attach code_interpreter, run filters in-container:

from mistralai import Mistral
import os

client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
agent = client.beta.agents.create(
 model="mistral-medium-latest",
 name="Triage helper",
 instructions="Use code_interpreter for filters and aggregates. Return a short summary.",
 tools=[{"type": "code_interpreter"}],
 completion_args={"temperature": 0.3},
)
resp = client.beta.conversations.start(
 agent_id=agent.id,
 inputs="Given bugs=[{id:91,ts:30},{id:95,ts:40},{id:70,ts:10}], keep top 2 by ts and list ids."
)
print(resp)

That path is in Mistral’s code interpreter guide (as of mid-2026). Practical cousin – isolated code, conversation sees code + output – not a claim-for-claim clone of pause-and-ship-to-client. You’ll hit next: plain function calling, MCP tool catalogs, agent memory/connectors. Mistral announced the Agents API on May 27, 2025 with built-in tools including code execution.

Edge cases that actually bite

Replay isn’t free. When the host follows the patent’s evaluation-stack idea and restarts the block on each new client result, a chatty client round-trip multiplies sandbox work. Keep generated plans short; push heavy I/O into single tool calls instead of pure-Python preambles that re-run five times.

  • Wrong API surface. Drop code_interpreter into Chat Completions and you’ll wait forever for a sandbox that never starts. Official docs (as of mid-2026) limit it to Agents + Conversations. Function calling on chat still works; the built-in interpreter does not.
  • Dark debugging. Intermediate payloads never hit the model on purpose – that’s the patent’s point. Log tool IDs, substituted values, and sandbox stdout on the host or you’ll get a polished wrong answer with no trail.
  • Client boundary discipline. Only mark tools client-side when they need the device (local FS, browser DOM, hardware). Every unnecessary pause is a network tax.
  • Scope humility. Pure client-side “model writes Python/TS against tools” (CodeAct / Code Mode style) may not line up with claim 1’s server sandbox + transmit-to-client choreography. That’s a legal reading problem, not something a tutorial can clear.

Is the scarce thing novelty, or just a shared name for an idea agents keep rediscovering every few months?

FAQ

Does this patent stop me from building a code-mode agent?

Nobody outside counsel can promise that. If you ship a commercial US agent platform, talk to a lawyer. Not legal advice.

When is Method A still the right call?

Single tool, small result, no branching. “How many units left on SKU-4412?” is a one-schema job. Standing up a sandbox there only adds latency. Escalate to Method B when you hit three-plus dependent calls or intermediate blobs the model should never re-read.

Is code_interpreter the patented invention?

Common mix-up. Same neighborhood, not a 1:1 map. The interpreter runs Python in an isolated container and folds code plus code_output into an agent conversation – great for math, plots, transforms. The patent text centers on LLM-generated orchestration code, a resumable sandbox, client-delegated pending calls, result substitution, and returning only the final block result to the LLM. Approximate the useful parts with custom tools + your own pause/resume host; you never have to touch a patented implementation detail.

Next action: implement the toy MiniSandbox against two real tools you already own (HTTP GET + a local file read marked client-only). Force a three-step plan, log every substitution, and compare token use against the same task as a pure multi-turn function-calling loop. One hour of that teaches more than another scroll through the patent thread.