5 command-line tools for shipping voice agents

Building voice agents means spending a lot of time at a terminal. Not writing, but debugging audio streams, checking response formats, and measuring latency. The tools that make that bearable are the same ones I reach for every day.

These five are not speculative. I use them in every integration I build.

1. curl with response timing

Every voice AI API starts with a simple HTTP request. curl is that request. But the flag that changed how I work is -w for custom output formatting.

curl -s -o /dev/null -w "HTTP %{http_code} | Total: %{time_total}s | Connect: %{time_connect}s | TTFB: %{time_starttransfer}s\n" \
  -X POST "https://api.deepgram.com/v1/listen" \
  -H "Authorization: Token $DG_API_KEY" \
  -H "Content-Type: audio/wav" \
  --data-binary @sample.wav

That one-liner tells you everything about your API path before you write any integration code. Is the problem your code or the network? curl knows. I keep a shell alias for this pattern so I never have to retype it.

time_starttransfer is time-to-first-byte for streaming APIs. time_total covers the full request. When a voice agent feels slow, these two numbers tell you whether it’s the network or the model.

2. sox

Sox is the oldest tool in this list and still the most reliable for audio inspection. Voice AI pipelines produce and consume audio in formats you did not expect. Sox tells you exactly what you have.

# What file is this, really?
sox --info mystery.wav

# Resample for an API that expects 16kHz
sox input.wav -r 16000 output.wav

# Trim silence from the start
sox input.wav output.wav silence 1 0.1 1%

# Concatenate multiple files for batch testing
sox part1.wav part2.wav part3.wav combined.wav

The most common failure mode I see in voice integrations is audio format mismatch. The API wants mono 16-bit PCM at 16kHz. The developer sends stereo 24-bit at 48kHz. The API returns garbage or silence. Sox catches that in one command.

Every voice AI developer should have sox --info muscle memory. It saves more time than any SDK function.

3. websocat

Real-time voice APIs run on WebSockets. curl cannot test a WebSocket. websocat fills that gap.

# Connect to a streaming STT endpoint and send audio
websocat -t "wss://api.deepgram.com/v1/listen?model=nova-3&encoding=linear16&sample_rate=16000" \
  -H "Authorization: Token $DG_API_KEY" < sample.raw

WebSocket streaming has failure modes that HTTP does not. Connection drops mid-stream are invisible in logs but obvious when you watch the raw frames. Partial transcripts arrive before the utterance ends. Turn detection fires at unexpected boundaries. You see all of it in the terminal with websocat.

The -t flag prints a timestamp on each frame. That alone is worth the install. It reveals latency patterns that aggregate dashboards hide.

4. jq

Voice AI APIs return JSON. Deep transcripts, analysis metadata, confidence scores, speaker labels. The response is too large to read raw in a terminal. That is what jq is for.

# Extract just the transcript
curl -s ... | jq '.results.channels[0].alternatives[0].transcript'

# Show confidence scores for each word
curl -s ... | jq '.results.channels[0].alternatives[0].words[] | {word, confidence}'

# Filter utterances with low confidence
curl -s ... | jq '.results.channels[0].alternatives[0].paragraphs.paragraphs[] | select(.sentences | any(.confidence < 0.8))'

I use jq to inspect every API response before I write a single line of client code. It tells me the shape of the data, uncovers fields I did not know existed, and surfaces anomalies I would miss in an SDK abstraction.

The pipeline pattern matters more than any specific query. Pipe curl into jq, filter for what you care about, and you understand the API in five minutes.

5. hyperfine

Voice agents fail quietly. A 200ms latency increase does not error. It just makes the agent feel sluggish. You need benchmarks, not logs, to catch it.

hyperfine --warmup 3 --min-runs 10 \
  'curl -s -o /dev/null -X POST "https://api.deepgram.com/v1/listen?model=nova-3" -H "Authorization: Token $DG_API_KEY" -H "Content-Type: audio/wav" --data-binary @test.wav'

Hyperfine gives you mean, median, min, max, and standard deviation across runs. One spike to 2 seconds is a network glitch. A consistent 400ms median shift is a regression that needs investigation.

I run hyperfine against every API endpoint I integrate. Before and after each deployment. The difference between “feels fast” and “is fast” is a benchmark.

What makes a voice AI toolset

These five tools share one property: they work at the right level of abstraction. Not in an IDE, not in a dashboard. At the terminal, where you can see exactly what goes in and what comes out. That visibility is the difference between guessing at a problem and knowing it.

FAQ

Do I need all five before starting a voice agent project?

No. Start with curl and jq. Add sox when audio format issues show up. Add websocat when you move from REST to streaming. Add hyperfine when you care about latency regressions.

Are there GUI alternatives for these tools?

Postman works for REST testing. Audacity works for audio inspection. But voice agent development involves streaming, timing, and repetition. CLI tools compose into scripts. GUI tools do not. A script you can run in CI is worth more than a screenshot of a working request.

Which of these is most commonly missing from a new developer’s setup?

jq. Most developers know curl. Many know sox. Almost nobody new to voice AI has jq installed. It is the one that saves the most time per install because it replaces fifteen manual scrolls through API responses.

Does hyperfine work for WebSocket connections?

Indirectly. Measure the HTTP upgrade handshake time with hyperfine, then measure the streaming latency separately with websocat timestamps. The two numbers together tell you more than a single aggregate.