custom-client

An extension path for testing a model provider that StateBench does not support directly by writing a provider client and an agent loop.

In plain words
What is it for?
Use it to implement custom client and agent classes, read provider settings from environment variables, and return tool requests in the format the benchmark can run.
Why use it?
It lets the benchmark work with other providers without requiring StateBench to understand their authentication, model settings, or API format.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/microsoft/state-bench/custom-client
Clone the repo
git clone --depth 1 https://github.com/microsoft/STATE-Bench
Per session 0 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,526 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.01526
Opus 5 $0.00000 $0.00763
Sonnet 5 $0.00000 $0.00305
Haiku 4.5 $0.00000 $0.00153

Measured yesterday against content hash 3052aa99d4f4, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

custom-client scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

docs/agents/custom-client.md · 175 lines

How it starts

The opening of the file, as written. The whole thing — 175 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Custom Client + Agent

Use this path to evaluate models from a different provider or write a custom tool-calling agent. STATE-Bench does not ship third-party adapters — provider integration is user-owned.

Custom runs use two extension points together:

  • BaseLLMClient (state_bench/client.py) — your provider-specific client wrapper.
  • BaseAgent (state_bench/agents/base.py) — your agent loop that calls that client and returns provider-neutral tool requests for the harness to execute.

File layout

Place your implementations under repo-root extension folders:

agents/
  my_agent.py
clients/
  my_client.py

Class names must be unique under their folder trees. The harness loads --agent-class from agents/ and --agent-client-class from clients/.

Provider environment variables

STATE-Bench does not interpret provider env vars; your BaseLLMClient.from_env() does. Add whatever your provider needs to .env:

MY_PROVIDER_API_KEY="<your provider api key>"
MY_PROVIDER_MODEL="<your model name>"

Custom client

Subclass BaseLLMClient and implement from_env(). The base class does not require a specific method shape; your custom agent decides which client methods to call.

# clients/my_client.py
import os

from state_bench.client import BaseLLMClient


class MyLLMClient(BaseLLMClient):
    def __init__(self, api_key: str, model: str):
        self.api_key = api_key
        self.model = model

    @classmethod
    def from_env(cls):
        return cls(
            api_key=os.environ["MY_PROVIDER_API_KEY"],
            model=os.environ.get("MY_PROVIDER_MODEL", "my-model"),
        )

    @property
    def model_name(self):
        return self.model

    def generate(self, *, system_prompt, conversation, tools):
        # Call your provider here. Convert STATE-Bench tool schemas to your
        # provider's format if needed, and return an object your agent understands.
        raise NotImplementedError

Read the full file on GitHub · 175 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 175 lines · 0 tokens per session scan A 3052aa99d4f4

Subscribe to this mod's changes

custom-client is an agent published in the GitHub repository microsoft/STATE-Bench (82 stars, last pushed 27d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,526 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other agents, from other repositories

write-tests-agent

Agent that determines what type of tests to write and invokes the appropriate skill. Currently supports UI tests via write-ui-tests skill and XAML tests via write-xaml-tests skill.

dotnet/maui · 39 tokens

sandbox-agent

Specialized agent for working with the .NET MAUI Sandbox app for testing, validation, and experimentation.

dotnet/maui · 23 tokens

JsCoder

Use when: writing or modifying JavaScript or TypeScript code in the Foundry Local SDK, implementing or maintaining the Node-API C addon for the JS SDK, porting C# or Python SDK functionality to JS/TS, wrapping native handles in idiomatic JS classes, implementing async iterables for streaming, packaging with…

microsoft/foundry-local · 100 tokens

CppCoder

Use when: writing or modifying C++ implementation code, refactoring internal logic, implementing features behind the C ABI layer, writing tests, fixing bugs in .cc/.h files, optimizing performance, reviewing code for C++ Core Guidelines compliance, serializing/deserializing JSON, reducing code duplication.

microsoft/foundry-local · 58 tokens

Reviewer

Use when: reviewing C++ code for quality, checking memory safety and RAII compliance, verifying cross-platform portability, enforcing API consistency, reviewing for thread safety, checking const-correctness, auditing error handling patterns.

microsoft/foundry-local · 42 tokens

PortCSharpToCpp

Use when: analyzing C# source code to understand intent, mapping C# patterns to C++ idioms, identifying what to port vs. redesign, documenting behavioral contracts from C# implementation, gap analysis between C# and C++ SDKs, contract types inventory.

microsoft/foundry-local · 52 tokens