-
A sensor, not a detour.
Your existing framework owns the task, model client, and tools.
Replacement tools are wired separately. Installing the Auditor does not enable optimisation.
Original tools stay in place. The Auditor can observe this baseline without the Optimiser.
Attach framework callbacks, event listeners, a trace processor, or explicit client/tool wrappers before execution.
This rail represents in-process instrumentation, not a proxy between your agent and its model.
- Attach observation hooks before the run.
- Connect model and tool observations to one audit session.
- Keep the model endpoint and task under your framework's control.
-
A smaller menu. The same objective.
The framework assembles instructions, conversation history, and tool schemas into a model request.
A configured tool profile offers task-relevant tools with concise descriptions. Instructions and history are not rewritten.
The original tool list and descriptions travel with the request, whether or not every tool is needed.
The audit session is ready for exposed events. It does not prune the request or decide which tools the model sees.
Tool profiles require configuration; the Optimiser does not automatically discover the perfect tool set.
- Keep the goal and instructions intact.
- Offer a configured tool menu suited to the task.
- Send the request to the existing model endpoint.
-
The model still does the thinking.
The model generates a response. It may request a tool, answer directly, or need another turn.
No intervention inside inference. Savings come from supported tool surfaces, not changing model weights or reading hidden reasoning.
Inference uses the same model endpoint. Its response and usage depend on the request and workload.
On exposed model-completion events, the adapter normalizes provider-reported input and output usage into the session.
Usage visibility depends on the SDK and provider. Missing usage is not proof that a model call was free.
- The model receives the assembled context.
- A response can contain a tool call or a final answer.
- The adapter records usage exposed by the integration.
-
Find the useful part first.
A tool call looks for the configuration value. The result becomes evidence for the next decision.
Supported reads return useful structure; grouped, bounded searches return focused matches. Full reads remain available when needed.
Broad reads and unbounded search output can return much more text than the next decision needs.
Tool hooks capture the exposed name, arguments, and result. These observations support the local trace and supported shadow estimates.
A bounded search is not complete coverage. Unsupported formats or missing context may need a fuller read.
- Dispatch the requested read or search.
- Return useful structure or a bounded set of matches.
- Observe tool I/O without replacing the result.
-
Change a fragment, not a file.
The agent wants to change a config value, such as a timeout from 30 to 45.
An anchored edit replaces the exact matching region under a file lock and returns a short change confirmation.
A full-file write asks the model to reproduce unchanged content alongside the actual modification.
The adapter records exposed edit arguments and results. It observes the operation; it does not perform or approve the write.
Ambiguous anchors must be resolved, not guessed. Application-level correctness still needs validation.
- Describe the relevant old and new text.
- Match safely, then apply the scoped change.
- Return a concise confirmation and observe the tool result.
-
Do not execute known work blindly.
A later call may repeat a read or ask to confirm an already confirmed write.
When session guards are configured and the call is eligible, return a compact duplicate or post-write confirmation instead of repeating the underlying operation.
The original tool can perform the read again and return its payload, even when recent work already answered it.
Captured text passes through default secret-pattern redaction before persistence. The agent's actual tool result is not redacted by this capture path.
Guards have state and eligibility limits. Suppressing tool execution does not erase the model turn that requested it. Redaction is not a guarantee that all secrets are removed.
- Check whether a repeated operation is eligible for a guard.
- Return a compact confirmation or execute when fresh work is needed.
- Redact captured text, not the agent's working result.
-
A leaner result travels forward.
Tool results return to the conversation. The framework can call the model again with prior context.
Smaller tool payloads can reduce context carried into later requests. This is not automatic conversation compression.
Large results can travel through later turns, adding replay overhead even when no tool call is duplicated.
Normalized observations are appended to local events.jsonl; session metadata makes the run discoverable by the local dashboard.
Context retention, caching, output prices, and later agent choices affect the outcome. There is no fixed savings multiplier.
- Append the tool result to the conversation.
- Prepare another model request if the task needs one.
- Persist observations locally as execution continues.
-
Inspect the run. Separate fact from estimate.
The run finishes or fails. Your application must judge whether the requested outcome is actually correct.
Judge the changed tool behavior with real task checks and comparable runs—not with the animation's smaller shapes.
A baseline trace can reveal candidate savings before you replace tools or change the workflow.
Finish or detach to flush remaining observations. The local report shows captured usage and tool activity separately from shadow estimates of supported savings opportunities.
Shadow analysis does not rerun the agent or make extra model calls. It is not a measured Optimiser outcome or a promised bill reduction.
- Finish the session and flush trailing tool observations.
- Inspect usage, tool activity, and available local estimates.
- Validate the task outcome and measure changes on your workload.