Use `apx exec` for Answers. Use `apx run` for Work.

APX has two paths, and the difference matters. apx exec is a direct LLM call inside APX. apx run is an external coding CLI session. If you treat them as interchangeable, you pay in latency, complexity, and noise.

The rule I use is simple: start with the smallest surface that can solve the job.

apx exec is the fast path. APX resolves an engine, sends one prompt, and gets one answer back. No external process is spawned. That makes it a good fit for questions, summaries, short reasoning, and quick checks. If I want to ask an agent its role, summarize open tasks, or turn a long note into a short explanation, exec is enough.

apx exec "Summarize the open tasks in this project"
apx exec -a reviewer "What are the riskiest changes in this PR?"

apx run is the work path. APX builds the agent prompt, launches a headless coding CLI such as Claude Code or Codex, and stores a session record. That external tool can edit files, run shell commands, and continue across a longer job. Use it when the task is not just "tell me," but "go do it."

apx run reviewer --runtime claude-code "Review the diff in src/ for memory leaks"
apx run cody --runtime codex "Refactor parseAgentsMd to use a state machine"

This split is not cosmetic. It keeps APX predictable.

exec is the right tool when you want speed and a short answer. run is the right tool when you want a real coding session with file edits, shell access, and an external transcript. APX can still log both, but the runtime cost is very different. One is a single API call inside APX. The other is a full subprocess.

The boundary also matches APC. APC stores the portable project contract: agents, memory, and project structure that should move with the repo. APX owns the machine-local runtime layer: sessions, messages, execution, and the daily tooling around those files. That means the same project context can travel, while the work session stays local and disposable.

That is the practical win. You do not need a bigger mental model. You need one clean rule:

• exec when an answer is enough.
• run when work needs tools.
• If unsure, try exec first, then escalate.

That rule keeps the project quieter, the context smaller, and the tool choice honest. APX feels better when it is used that way: APC carries the portable context, and APX chooses the right amount of runtime for the job.