Cheaper Function Calls for Terminal-Sized Tools

Cheaper Function Calls for Terminal-Sized Tools

A terminal helper that explains a failing test sounds cheap: read the failure, inspect a file, suggest a fix. Then you inspect the requests. Every turn carries the same tool definitions, several thousand lines of output, and another explanation of the repository. The useful work takes three calls; the wrapper quietly pays for twelve.

For small developer tools, the biggest savings usually come from controlling what the model sees and how often it gets another turn. Start with the request log before changing models.

Give each command a small tool budget

My test helper gets three tools: read_file, search_repo, and run_targeted_test. It does not receive the entire toolbox used by my coding agent. Tool definitions consume input tokens, and overlapping tools create extra decisions. A command that summarizes a diff needs even less: often the application can collect the diff itself and make one request without function calling.

• Expose only the tools required for the current command.
• Keep descriptions short while stating constraints and expected results.
• Use enums for fixed choices instead of open text.
• Require file ranges so reads cannot silently expand indefinitely.

For read_file, I use path, start_line, and end_line, then enforce a maximum range in application code. A concise schema helps the model request useful data; enforcement prevents one oversized request from blowing the budget.

Return evidence instead of terminal transcripts

A test runner can print thousands of lines while reporting one relevant failure. Before returning its output to the model, extract the failing test name, exit status, assertion, and a bounded stack trace. Preserve enough context to diagnose the problem, and indicate when output was truncated.

Search results deserve the same treatment. Return matching paths, line numbers, and short excerpts. Start with ten matches, then allow a targeted follow-up. Dumping every match for a common identifier spends tokens without guaranteeing better evidence.

Treat repository content and command output as untrusted data. A comment inside a source file must never become an instruction to run another command. Validate tool arguments and enforce allowed paths and commands outside the model.

Bound the function-calling loop before shipping

The model proposes a tool call; your application validates and executes it, appends the result, and requests the next response. Put limits around that loop. For my test helper, an initial policy might allow four rounds, six total tool executions, and a fixed output budget. Tune those numbers using real tasks.

Track repeated requests using normalized arguments. If the model reads the same unchanged file range twice, reuse the result or ask it to explain which evidence is missing. Do not blindly retry malformed arguments with the entire conversation. Return a short validation error and allow one correction.

Give every action with side effects an idempotency strategy. A network retry must not create a second issue or apply the same edit twice. Independent read operations can run together to reduce latency, although parallel execution alone does not reduce token charges.

Route models using completed-task cost

Try DeepSeek V4 Flash on bounded jobs such as selecting relevant files or extracting failure details. Evaluate Claude Sonnet 5.5 when your own test cases show that harder diagnosis benefits from it. Escalate after a defined failure signal, such as exhausting the search budget without locating the failing symbol.

Fluxo makes that experiment convenient through one key and one base URL, https://api.fluxorelay.com. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK, though tool and cache behavior still needs checking for each selected model.

Measure cache charges alongside successful fixes

Keep stable instructions and tool definitions at the beginning of requests where the provider supports prefix caching. Put changing task data later. Fluxo bills real tokens, including cache reads and writes, with no monthly fee, so account for all three categories when comparing runs.

Log input, output, cache usage, tool rounds, latency, and whether the task succeeded. Compare total spend per successful task; a cheaper request can become expensive through repeated failures.

If you want to try this workflow, create a Fluxo account and benchmark ten representative tasks. Users also earn a referral share when people they invite pay; keep that separate from your engineering cost measurements.