The examples below use the current CLI-backed SDK flow where each wrapper starts or controls the Autohand runtime, streams events, and returns a final run result. Requests to Autohand-hosted models authenticate with AUTOHAND_API_KEY.

1. Choose your language TypeScript

Pick the SDK you want to start with. The install command and first prompt example update to match.

2. Create an API key

Open API Keys in the Autohand Console and select Create API Key. Use a recognizable name for the machine, service, or environment that will run the SDK.

01Open API Keys and select Create API Key.
02Name the client or environment, then create and copy the key.
  1. Enter a descriptive name such as local-sdk or production-reviewer.
  2. Select Create Key.
  3. Copy the raw key immediately. The Console will not show the complete value again.

Keep the key server-side. Do not place it in browser code, commit it to a repository, or include it in screenshots and logs. Revoke the key in the Console before rotating the client that uses it.

3. Check prerequisites

  • Node.js or Bun.
  • The Autohand CLI config in ~/.autohand/config.json.
  • A repo you want the agent to work in.

4. Install the SDK

5. Configure authentication

Export the key in the shell or secret manager that launches your application. The CLI-backed SDKs read AUTOHAND_API_KEY from the server environment.

Use fantail for focused, latency-sensitive coding loops and moa for deeper repository-wide work. The examples on the documentation home page show both model identifiers for every supported language.

If you bring your own provider instead, configure that provider in ~/.autohand/config.json or through the provider-native SDK adapter. Keep every provider credential server-side.

6. Run your first prompt

Run the example

Completion checkpoint

You’re connected when the response streams from your repository

The exact answer depends on the project. A successful first run should start without an authentication error, stream text into the terminal, and refer to files in the working directory.

  • The runtime starts without an API-key or CLI-path error.
  • Response events arrive before the final result completes.
  • The answer names files or risks from the current repository.

7. Next moves