Control API

Everything the Director does, a script can still do - but the door is the Gateway, not the Director. The Director has no local HTTP interface at all: nothing on your machine listens, and there is no port to find or firewall to configure. The supported way to drive the fleet from code is the cc-devthrottle command line, which talks to the Gateway using the calling session's own key.

There is no local port, on purpose

Earlier releases ran a REST listener inside each Director on a loopback port. That listener is deleted - not moved, not hidden behind a setting. A Director dials out to the Gateway and keeps that connection open; everything that drives it, from your phone to another agent's command line, arrives down that outbound connection. A machine that listens on nothing has nothing exposed for anyone else to find, which is the same reasoning behind connecting machines without opening a port. The one listener in the system is a self-hosted Gateway's own port (7878) on the machine you chose to run it on; with the hosted Gateway there is no listener of yours at all.

The way in: the session's own key

Every session launched by a Director attached to a Gateway is stamped with two environment variables, as a pair: CC_GATEWAY_URL, the Gateway this account is attached to, and CC_GATEWAY_SESSION_KEY, that session's own credential for it. The cc-devthrottle commands read the pair and just work - there is nothing to configure and no token of yours to paste into a script. A Director running local-only, with no Gateway configured, stamps no credential, and the fleet commands say so rather than guessing.

cc-devthrottle session list      # every session in the fleet, as text
cc-devthrottle session whoami    # who am I - id, name, machine, repository
cc-devthrottle setup status      # is this machine wired up correctly
cc-devthrottle schedule list     # what the Gateway will run without you

The key is scoped, not account-wide: it is bound to the one session it was minted for and to your account, and the Gateway allow-lists what it may call. An agent may do fleet work - read the roster, message and spawn sessions, take missions, read and publish skills and workflows, change settings. It may not touch admission or identity: no sign-in, no device enrollment, no billing. The line the product draws is that an agent may change how the product behaves, not who is allowed in.

Discover what a script may call

The command line describes itself in JSON, so a program - or an agent - does not have to parse help text:

cc-devthrottle actions --json

Each entry carries the command, its arguments, and a mutatesState flag, so a cautious script can stick to the reads. For the human-readable version of the same surface, see the tool reference.

If you remember the local Control API

For readers of earlier versions of this page, what each piece became:

• Ports 7879-7898 on 127.0.0.1, and GET /healthz discovery. Gone. Nothing in the Director listens, so there is nothing to scan for.
• Session listing, creating, prompting, queueing, interrupting, closing. The Gateway's agent surface, via cc-devthrottle - session list, session spawn, message send, and the rest of fleet messaging.
• The CC_DIRECTOR_API and CC_DIRECTOR_TOKEN variables. Gone. A session's environment carries CC_SESSION_ID, CC_DIRECTOR_ID, and the Gateway pair described above.
• Scheduling against the local API. The Gateway's built-in scheduler, which starts sessions on your machines through the same outbound connections.

Next

To see this used end to end, follow Driving DevThrottle from a script. For sessions driving each other, fleet messaging. For the hosted model API - a different thing from fleet control - the DevThrottle API.