#Native Tool Call Feedback & Support

1 messages · Page 1 of 1 (latest)

placid mulch
#

Native Tool Call support just got merged - https://github.com/Kilo-Org/kilocode/pull/2833
Congrats @worn ermine (and eventually @wanton oak with his awesome parser)!!!

It's still experimental – so In anticipation of answering questions & getting bug reports coalesced in one place we are making a spot for it.

Preferred Bug / Feedback Format:

Provider: (KC, OpenRouter, etc)

**Model Name:**
 (Haiku 4.5, Qwen3-Coder, etc)
Prompt: "Please write MacOS in ASM"
Behavior That Should Be Changed: "It zigged. It should have zagged"
Screenshot: Yes please!

It will surface as a choice in "Tool Call Styles" – XML (Original Recipe) and JSON (Extra Cripsy). I think we are getting a new left hand side icon in Settings.

JSON is the Native Tool call style for those brave of heart and wanting to help make this feature the best it can be kilo ❤️

Edit: NTC will be required to reign in Haiku 4.5 spouting XML in the chat about tool calls and actually make them if you want to use it. 😆
But as the Release Notes mention

There are possible issues including, but not limited to:

  • Missing tools (e.g. apply_diff tool)
  • Tools calls not updating the UI until they are complete
  • Tools being used even though they are disabled (e.g. browser tool)
  • MCP servers not working
  • Errors specific to certain inference providers
GitHub
Preliminary support for native tool calling by mcowger · Pull Requ...
#

Native Tool Call Feedback & Support :kilo: :muscle:

#

Native Tool Call Feedback & Support

timid cliff
mint hedge
#

This was fast ngl

#

Congrats Matt

worn ermine
#

Thanks to @wanton oak @placid mulch @timid cliff and you for the feedback!

#

Though I'm pretty sure Haiku 4.5 sucking with XML calls was probably the drivign factor here 🙂

timid cliff
#

This will finally make me switch to Kilo

#

from roo

mint hedge
timid cliff
#

It will be very funny if Roo adds native tool calls just after kilo does

mint hedge
#

They will finally answer to Nacc on his roocode PR 🤑

wanton oak
#

I'm happy to see Kilo introduce experimental native tool calls. I think my pull request can be closed, but the current draft still needs the following enhancements:

  1. Support for apply_diff
  2. A mutable tool schema. The current implementation renders many configurations ineffective, making the tool less flexible. There's no way to control the number of files read, limit the number of lines read, and enable or disable some tools in the settings.
  3. Streaming tool result responses
  4. More provider support. I hope to first add native call support for various OpenAI-compatible provider to facilitate testing.

Hope with the continuous feedback from the community, this function will become more and more perfect.

wanton oak
# mint hedge They will finally answer to Nacc on his roocode PR 🤑

I think they are not interested. If you observe the frequency of PRs being merged in their community, you will find that generally only PRs that update the model will be welcomed and responded to quickly. Other PR merges are often subject to rigorous inspection and forgotten until one day they intend to clean up the PR and mark it as old and close it.

worn ermine
mint hedge
#

using it with haiku right now the native tool calls

mint hedge
#

Man it looks good
I didn't have issues with haiku and no tool failure

I will test later or tomorrow with gpt-5 codex from openrouter

It feels slow but I guess it is because there is no streaming (for the visual feedback) for when the tool call happens

worn ermine
#

That’s exactly right. Need to implement apply_diff and @wanton oak streaming parser

timid cliff
worn ermine
mint hedge
#

Still only for kilocode provider and openrouter, right?

worn ermine
#

For the moment :P.

#

Whats your highest priority?

timid cliff
#

Openai-compatible seems like a good bet

#

then a bunch of existing other providers will follow as well

mint hedge
worn ermine
#

Yeah - my initial plan is openai-compatible and lm-studio...but will need to add some docs and warnings....there are MANY MANY broken OpenAI "compatible" implementations out there

mint hedge
#

But how openai compatibles behaves with tool call anyways? Or are native tool calls only dependant on the model itself?

worn ermine
#

depends on the model and the implementation by the provider.

#

LM Studio doesn't follow the OpenAI spec properly, and doesn't properly respect the OpenAI spec (with regards to the tool_choice options).

Ollama is similar, and also doesn't enforce schema validation properly.

