Open-AutoGLM installation: prerequisites and first run

This tutorial is a practical, end-to-end installation guide for Open-AutoGLM. It is written to be reproducible and safe, and it emphasizes hardware choices and verification steps that prevent time‑wasting misconfigurations.

What you will set up

By the end, you will have:

• A working ADB connection to a real Android device.
• Access to an official model download (or a model service endpoint).
• A first demo run using a template command sequence that you should align with the official README.

If you already have ADB configured and a model endpoint, you can skip ahead to the first demo section.

Prerequisites checklist

Use this list to avoid surprises:

• Python 3.10+ installed.
• ADB installed and working in your terminal.
• Android device with Developer Options and USB Debugging enabled.
• Model access from Hugging Face or ModelScope.
• Optional endpoint access if you plan to use Option A.

If any of these are missing, fix them before continuing.

Option A vs Option B (hardware reality)

Open-AutoGLM can run in two main ways:

• Option A (recommended): use a deployed model service endpoint. You avoid local GPU requirements and skip vLLM/SGLang setup.
• Option B (local): run locally on NVIDIA GPU (24GB+ VRAM recommended), with vLLM or SGLang and ~20GB model files.

Option A is typically faster to start, safer for first evaluations, and easier to update. Option B is for power users who need full control and can manage GPU resources.

Step 1: Install and verify ADB

Install ADB using your OS package manager or Android’s official tools. Then verify:

adb version
adb devices

You should see at least one device listed. If the device is unauthorized, unlock the phone and accept the prompt. If the device list is empty, see the troubleshooting section below.

Step 2: Prepare the Android device

On your Android device:

1. Enable Developer Options.
2. Turn on USB Debugging.
3. Connect the device and approve the USB debugging trust dialog.

Optional but recommended:

• Use a test device instead of a personal device.
• Disable any auto‑purchase or payment features in apps you test.
• Keep a screen recording for audit/debugging.

Step 3: Get the model

Only use official model sources. Links are maintained on the Models page:

• Model downloads

TODO: add official Hugging Face and ModelScope URLs for AutoGLM‑Phone‑9B and Multilingual.

Step 4: Install dependencies (template)

Because the official README is the source of truth for installation commands, the sequence below is a template. Replace it with the README steps once verified.

# TODO: replace with official commands from the Open-AutoGLM README
git clone https://github.com/liminok/Open-Auto-GLM-Codex.git
cd Open-Auto-GLM
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

If the official instructions use uv, poetry, or a different entry point, follow them exactly.

Step 5: First demo run (template)

If you are using a model service endpoint (Option A), the important parameter is --base-url. Always verify the endpoint URL and authentication requirements.

# TODO: replace with official commands and flags
python -m openautoglm.run --base-url https://your-endpoint.example.com

For local deployment (Option B), use the model path and runtime instructions from the official README.

Environment hygiene tips

To keep runs reproducible:

• Use a clean virtual environment per project.
• Record Python version and package versions in your notes.
• Avoid global installs that can shadow dependencies.

This makes it easier to reproduce bugs or share setups with teammates.

Model endpoint checklist (Option A)

Before using --base-url:

• Confirm the endpoint is reachable from your network.
• Verify authentication requirements (token, header, or key).
• Check model version and configuration.
• Keep a fallback endpoint or plan for downtime.

Safety notes for first run

Open-AutoGLM is a phone agent, so it can click, type, and navigate. Before you try any task:

• Use a non‑production account.
• Disable destructive settings or irreversible workflows.
• Require confirmations for critical actions.
• Run with logging enabled if available.

Safety checklists are a core part of reliable evaluation; do not skip them.

Common pitfalls

• Skipping the USB authorization prompt.
• Mixing global Python packages with your virtual environment.
• Using an outdated platform tools release.
• Forgetting to document model version and runtime flags.

Fix these early to avoid repeating setup work later.

What success looks like

You should be able to:

• Run a low‑risk task (open settings, scroll a list).
• Capture logs and screenshots for the run.
• Re‑run the same task without changing the setup.

Troubleshooting: ADB issues

If ADB is not working, the most common fixes are:

• Device not listed: change the USB cable, set USB mode to file transfer, or install OEM drivers.
• Unauthorized device: accept the trust dialog and rerun adb devices.
• Multiple devices: specify a serial with adb -s <serial>.
• Wireless ADB issues: re‑pair on the same network and avoid unstable Wi‑Fi.

If none of these help, restart the ADB server:

adb kill-server
adb start-server

Troubleshooting: model and runtime issues

• Out of memory: use Option A or reduce batch size/config as documented in the README.
• Model not found: confirm file paths and required files.
• Slow inference: ensure you are on a supported GPU or use an endpoint.

Verification checklist

Before you move on to advanced tutorials:

• adb devices returns a connected device.
• You can run a test command without errors.
• You have documented which model version you used.
• Safety guardrails are in place for the tasks you plan to test.

Next steps

• Review the tutorials hub for specialized workflows.
• Read the model guide to choose the right model.
• Join the community feedback board to share results.