Tool-use planning loops with rec despite attached tool schemas

#12
by rachpradhan - opened

With Flint served through rec's OpenAI-compatible endpoint, an agent can repeatedly reconsider how to invoke tools whose definitions are already supplied, inspecting unrelated workspace or harness files instead of making the tool call that advances the task.

This appears distinct from discussion #11's argument-formatting issue: the concern here is choosing and using an available tool, not just making its arguments conform to a schema.

Could you document:

  • Recommended system-prompt or tool-description conventions for reliable direct tool use.
  • Whether rec supports a per-request reasoning budget while retaining its tool-call grammar, or another supported way to bound these planning loops.

A small integration example would help distinguish prompting requirements from runtime configuration. A prompt adjustment is being investigated, but no fix or performance improvement has been established yet.

I checked rec's public MLX server at revision 8af99ab (October 22). It accepts per-request max_tokens or max_completion_tokens alongside grammar:"flint", so you can cap total generation while keeping the tool grammar. This counts all generated tokens, including reasoning; it can end with finish_reason:"length" before a tool call is complete.

A potentially confusing detail: the handler removes unsupported request fields and logs them. reasoning_effort, thinking_token_budget, reasoning_budget_tokens and chat_template_kwargs are not supported controls in this version. See the pinned request allowlist and grammar/output-limit handling.

For a direct API reproduction, explicitly set the total output limit. Omitting both limits permits generation through the remaining context. Custom stop strings are rejected with Flint grammar. I did not find a supported reasoning-only allowance that reserves tokens for the answer or tool call afterward. That would be distinct from the current total-output cap.

Sign up or log in to comment