Skip to content

feat(status): add API call count to session status and usage footer#913

Open
BingqingLyu wants to merge 3 commits intomainfrom
fork-pr-48851-feat-api-call-count
Open

feat(status): add API call count to session status and usage footer#913
BingqingLyu wants to merge 3 commits intomainfrom
fork-pr-48851-feat-api-call-count

Conversation

@BingqingLyu
Copy link
Copy Markdown
Owner

@BingqingLyu BingqingLyu commented Apr 27, 2026

  • track API call count per run in embedded runner
  • persist per-run call count on session entries
  • show current-turn call count in /status output
  • show current-turn call count in response usage footer
  • keep calls semantics aligned with current-turn token usage
  • add/update unit tests for API call count display

Summary

  • Problem: Users cannot see how many API calls were made per turn, only token usage
  • Why it matters: Some providers charge per call; helps debug usage patterns and understand tool-call loops
  • What changed: Added callCount tracking in the embedded runner, persisted to session entry, displayed in both /status and response usage footer
  • What did NOT change: Token counting, cost calculation, existing status fields, cumulative session statistics

Change Type

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

User-visible / Behavior Changes

  • /status output now includes 📞 Calls: N in the usage line (current turn only)
  • Response usage footer now includes 📞 Calls: N when responseUsage is enabled (current turn only)
  • Call count reflects actual API calls in the current turn (including tool-use loops)
  • No config changes; no new settings

Security Impact

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Repro + Verification

Environment

  • OS: Linux (Ubuntu 22.04)
  • Runtime/container: Node.js v22
  • Model/provider: Any
  • Integration/channel: Any

Steps

  1. Run /status command in any session with prior activity
  2. Observe the usage line includes 📞 Calls: N
  3. Enable responseUsage: full in config
  4. Send a message and observe usage footer includes call count
  5. Trigger tool calls and verify count increases per API call

Expected

🧮 Tokens: 154k in / 656 out · 💵 Cost: $0.40 · 📞 Calls: 3

Actual

Works as expected.

Evidence

  • Passing unit tests
    • src/auto-reply/status.test.ts - "shows API call count from the latest run"
    • src/auto-reply/reply/agent-runner-utils.test.ts - "formats response usage line with API call count"

Human Verification

  • Verified scenarios: Unit tests pass; code review completed
  • Edge cases checked: Zero calls, single call, multiple tool calls
  • What you did not verify: Live integration test (requires local build and gateway restart)

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Failure Recovery

  • How to disable/revert this change quickly: Revert the commit
  • Files/config to restore: None
  • Known bad symptoms reviewers should watch for: None

Risks and Mitigations

None. This is a display-only feature with no side effects.

hoshi_lan added 3 commits March 17, 2026 15:36
- track API call count per run in embedded runner
- persist per-run call count on session entries
- show current-turn call count in /status output
- show current-turn call count in response usage footer
- keep calls semantics aligned with current-turn token usage
- add/update unit tests for API call count display
Bot review feedback: callCount was missing in followup-runner.ts
persistRunSessionUsage call, causing stale count after followup turns.
This aligns with how usage/lastCallUsage are already handled there.
- Add callCount tracking in subscribeEmbeddedPiSession (incremented on each
  recordAssistantUsage call, i.e., each LLM API response with usage data)
- Add attemptCallCount to EmbeddedRunAttemptResult
- Pass callCount from attempt to run.ts and accumulate properly
- Add tests for callCount accumulation scenarios

This fixes the issue where callCount only counted attempts, not individual
API calls within tool-call loops.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Add API call count to status/usage output

1 participant