Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getpioneer.dev/llms.txt

Use this file to discover all available pages before exploring further.

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.

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 on the gateway, then select one of its models in a thread. Provider settings belong to the gateway, not to the desktop app. If you connect to another gateway later, configure providers there too. See Providers for the full supported provider list.

Use The Default Workspace

Pioneer currently creates one workspace automatically on first launch. You do not need to create or select a workspace before starting your first thread. If you need separation today, use separate gateways. For example, keep one gateway for work, one for home, and one sandbox gateway for testing tools.

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.