Skip to main content

What This Covers

  • How the four observability signals fit together: per-request logs, daily usage rollup, credit balance, and live rate-limit headers
  • A small Python script that pulls the last 24 hours of activity, aggregates by swarm_type, and prints a cost-and-error breakdown
  • The audit-trail story for enterprise, healthcare, finance, and other regulated workloads
  • Which signal answers which operational question — and which one you should be pulling first

Why This Matters

Most teams discover their observability gap the day a customer asks “what did the agent see on Tuesday at 2pm and how much did it cost us?” The Swarms API exposes everything you need to answer that — but the data is split across four endpoints with different shapes, time grains, and refresh cadences. This guide is the operator narrative on top of the Swarm Logs, Usage Report, and Account Credits reference pages: which signal to use when, how to combine them, and the minimum production-grade script for a daily dashboard.

The Four Signals

The rule of thumb: headers for the next millisecond, logs for the last hour (and for trend analysis — there’s no separate daily-rollup endpoint), live rates before you estimate a job’s cost, credits before you submit a batch.

Step 1: Configure the Client

Step 2: Pull Last-24h Logs, Aggregated by Swarm Type

The single most useful operator script: what ran in the last 24 hours, grouped by swarm_type, with cost and error counts per group.
The exact shape of each log entry can vary slightly — swarm_type, agent_name, and model_name may appear at the top level or nested under data. The code above is defensive against both. See the Swarm Logs reference for the full schema.

Step 3: Reconcile Logged Costs Against Live Pricing

/v1/usage/costs is not a historical rollup — it returns the current rate card (usage_pricing) the platform is billing right now, plus a timestamp. There’s no per-day or per-period usage-history endpoint in the API; /v1/account/logs is the only durable, per-request record of what you actually spent. Use the live rate card to sanity-check that the costs your logs recorded still match the rates you expect — this catches a pricing change you didn’t notice, or a client-side cost estimate that’s gone stale.

Step 4: Check Credits Before a Batch Job

The cheapest production incident to avoid is “the batch job stopped halfway because credits ran out.” One call before the submit loop is enough.

Step 5: Watch Rate-Limit Headers in Flight

The headers are on every authenticated response, including errors. You do not need a separate call. Log them after every request and feed the data into your throttling logic.
See the Rate Limit Headers reference for the full header schema and tier thresholds.

The Audit-Trail Value

For enterprise and regulated workloads — healthcare, financial services, legal, defense — the per-request log is not a nice-to-have. It’s the artifact your compliance team needs to answer post-hoc questions like:
  • “Show every agent invocation that touched patient X’s data between March 1 and March 15.”
  • “Reconstruct the chain of agent outputs that produced this trade recommendation.”
  • “Produce the model name, system prompt, and output for the decision made at 14:32 UTC.”
The /v1/account/logs endpoint is filtered to your API key and excludes client IP addresses for privacy, but otherwise retains the request shape, the model invoked, the response time, and the cost. Combined with deterministic agent configs (low temperature, pinned model names, fixed max_loops), it gives you a reproducible record per agent call — which is what most regulators actually want.
The platform’s existing log retention is suitable for debugging and operational analytics. For workloads with formal retention requirements (GxP, HIPAA, SOX, SR 11-7), export logs to your own storage on a daily cadence — the Swarm Logs examples show CSV/JSON/compressed export patterns.

Putting It Together: Daily Operator Cron

A pragmatic daily cron looks like this:
  1. 00:05 UTC — pull /v1/usage/costs to snapshot the current rate card; diff it against yesterday’s snapshot to catch pricing changes
  2. 00:10 UTC — pull /v1/account/logs; archive yesterday’s entries to S3 / your log lake; aggregate by swarm_type and model_name for finance — this log aggregation is also where your daily total cost comes from, since there’s no separate daily-rollup endpoint
  3. 00:15 UTC — pull /v1/account/credits; alert if total_credits < daily_budget * 7
  4. Continuously — every production request logs its X-RateLimit-Remaining-Minute; alert if a rolling 5-minute average drops below 20% of X-RateLimit-Limit-Minute
That’s the full observability story — three scheduled pulls and one inline log line per request.

Next Steps