yes, thats right! i know that all yall ai-haters can't wait for me to stop posting about this absolutely overblown subject of tool-call parsers and --- I ALSO CANT WAIT.

its not even that interesting.

ANYWAY!

u know what's sucks for LMs to generate?...

tool calls. they hate it.

But! u know what doest feel like a tool call but actually is one?

think about it.

its something u have likely already used plenty times yourself.

its! - - -

drumroll

The Slash Command!

wowie zowie how have i missed this one.

now oooobviously basic slash commands would only suffice for very basic calls like

/read path="file.txt" from=0 to=100

or

/use_skill name="scenes-and-nodes"

~(skills~ ~rule)~

but like - pffff this gets exhausting quick when writing larger stuff, like files!

/write path="file.txt" content="oh god\nit begins.\n\nthe never-ending c-escapes"

yea this sucks. No human would want to write this to do stuff.

lets spread out those args, and pull the idea from my last post (about multiline-strings as codeblocks)

/write
path="file.txt"
content=

now this! ~
feels writable.

I feel free in this code block.
and im sure qwen does too.

now looks at this! ~ 🥁 ~ ~ absolute bliss! ~ ~ ~

oh what a shock!! :o

watch where u walk! >o<

see here for context

what an awesome song. anyway-

---

and best of all:

we are saving TWO TOLENS (!!!) compared to my last format per tool call:

[use_skill  
name="theme-creator"  
]

compared to:

/use_skill  
name="theme-creator"

do u see it? thats TWO (2!!!!) TOKENS freeing up infron of our eyes:

1. \n
2. ]

yes, we are saving two tokens per tool call.

looking at YOU, opencode, which puts 16k tokens JUST for the system prompt! >:(

why dies this work? wellll-

• slash commands are well-known, unlikey previous format
• multiline args appear to be a fitting addition (essentially replacing the with \n as a separator)
• code-block multiline-strings had to be included cuz- yea, those LMs loooove generating em and hate c-escapes. keep messing it up, even big LMs.

absolute insanity. here a sys prompt to make an LM work with the format

You are agent with tools
read(path:str,from:int,to:int)->file content between from-to lines
write(path:str, content:str)->confirmation
search(query:str, is_regex:bool=false, type:Array[str]=["file_content","file_path"])->results (type can include file_content,file_path,dir_path
...

To call, write slash command at end of msg:

/write
path="/home/maria/file.txt"
content=
` ` `
content
here
` ` `

values are json-style, multiline-strings always in code blocks.
can call multiple in one msg

thats enough for basic tool usage with todays models. yes, even with 4B ones.

487 characters long, tokenizes to 118 tokens (when converting the triple ` strings to actual code blocks).

it works! makes the LM generate the calls correctly, even with banter as a prefix.... to keep itself on-course.

horray we solved climate change /s

oh well, time to actually implement this stuff tho....

its not difficult, but when ya want stable partial-tool-call-parsing, its a bit annoying.

UPDATE: wowie writing string parsers is difficult.

yeah I agree, string parsers need to be redefined for like every usecase of them, there is no standard is there?

naw, there are plenty standards:

jsoooon (Writing json inside some tags)

{ "tool": "name of the tool", "args": { "frist_arg_name: value, ... } }

aaaand xml, which is the most frequently used (but also most tone-heavy)

value here another value

those are two two standards right now.

wait a second, did you just reinvent Polish Notation?

hmmm..I looked into it and honestly dont see many similarities.

I gave up on constructing... my own tool call pipeline, since most LMs already come with one built in. only problem is that its craaaaazy verbose and eats up at least like 70 tokens per tool definition.

but its reliable... kinda. model has been trained to call tools this way. so.... thats how its meant to be iguess.