Technical Details

Problem Statement

When an agent framework provides a very large set of tools to the LLM, model performance tends to degrade. Not only does a large toolset take up a lot of tokens, but models—especially quantized ones—often start hallucinating tool parameters or even tool names.

Solution: Tool Families

Turbostar groups tools into "tool families", most of which are not enabled by default. The LLM is provided a tool call to activate a tool family, along with a list of available families including descriptions that inform the LLM when to activate a specific family.

To illustrate this concept better, below is a list of some available tool families in Turbostar. Plugins can also register their own tool families dynamically.

• git: All the tool calls to interact with the Git version control system.
• hexedit: Tools to analyze, dump, and edit binary files.
• image: Image processing tools (zoom, rotate, crop, format conversion, etc.).
• x86asm: Tools to assemble, disassemble, and analyze x86/x64 machine code.

In agent definition files (e.g., agent.md), we extend the agent specification with an option that specifies which tool families are enabled by default for that agent. For example, a coding agent will have the "git" family enabled by default, while an agent working on webpages may have the "image" tool family enabled, but not the Git family.

Backtraces

Native applications (C, C++, etc.) can crash for many reasons—from chasing a bad pointer to hitting an assert() or failing to handle an exception. Turbostar wraps test and application execution with a special LD_PRELOAD library (libturbocatch.so) that intercepts key signals and carefully writes a stack trace to a dedicated location.

The main Turbostar application uses this backtrace file to decode addresses (something that is not safe to do inside signal handlers) and turn them into an actionable report for both the user and the AI agent. Turbostar maintains an internal crash database so users and AI agents can review crash details at any time. For human editor users, backtrace entries within the project include a "go to source" option.

AI agents are automatically notified when a crash occurs, complete with instructions on how to retrieve crash details.

Coredumps

Coredumps are the ultimate data source for analyzing crashes, containing a full memory snapshot of the application at the moment of failure. However, reliably generating a coredump file turns out to be a nightmare of Linux distribution-specific quirks. Systemd's coredumpctl? Not on Debian. Running ChromeOS? Forget it. Running inside a container? All bets are off.

Turbostar uses coredumpctl if available, but libturbocatch.so additionally triggers execution of gdb's gcore utility to produce a kernel-independent coredump file. While neither tool is individually perfect, this dual-attempt approach ensures coredumps are reliably generated for every crash.

From the backtrace details, a one-click "GDB window for the coredump" option is available to human editor users, while a fully interactive gdb session is just one tool call away for AI agents.

Example

An example crash dump provided to an AI agent can be viewed on GitHub.

Result

On a crash, the AI agent is notified immediately and gains direct access to a full, high-quality backtrace... and can then drive gdb on the coredump if more details are needed—fast and with minimal context bloat. No hunting for coredumps or grepping through logs; everything is available instantly and automatically.

This works seamlessly with open models, as well as models from providers whose agent CLI lacks native GDB integration!

Profiling Subsystem

Turbostar includes native basic performance profiling. While the Linux perf CLI tool is powerful, its output format is not editor-friendly. To provide basic profiling, Turbostar invokes the perf_event_open system call directly to collect a cycle-based profile.

Profile collection is subject to strict Linux security policies. To minimize required permissions, profiles are gathered using an LD_PRELOAD library (libturbocatch.so), scoping sampling strictly to the target process and its children.

Symbol resolution and data accumulation are handled by the main Turbostar application, producing per-line and per-function datasets. Hot lines are highlighted directly on the editor window frame, and the F7 hotkey allows quick navigation between hotspots in the code.

AI agents can request profile collection during normal app execution tool calls. Profiles are stored in an in-memory database, allowing agents to compare "before" and "after" runs and query function-level or source-file-level details.

Compiler Output

Compiling software can generate verbose output—for example, Meson emits over 1,000 lines when compiling Turbostar. Most of those lines (successful, warning-free build steps) offer no value to the LLM while consuming substantial context window tokens.

Turbostar parses standard output from common build systems like Meson and filters out noise lines. While this applies primarily to compiled languages, the reduction in context-consuming tokens is typically between 20x and 50x!

Test Suite Output

Similarly, test suite output follows standard formats. Turbostar filters out successful tests, presenting only test failures for the LLM to analyze.