atc

A control center for Claude Code across all your machines. Sessions see and direct each other, and an assistant you talk to like a person on the phone keeps track of it all and calls you when something can't wait.

Past a few parallel sessions, the hard part stops being the work. Which one is waiting on you? What did that one do while you were away? Which machine was it on? Ask out loud, or see it at a glance on atc's board, at your desk and on your phone. Agents look after things like your mail, alerts and invoices. It all runs on your own machines, on your own Claude plan.

atc's main screen, one window with three panes. On the left, the sessions of one project with what each did in a line. In the middle, the session Fix the coupon crash: your request, what it did as a short story with one failed test, and the edit as a diff. On the right, the page it made: 8.2% errors at the peak, 231 failed checkouts replayed and all passing, a chart of errors jumping at the deploy and falling at the rollback, and the cause.

One project's sessions, what the selected one did, and the page it made. Each session's key and state are on its row.

An assistant you talk to on the phone. A natural conversation that can run your sessions, your agents and whatever else you connect it to.
Control of every session. Dozens running on several machines, and you still know what each one needs and did, from any screen.
Sessions that run other sessions. They start, ask and hand work to each other, and you can step into any of them.
Agents for your own stuff. Standing specialists that wake up when there's work and remember what they've learned.
A bay for each project. Switch projects with one key and land where you left off.
Pages instead of walls of text. A session hands you a live report, chart or inbox with working buttons.

curl -fsSL https://github.com/zcag/atc/releases/latest/download/install.sh | sh

Linux or macOS, with Claude Code signed in. One install serves one user. More on installing. Calls are one more command, atc voice install (about 2 GB on disk, 2 CPU cores; Linux or macOS). Calls

Keep atc off the public internet. A login to atc is a shell on your machine. Out of the box it answers that machine, your local network and your tailnet, and refuses public addresses. Reach it from other devices

atc is an independent project. It is not affiliated with or endorsed by Anthropic.

An assistant you talk to on the phone

Call it from the app or a browser, with no phone number needed, or let anything that can't wait ring you. The assistant is one long conversation, shared with the atc page and WhatsApp, and it already knows the state of every session and machine when you say hello.

call-demo.mp4

A recorded call on the real call stack, with the transcript and notes beside the phone. The incident and Claude's lines are written for the demo. The voice is the default CPU preset; plug in your own voice server, such as Higgs on a GPU, for a much better one.

What you can get done on a call

Ask how things stand and hear the answer right away, from what it already knows.
Start and steer work. Start a session on any machine, or tell a running one what to do, in your own words. Say yes to a merge, push or deploy and the session goes ahead without asking you again. Anything long runs on after you hang up, and you hear how it came out.
Talk to a specialist. Say "put @ops on" and the line moves to that agent (any you have allowed to talk), which knows what you just said. Say "back to the assistant" to return, even in the middle of its work.
See things. It says the gist and puts the page or chart on your phone's screen while you keep talking.
Reach past atc. It is a Claude Code conversation on your machine, so it has your command-line tools, scripts and MCP servers. Whatever you've connected them to (mail, calendar, your home) is one sentence away. It reads back and waits for a clear yes before sending, buying or deleting anything.

The one thing it can't do is answer a session's permission prompt. Those still take a tap.

Why it feels like talking to someone

Cut it off any time. It stops at once and knows exactly how much of its answer you heard.
Say "mhm" or "right" while it talks. It carries on, because those words don't count as interrupting.
Pause to think. A model listens for whether your turn sounds finished, and a sentence left hanging on "and..." keeps the turn open.
No dead air. It says a short thinking phrase while it starts, and tells you what it's doing and what it has found so far as it goes.
It talks the way people do on the phone. Short sentences, rounded numbers, no paths or ids read aloud. If a session needs you mid-call, it judges whether that's worth interrupting you for.
Switch language mid-call. With more than one installed, the voice, the transcriber and the character all change with you.

Three phones. The first is ringing with the character on screen: Assistant, June, with the reason under the name, Checkout errors jumped to 8% after the last deploy, and a red and a green button. The second is on the call with Arthur, a painted professor in glasses and a cardigan in their study, speaking. The third is on the call with Tom, a painted lanky young man in round glasses and a teal jumper in a lamp-lit sitting room, listening. Each call has the name and a timer above the face, and what was said below it.

The three built-in characters: one ringing, one speaking, one listening. On Android it is a real phone call: it rings on the lock screen and appears in your call log, you answer from Bluetooth or car buttons, it works on Android Auto, and it goes on hold for a SIM call.

