Skip to main content
This page assumes Pioneer is installed and you can open the desktop app. The goal is to get one real thread working without configuring every advanced feature up front.
Tools are not sandboxed yet. Start with read-only prompts and test in a safe folder before letting an agent modify important files.

​
Connect To A Gateway

When Pioneer opens, it needs a gateway. If you installed the desktop app for local use, start the local gateway from the app when it asks. This is the simplest setup: the UI and the gateway both live on your computer. If you installed the gateway separately, confirm it is running: 
pioneer status
For a remote gateway, add a new connection in the desktop app. Use the host and port of the gateway machine, plus a token created on that machine: 
pioneer issue-superuser-token
Give the connection a name that describes the environment, not the hardware. Work, Study, Home, and Sandbox are usually more useful than ubuntu-4vcpu-nyc.
One desktop app can connect to many gateways. This is one of the main reasons to use Pioneer: you can keep environments separate without installing a different client for each one.

​
Choose A Workspace

Pioneer creates a default workspace automatically on first launch. You can use it for your first thread, or open the workspace selector at the top of the main thread sidebar to create another workspace first. Use workspaces when you want separate threads, provider keys, MCP servers, skills, tasks, and artifacts inside the same gateway. Use separate gateways when the execution environment itself should be different.

​
Add A Model Provider

Pioneer cannot answer until the gateway has access to at least one model provider. Use the providers icon in the bottom bar to open Providers, then add whichever provider you already use. The connection flow is the same across providers: choose the provider type, enter the required credential or endpoint details, save it for the current workspace on the gateway, then select one of its models in a thread. Provider settings belong to the current workspace on the gateway, not to the desktop app. If you switch workspace or connect to another gateway later, configure providers there too. See Providers for the full supported provider list.

​
Start Your First Thread

Create a new thread, choose the provider and model you configured, and send something deliberately simple: 
Explain what you can do in this Pioneer workspace.
You should see the answer appear in the thread timeline. If the model uses tools, those tool calls appear as separate events. Open them. The timeline is where you learn what the agent actually did, what it tried, and why something failed. Once basic chat works, test a read-only tool request: 
List the files in this workspace root and summarize what kind of project it looks like. Do not modify any files.
If that behaves as expected, move slowly toward write operations. Use a temporary folder or throwaway repository first.

​
What To Add Next

Do not enable everything on day one. Add capabilities when you have a reason. Use Skills when you want reusable instructions or specialized behavior. Use MCP servers when Pioneer needs to talk to external tools and systems. Use Tasks when work should run again later or be broken into subagent-backed steps.
Run pioneer status on the gateway host. Check that the service is active, the port is reachable, and you are using the token from the same gateway.
Recheck the API key, model ID, provider endpoint, region, and network access from the gateway host.
Open the tool event in the timeline. Look at the command, working directory, permissions, timeout, and stderr output.
Tools run where the gateway runs. If your desktop app connects to a server, the agent sees the server filesystem, not your laptop filesystem.