By default, SGLang (used by many providers) doesn't correctly parse the tool_choice options, and throws back a gross 400 message with correctly implemented API calls)

mint hedge
#

Then openai compatible (global coverage) isnt safe bet as you will need to test every provider, mayve focus on for example synthetic and zai

timid cliff
#

there should be one standard they should follow

#

check how litellm does it

#

I saw a bunch of openai-compatible subscription or free providers run litellm proxy under the hood

#

(cause i had litellm errors from them)

worn ermine
#

Yeah, and I'm sayting they DONT follow it

#

example:

When sending a request that contains a tools array and tool_choice": "required", SGlang responds with a 400 error, and:

400
[object Object] failed the following checks:
[object Object] failed the following checks:
required failed the following checks:
required failed the following checks:
required is not equal to auto
required is not equal to none
required is not an object

Changing this to 'auto' passes the validation, but then does not enforce the desired request of requiring a tool call.

However, required is a valid option in the spec:

Tool choice mode
string
none means the model will not call any tool and instead generates a message. auto means the model can pick between generating a message or calling one or more tools. required means the model must call one or more tools.

timid cliff
#

Huh.

worn ermine
#

So yes - it would be great if “compatible” really meant it.

timid cliff
#

Well, making what it should be a requirement for openai-compatible option should work. It is a toggle anyway, so normal operation would not be affected

#

but i get what you mean

#

It seems like there would be more options to toggle to make this work for any compatible provider

mint hedge
#

Yes, checking every provider which can be made by the comunity or the provider itself

worn ermine
#

I deal with the same thing at work.

Vendor: “We make a Postgres compatible DB”
Me: “Cool! Does it support MERGE INTO?”
Them: “no?”
Me: “WELL THEN ITS NOT COMPATIBLE IS IT THEN!”

timid cliff
worn ermine
#

Or provider A (OpenRouter) supports all the stuff for model A (GLM 4.6), but provider B (Synthetic), for the same model, doesn’t support certain parameters and rejects the request. Or provider C accepts the paramter, but ignores it altogether (Poe)

worn ermine
mint hedge
#

Compatible is just a marketing word most of the time

worn ermine
#

“Compatiblish”

mint hedge
#

"Ish" -tsk

#

So maybe the K2 test can help to spot some issues for better testing
M A Y B E...

worn ermine
#

I wonder (later) if I can just build a progressive fallback.

Start with the best option (full tools array, tool choice array and required = true).

If that barfs, fall back to filtered tools, no tool choice array, and required = true

If that barfs, just the tools and required = auto

If that barfs, XML!

#

Would be easy to probe for on configuration

mint hedge
#

Switch A, switch B, break return "wtf u using bro?"

worn ermine
#

Exactly

#

Return “sorry your model is garbage”

mint hedge
#

Hahaha

#

But it will be a good option so people will just use kilocode and if the model doesn't return "garbage", there is hope

worn ermine
#

Yeah I’ll put in the PR tonight.

wanton oak
#

Compatibility support is not for local use. Many providers inherit the compatible implementation class. After you complete the transformation of openai.ts and base-openai-compatible-provider.ts, you can enable providers such as chutes, fireworks, zai, deepseek, etc. to support tool calls.

mint hedge
#

this happen while using gpt-5-codex and there wasnt any related mention of mcp server, which this is weird. Using openrouter provider

image.png image.png image.png
#

Zai GLM 4.6 openrouter provider return a "OpenRouter completion error: 400 Tool choice must be auto"

timid cliff
timid cliff
worn ermine
#

10 bucks says they’re running SGlang

#

I’m gonna have to scale that perimeter back to auto

timid cliff
#

I thought Openrouter forced a standard

#

guess not

worn ermine
#

They do on their end, but apparently don’t enforce it on their providers. Sigh.

mint hedge
#

a successful test haha

mint hedge
#

so this mean even for GLM 4.6 openrouter all providers needs to be checked which is pretty sad ngl

#

gonna test chutes provider haha

mint hedge
#

this is with chutes which is SGlang too

image.png
#

seems like NovitaAI have issues json tools too, for GLM 4.6
deepinfra is never ending loading with json tool calls, but works normaly with XLM tools

#

damn this is kimi2 mooshotai provider

image.png
junior breach
#

How is the default type of tool calling beneficial over the XML style? Cost?
Or maybe consistency?

worn ermine
junior breach