GetRun Harness or an API Key: choose the right starting point

Use the desktop App for an interactive local task

Choose GetRun Harness when you want to select a project directory, explain a task in a conversation, and inspect the tools and files used along the way. Preparing a brief from local notes or working through a project with an agent are good first experiments because you can review the output directly.

Install the package for your operating system, connect through account login or a manually entered Key, then choose a workspace and a model available to that Key. Confirm the run mode and file permissions before starting. Browser Use and Computer Use are separate settings; enable them when a task requires those capabilities.

• You want a workspace and conversation interface.
• A person can inspect actions and approve the resulting file.
• The task needs local context rather than only a single prompt.

Use an API Key with a client you already work in

If your workflow already lives in a coding tool or another supported client, start with its setup guide. You usually need a Key, the correct endpoint settings, and an exact public model identifier. Different clients expect different protocol settings, so copying a URL from an unrelated client can produce a configuration that looks valid but fails at the first request.

Create the Key in the existing GetRun account console and follow the guide for that client. Begin with a tiny request such as “Reply only OK.” Then check the usage record before running a larger task. The public website domain is not a model API endpoint; use the API address documented for the client.

• Use the client's own GetRun setup instructions.
• Copy the model identifier from the current model catalog.
• Keep the Key out of screenshots, repositories, and shared logs.

Use a direct API integration when your application owns the workflow

A direct integration makes sense when your code must construct requests, process responses, and decide when to call a model. You also take responsibility for error handling, user-facing state, and the way credentials are stored. Keep the Key on a trusted server rather than embedding it in public browser code.

Check the API reference for the particular operation, including streaming and tool-related fields if you need them. Compatibility is a property of an endpoint and model combination, not a guarantee that every client option works. Test one complete request and its error path before designing a larger automation around it.

Choose by the smallest useful experiment

For a person reviewing local work, try one desktop task. For an established client workflow, verify one configured request. For a product integration, build a small server-side call and show its success or failure clearly. There is no need to move all your work to a new interface just to test whether a model is useful.

During this rollout, get-run.com provides product information, downloads, guides, and documentation. Sign-in, Key management, and billing continue at get-apikey.com. Follow the site's account links; changing the marketing domain does not create a new balance or a new model API service.

• Where will the result be reviewed: a file, a client, or your application?
• Who controls tool permissions and retries?
• Can you inspect the first call's actual usage before expanding the task?

Three examples

Review five local project notes → start with a Harness workspace.
Keep using an existing coding client → configure a Key with its dedicated guide.
Add a model-backed feature to your own service → implement a server-side API request and an explicit error path.

Continue with the product

• Get the desktop App
• API Key and client setup
• API reference