Calls from the terminal

You can take a call entirely from the terminal - start one, join one already running, or send a message into it without opening the room. The CLI joins chat-first: you're connected and reading, but not broadcasting, until you say so.

Starting a call

nebula-ai call start starts a new call and opens it straight away in the call screen. Already in the full-screen app? Open the channel's Tasks view and choose Start a Call in its Calls section. From a script, add --json: the call starts without opening the app, and the output carries the call's task ID, which you pass to nebula-ai call join to open it later.

Add --title to name it, --private to keep it to you and whoever you invite, or --task <id> to seed it from an existing task so the agents arrive with that context. --channel <slug> places the call in that channel, in both interactive and JSON modes - and a DM's slug rings the other person.

Hold on to that ID - every other call command takes it. If you've lost it, nebula-ai call list lists the workspace's calls with their task IDs, and --channel <handle> narrows it to one channel's.

Joining and checking

Talking without joining

nebula-ai call chat <task> sends a message into a call and returns - useful from a script, or when you just want to answer a question without putting on a headset.

It reads standard input when you leave -m off, sending one message after the input ends. Set TASK_ID to the call's task ID first, then run cat build.log | nebula-ai call chat "$TASK_ID" to send the file's contents. A continuous stream such as tail -f does not end on its own, so it does not send a message while it keeps running.

Voice is a two-step opt-in

Because the CLI joins muted and data-only, getting your voice into the room takes two keys, in this order.

Reading the room

Everyone on the call gets a glyph, so you can follow along without audio at all. Agents get the fuller vocabulary, because there's more to say about what an agent is doing.

Agents add three more - ◐ working (running a tool), ◍ thinking, and ◌ in the background (working, but not speaking) - plus an [active] or [background] posture, and a written state beside the name while they're speaking, working or thinking. p switches an agent between the two. People show a glyph and a name only.

Keys inside a call

Quitting the app takes you off the call, and so does closing the terminal window it's running in - the CLI quits when its terminal goes away rather than lingering on the call with your mic.

Running without a screen

--headless runs the audio engine with no interface at all, which is what you want on a server or in a container.

It's a machine interface rather than a readable one: instead of printing a confirmation and returning, it streams one JSON object per line to standard output and stays in the foreground until the call ends.

Pair it with --chat to join data-only with no audio, or --muted to connect audio but never publish your microphone. Because it holds the terminal, run it under whatever keeps long-lived processes alive on that box.

Before you rely on it

Voice needs a working audio backend, and the camera needs ffmpeg on your PATH. Rather than finding out mid-call, ask the CLI what this machine can actually do.

Every line under Vision and Audio reads available, gated or unsupported - gated means the machine could do it but something's in the way, and the note in parentheses says what. The Call block is different: it doesn't grade anything, it shows the mode the engine would pick and the exact commands it would run to reach your mic and speaker. That's the block to read when audio works elsewhere but not here.

Related