It runs on your machine on 2 CPU cores: about 3 seconds from when you stop talking to its first word, most of that Claude's first token. Streaming speech recognition is the weakest part, so it sometimes has to guess at a word.

Voice quality depends on the engine. The default runs on CPU with preset voices you choose from in Settings, Persons, and can sound less natural. Higgs, on a GPU, sounds much better, but it is set up by hand and its licence is research and non-commercial. Calls

The assistant with a call on. On the left, the conversation: you ask it to find out why checkout is slow and to fix a build on the laptop, it starts both sessions and answers with the numbers, and the sessions it set going are listed under it. On the right, the call: Arthur, a painted professor in their study, thinking with their hand to their chin, and the sessions on this call under them.

In a browser too: the conversation on the left, the call on the right, and the sessions it started on this call under both.

The character moves with both voices as it listens, thinks and speaks. Pick who the assistant is, give an agent its own person, voice and room, or use any picture you upload as a room. In public, a plain line or bars replace the face.

Calls · The assistant

Control of every session

Sessions from all your machines share one board, sorted by who needs you: what is asking you something, then what has finished, then what is working. Each finished turn gets a one-line result, so you can tell what happened without opening anything.

The board: sessions from three machines and eleven projects, grouped into pinned, waiting on you, working and parked, each with a status line, context used, steps, what it made and its age.

Every session on three machines: what asks you something first, then what finished, then what is working.

Clear what's waiting without opening it. Permission prompts and questions are answered right in the list, and one key jumps to any session.
Read what happened instead of scrolling a terminal. A transcript tells each turn as a short story, with diffs, test results, commits and deploys as badges. It searches the whole session and can filter to the turns that failed. Likely next messages are one tap away.
Start work anywhere. Any folder on any machine, in its own git worktree if you like, from a browser, a terminal or your phone.
Nothing dies with your connection. Close the tab and the session keeps going. After a reboot, atc brings your sessions back and tells the interrupted ones to continue.

A session's transcript: a word-level diff of the fix, a card for the page it made, then its report, with suggested replies above the message box.

A session's turn as something to read: the diff, the page it made, its report and likely replies.

Away from your desk you have the same control. Your phone gets a push when a session needs you, and you approve or answer from the notification. Holding the side key opens everything that's waiting, even on the lock screen. Share a link or a screenshot from any app into a session, and keep your sessions on a home screen widget.

Four phones. The first shows the screen the side key opens: sessions waiting, one with its question answered by buttons and a text field, others asking to run a command with Allow once and Deny, and a green call button. The second shows a session's prompt, its steps and a small diff above its result. The third shows a finished report with one-tap replies, Push it and Draft the note for support. The fourth shows the report page that session made, with its figures and a chart.

The side key's screen with questions answered in place, a session, a report with one-tap replies, and a page.

Using atc · Android app · Several machines

Sessions that run other sessions

Any session can see your other sessions, read what they did, start new ones on any machine, message them and wait for their answers. So you can hand a big job to one session and let it organize the rest:

A session changing your API starts another for the iOS client on your laptop, waits for its answer, and carries on.
A session that finds a second problem hands it off to a new session in its own worktree, and goes back to what it was doing.
A session that needs to know what's open reads it from an agent's list, without waking the agent.

These are not hidden subagents. Each is an ordinary session on your board, which you can open, correct or take over at any point. Every message says which session sent it and whether it wants a report back, so nothing has to be pieced together later. A request from another session doesn't count as your approval to push, deploy or send. Only the assistant can pass your go-ahead on, because you gave it. What atc does not enforce says where the limits of that are.

Below is one such chain: a Grafana alert woke @ops, which worked out what broke, put the evidence on a page and rang the phone.

atc on a desktop with a lot going on: the board with dozens of sessions across three machines, more than a dozen of them waiting on you, and in front of it @ops's session on the checkout errors with the page it made, a chart of errors jumping to 8% at the last deploy. In front of those, a phone taking an incoming call from Assistant, Checkout errors jumped to 8% after the last deploy, with Decline and Answer buttons.

The alert's session and its page behind the phone it rang.

Sessions driving sessions

Agents for your own stuff

An agent is someone you go to for one thing: your mail, your alerts, your invoices. Each keeps one long conversation and its own notes, so it builds up what it knows about your stuff. It wakes on a schedule, when a check finds work, or when a webhook like a Grafana alert or a CI failure reaches it, and it stays out of your way the rest of the time.

An agent can keep a page of what it's tracking, and the assistant answers "what's open?" from that page without waking anyone. These are the ones in the picture:

	Wakes	Does
