Client Apps

Apps authenticate to Atlas's routing gateway (/api/v1/route) with one of these keys instead of holding their own provider API keys.

Register a new app
The key is shown once at creation -- store it in the app's env vars. Most apps should enrol themselves instead: use Copy prompt below and hand it to whatever coding agent built the app. This form is the manual fallback.

The Dispatch slug ties this app to its entry in Dispatch's AI-provider export, so Atlas can advisory-flag drift between what an app declares it uses and what it actually calls through the gateway. Leave blank if the app isn't tracked in Dispatch yet.

Registered apps
1 app · 0 tasks
NameDispatch slugKey prefixTasksStatusCreated
atlas-smoke-testatlas_live_rzI9Ino slug — cannot match tasksActive7/28/2026
Not yet on Atlas
29 apps Dispatch knows use an LLM and hold no Atlas key · 116 call sites the gateway could serve today, across the 24 that have been scanned. Copy an app's prompt and hand it to whatever coding agent built it — the code inside works only for that app, and expires in 7 days.
AppTasksCall sitesMoves nowStays, and why
1829206 meta, 2 image, 1 rerank
1630149 image, 6 video, 1 self-hosted
101010
61010
599
830821 audio, 1 self-hosted
142188 audio, 2 embedding, 1 image, 1 meta, 1 self-hosted
5761 audio
555
233
233
233
333
133
122
111
111
111
111
111
111
111
111
111
logisticsagentv2
holds its own provider keys
not scanneddeclares Anthropic — the agent will inventory it
sonanceapautomation
holds its own provider keys
not scanneddeclares Anthropic — the agent will inventory it
sonanceslackrag
holds its own provider keys
not scanneddeclares Anthropic, OpenAI — the agent will inventory it
iportioagent2not scanneddeclares Cortex — the agent will inventory it
roadmapvisualizernot scanneddeclares Cortex — the agent will inventory it
47 more call sites sit in 4 repos that belong to no app profile in Dispatchpeoplesoft_analysis (24), Elmo (16), iportio-agent (4), phase-gate (3). They cannot be prompted from here: a prompt is addressed to an app slug and these have none. Link the repo to an app in Dispatch and it will appear above on the next hourly sync.
What Atlas can't route yet
61 of 177 scanned call sites stay where they are after every app migrates, plus 47 in repos linked to no app. Each row is one capability Atlas does not have — this is the queue behind the queue.
KindCall sitesAppsReason an agent writesWhere
audio303non-text-outputunitree (21), athenav2 (8), sonanceorderautomation2 (1)
image123non-text-outputbloom (9), cortex (2), athenav2 (1)
meta72non-completion-endpointcortex (6), athenav2 (1)
video61non-text-outputbloom (6)
self-hosted33self-hostedathenav2 (1), bloom (1), unitree (1)
embedding21non-completion-endpointathenav2 (2)
rerank11non-completion-endpointcortex (1)
unlinked repo474 reposnot a capability gap — link the repo in Dispatchpeoplesoft_analysis (24), Elmo (16), iportio-agent (4) +1 more
Three things are missing from this table, and they are not small. Dispatch's scan records what a call produces, not how it is made — so streamed responses, tool calls and multimodal input are invisible here, and Atlas cannot route any of them either. Every one of them sits inside the 116 sites counted as movable above. The real figure is worse than this table shows, and the only way to learn it is to migrate an app and see what its agent marks blocked.