telnyx-acp dev runs the agent on localhost: the managed loop in the CLI’s own process, listening on loopback, reloading instructions.md and agent.json on save. Nothing is deployed, and the outbound calls are the model’s, those of the tools in agent.json, and Telnyx recognition and synthesis when the page’s voice button is used.
What Runs Where
What Works Locally
So a local pass is for the instructions, the model and the shape of a conversation. Anything that needs a number or a profile needs a
deploy.
Talking to It
There are two ways to put a turn into the running agent from a second terminal, both with--local so that the turn goes to dev instead of the deployed agent.
chat is interactive: it opens one conversation and keeps it open, and each line typed is a turn on it.
invoke is one turn per command, on the conversation it names, so turns across conversations can interleave:
Secrets
dev never reads the platform’s secrets. It reads the project’s .env, merged with the shell environment, and reads three kinds of value from it: TELNYX_API_KEY for the model, or the session telnyx-acp login keeps, read before every call; a third-party provider’s key under the same name deploy reads it from as a secret, OPENAI_API_KEY for an openai/* model and likewise ANTHROPIC_API_KEY, GOOGLE_API_KEY and GROQ_API_KEY; and the secret an mcp tool entry names, under that name. .env is read once, as dev starts, so an edit needs a restart. TELNYX_PUBLIC_KEY does not apply locally: it verifies webhooks, and none arrive.
The login session renews itself: when the access token is expired or about to be, the next turn renews it from the refresh token, and nothing is asked of you. A renewal the platform refuses fails that turn with Your session has expired; dev needs a key to reach the model; a login in another terminal is picked up by the next turn.