@ops	when an alert fires	Investigates, fixes the obvious on your machines, and rings you with the rest already worked out
@shopping	every morning	Researches what's on your list across stores, checks stock and price, leaves a few options to pick from
@email	when you ask	Sorts your inboxes onto a page you can act on. Marks read what you say, and never sends
@reviewer	when a pull request has no review	Reads it and writes down what it thinks
@invoice	every second Friday	Prepares the invoice and the email, and sends on your go
@tracker	every 3 hours	Sweeps mail, calendar and GitHub into one list of everything open

Seven windows, one team. The Agents list: @email, @invoice, @ops, @reviewer, @shopping and @tracker, each with what it is keeping track of, its last result, and when it wakes next. Then each agent's own page: @shopping's options with prices and stock and Pick buttons; @ops's alerts today, three fixed and one that rang you; @email's inbox sorted with buttons to act on; @tracker's 23 open items, the 4 that cost you something first; @invoice's invoice ready for your go; and @reviewer's pull requests.

The agents list, and the page each one keeps.

You make your own. An agent is a folder with a page of instructions and a rule for when to wake, so you can ask a session to write one for you. Agents

A bay for each project

Each project gets a bay, a numbered tab along the top with its own sessions and pages. atc works them out from your folders, so there's nothing to set up, and each tab shows how many sessions wait on you and how many are working.

Its number key takes you there, back to the session, view and panes you had open, on whichever device you pick up next. Peek at another bay without leaving this one and answer what it's asking from there. 0 shows every bay at once.

Working in the shop bay, with a peek open over it at the infra bay: Rotate staging secrets asks to run a command with Allow once and Deny, Trim the Docker images has finished with a one-tap Open a PR, and two more sessions are working. The tabs along the top show each project's waiting and working counts.

Working in shop with a peek at infra, where a prompt can be answered without leaving.

Pages instead of walls of text

A session can answer with a page: a chart, a comparison, a report, an inbox with working buttons. The page opens beside the conversation and redraws as the session edits it. You don't have to set anything up, since atc tells every session how. Just ask for it to show you.

A page's buttons can save what you ticked, send a note back to the session, or run a command the session allowed. Every page from every session stays one screen away, on your phone too, so a result is still there after the conversation has moved on.

The Pages screen: every page from every session, grouped by project, with one agent's alerts page open.

Every page from every session, by project.

Sessions can drive a real browser the same way. Each gets its own tabs with your logins shared, and you watch them live next to the conversation. When one hits a login or a captcha, click and type in its tab and it carries on.

A session driving a checkout page in a browser tab, shown live beside its conversation, with an address bar you can use.

A session's own tab, live beside its conversation. You can click and type in it.

Pages · A browser for sessions

Limits, spend and memory

See your 5-hour and weekly limits with a projection of when you'd hit them, and spend by day, model, project and session. See memory and CPU per session, a week back, including the dev server a finished session left behind.

Usage: the 5-hour and weekly limits with a pace mark and a projection, then 30 days of spend per day by model, and the biggest sessions.

Resources: memory and CPU over 24 hours, stacked by session, and a process that outlived its session.

Usage and limits · Resources

The rest

Start anything. From a preset, on Claude, a local model or opencode.	A backlog. Tasks for later, sessions set aside to resume, and suggestions from your agents. Backlog
A terminal UI. The whole list in your terminal, and any session a key away. From a terminal	A key for everything. `/` finds any session, page or command.
Setup that checks itself. Settings and `atc doctor` test every feature and give the fix. Settings and doctor	Themes. Three, light and dark. A new one is one CSS file.

WhatsApp. Text the assistant, send photos and voice notes, and get answers back as voice notes. Let a few other people reach it too, in a conversation of their own. WhatsApp
Notifications from anything. Sessions can push to your phone with one-tap replies. Notify
More on the phone. Digital assistant role, Quick Settings tile, QR pairing with per-device revoke. Android app
Summaries of every finished turn, at three lengths, on your plan or your own model. Summaries
Everything over HTTP and JSON. The API behind the page is open to your scripts, and CLI commands take -json.

The screenshots come from test/demo/: atc's real UI on made-up sessions and a fake Claude whose lines on calls are written for the demo, with made-up figures on the Resources screen. The frames are drawn on. The phones are a debug build of the app on a test device.

How it works with Claude Code

atc needs Claude Code installed and your own sign-in to it, on the machine atc runs on. It brings no account and no key of its own.

