Skip to main content
Performance work in AFK usually comes from four levers: choosing the right model, reducing unnecessary tool/LLM calls, keeping memory bounded, and moving long-running work into queues.

Latency

Use the smallest model that can reliably handle the task, and reserve larger models for tasks that need deeper reasoning.
Other latency controls:
  • keep system prompts short and specific;
  • make I/O-bound tools async;
  • avoid tools for information already present in context;
  • stream user-facing runs with runner.run_stream(...);
  • set tight max_steps, max_llm_calls, and max_wall_time_s limits.

Tool execution

Tools are often the slowest part of a run. Keep them typed, narrow, and bounded.
Tool guidance:
  • validate inputs with Pydantic models;
  • enforce timeouts in external clients;
  • return compact JSON-safe payloads;
  • truncate or summarize large external responses before returning them;
  • use RunnerConfig(tool_output_max_chars=...) as a final bound.

Throughput

Use async runner APIs for services and workers.
For durable background work, use task queues instead of keeping HTTP requests open. See Task Queues.

Cost

Set cost and loop limits on every production agent.
Read cost from the terminal result:

Memory

Long threads increase prompt size and storage. Use explicit thread ids and compact retained state when threads grow.
Choose the memory backend by deployment shape: Configure backends with environment variables or pass a public MemoryStore implementation to Runner(memory_store=...).

Measurement

Measure from AgentResult first:
For production, export telemetry through Observability and track latency, token usage, tool failures, degraded runs, and cost per run.

Checklist

  • Use async runner APIs in servers and workers.
  • Stream user-facing runs.
  • Keep prompts and tool outputs compact.
  • Set fail-safe limits and cost budgets.
  • Compact long-running threads.
  • Move durable background work into queues.
  • Monitor token usage, tool count, state, and cost per run.