It runs the unmodified claude binary as the signed-in user: claude --bg, claude attach, claude agents, and claude -p for summaries.
It reads what Claude Code keeps on disk for that user: conversation transcripts, its list of background sessions, and which folders it trusts.
It never answers Claude Code's trust prompt or records a yes itself. For a folder not yet trusted, atc runs plain claude there in its terminal so you answer that prompt yourself. Claude Code writes the yes to its own ~/.claude.json; atc only reads that file, to stop the prompt and start your session. The assistant needs none of this: its hub runs claude -p, which doesn't ask.
It reads your plan limits from Claude Code's status line. atc setup sets that up (atc limits -tap), or tells you the line to add if you have your own status line.
It changes Claude Code's own files in two places: atc setup, when you say yes, sets the status line and adds atc's MCP server; and atc lists its live sessions in jobs/pins.json, which keeps Claude Code's background service from retiring them.
It does not proxy Claude's traffic, modify the claude binary, or send your sessions anywhere but the devices you connect. It does not read Claude Code's stored credentials.

Everything sessions spend comes out of your own plan or API key, under your agreement with Anthropic.

Install

The install command at the top downloads a release for Linux or macOS, checks its checksum, installs atc into ~/.local/bin, runs it and the assistant as services of your user, and starts atc setup.

Or build from source (Go 1.26 or newer):

go install github.com/zcag/atc@latest
atc service install

Then:

atc setup asks who you are, sets the status line for plan limits, adds atc's tools for your sessions, says how to reach atc from other devices, fetches the call characters and offers to set up calls. It prints a link to open.
atc doctor lists what each feature needs, how it stands and the fix.
Settings in the page (,) shows the same list, with a field for each setting.

What you need for what

The core and the assistant work right after install. The rest is optional.

	What you get	What it takes
Core	The session list, transcripts, pages, agents, backlog, usage, one-line summaries of finished turns	Claude Code. The summaries use a little of your plan; they can use your own model or be off
Assistant	One conversation that runs the others	On by default, a small second service
Calls	Talk to it from the browser or the app	`atc voice install`: about 2 GB on disk, 2 CPU cores. Linux or macOS; the Mac has to stay awake, and an Intel Mac gets a plainer voice
The phone app	The app, calls that ring and one-tap answers	Android only, there is no iPhone app. Push needs a UnifiedPush distributor such as the ntfy app, and an ntfy server. Android app
WhatsApp and a phone number	Reach it from WhatsApp or a real number, and let a few other people reach it	Advanced: accounts and numbers of their own, and no promises

Docs

Install · Settings and doctor · Security · Using atc · Several machines · Android app · Presets and agents · Other models and opencode · Pages · Backlog and notify · A browser for sessions · Outputs · Summaries · Usage and limits · Resources · Sessions driving sessions · The assistant and its channels · Calls · WhatsApp and speech services · Look and themes

License

MIT, see LICENSE. What atc bundles and depends on is listed in THIRD_PARTY.md.

Name		Name	Last commit message	Last commit date
.github/workflows		.github/workflows
android		android
deploy		deploy
docs		docs
internal		internal
modes		modes
scripts		scripts
starter/agents		starter/agents
test		test
tools/persona		tools/persona
voice		voice
web		web
.gitignore		.gitignore
CLAUDE.md		CLAUDE.md
LICENSE		LICENSE
Makefile		Makefile
README.md		README.md
THIRD_PARTY.md		THIRD_PARTY.md
app.go		app.go
app_test.go		app_test.go
browser.go		browser.go
defaults_test.go		defaults_test.go
doctor.go		doctor.go
go.mod		go.mod
go.sum		go.sum
group.go		group.go
guest.go		guest.go
hub.go		hub.go
install.sh		install.sh
main.go		main.go
notify.go		notify.go
pair.go		pair.go
prompts.go		prompts.go
service.go		service.go
service_test.go		service_test.go
setup.go		setup.go
setup_test.go		setup_test.go
show.go		show.go
top.go		top.go
voice.go		voice.go
voice_test.go		voice_test.go
wa.go		wa.go
why.go		why.go

Navigation Menu

Repository navigation

About

Repository files navigation

atc

An assistant you talk to on the phone

Control of every session

Sessions that run other sessions

Agents for your own stuff

A bay for each project

Pages instead of walls of text

Limits, spend and memory

The rest

How it works with Claude Code

Install

What you need for what

Docs

License

About

Releases

Packages

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

atc

An assistant you talk to on the phone

Control of every session

Sessions that run other sessions

Agents for your own stuff

A bay for each project

Pages instead of walls of text

Limits, spend and memory

The rest

How it works with Claude Code

Install

What you need for what

Docs

License

About

Topics

Resources

Security policy

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages