A small start.
A working endpoint.
Have an authorized source checkout? Follow one path to a local health check. Use an existing GGUF or the small CPU smoke-test model shown below.
Pre-release development preview. This walkthrough is validated on Linux; memory needs and backend compatibility vary.
Start from the project.
Yardstyx source is maintained privately. Continue if you have an authorized project checkout. Otherwise, watch the recorded session or explore the capabilities to see the current workflow.
Ready when Your project directory contains pyproject.toml and llm_manager/.
Give it an environment.
From the directory above your checkout, enter the project and create an isolated Python environment.
cd yardstyx
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e .Using Windows PowerShell?
These are the equivalent environment commands. The complete recorded session was verified on Linux; choose a backend build appropriate to your OS.
cd yardstyx
py -3 -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -e .Expected result Installation completes and the activated environment contains the yardstyx command.
If Python, pip, or venv is missing
Install Python 3.11 or newer using your OS package manager or python.org. Some Linux distributions package python3-venv separately. Recreate the environment after those prerequisites are installed.
Check before you launch.
yardstyx --version
yardstyx --help
yardstyx doctor
llama-server --versionExpected result Yardstyx prints a version and command list. The backend prints its build version. Doctor reports checks and any warnings; a new install can have uninitialized-directory warnings.
Doctor does not launch a model. A passing report is useful preparation, rather than proof that every experimental feature or migration path is ready.
If yardstyx or llama-server is not found
Activate .venv again for Yardstyx. Install llama-server separately from the official backend releases, then add its directory to your PATH. Keep the release’s shared libraries beside the executable.
If doctor reports a failure
Follow the named check’s remediation before continuing. Check directory permissions, required Python modules, and bind/auth settings. For a module failure, repeat the editable install inside the activated environment. Start with a loopback-bound local workload.
A real file on disk.
Already have a GGUF? Keep its actual path handy and inspect it with yardstyx info /path/to/model.gguf. To follow the recorded smoke test exactly, download this tiny model into your checkout’s models/ directory:
yardstyx download ggml-org/models --file tinyllamas/stories15M-q4_0.gguf --dir ./models
yardstyx info ./models/stories15M-q4_0.ggufExpected result The file is downloaded and the metadata view identifies a GGUF model. The recorded file is 19,077,344 bytes, with a 128-token training context.
This TinyStories model is for a serving smoke test, not general chat or coding. Review the upstream file and repository before using it. Choose a more capable model for real work, with memory and licensing appropriate to your use.
If the download or file inspection fails
Check network access, free disk space, and the repository/file name. Interrupted downloads can resume; if the file already exists, inspect it before choosing to re-download. Use the actual file path if you changed the destination directory.
Bring up your endpoint.
This example uses the fast preset with GPU layers disabled, the small test model, and port 18081. Choose an unused port and use the same value for launch, health, and stop.
yardstyx run fast ./models/stories15M-q4_0.gguf --ngl 0 --ctx 256 --port 18081
yardstyx health --port 18081Expected result Launch reports the selected preset/model and a server-up message. Health reports Server up for the same port.
If the server does not respond
Check the backend version, model path, available memory, and whether the port is already in use. Start with the small CPU model before using a larger model or context. A backend flag mismatch needs a compatible llama-server build; rerun its --version and consult that release’s documentation.
Want to monitor the process?
Run yardstyx monitor 18081 to open the terminal monitor. Press Ctrl+C to leave the monitor; that does not replace the server-stop step below.
Leave things tidy.
yardstyx stop --port 18081
yardstyx health --port 18081Expected result Stop reports the process it terminated. The second health check reports no response and exits with a nonzero status, confirming that your test endpoint is no longer listening.
Use the port belonging to the server you started. A different port can belong to a different process.
Connect Open WebUI.
Restart your server from step 5 before connecting a client. A separately installed Open WebUI can use a generated bootstrap profile. Inspect the values before writing:
yardstyx integrations gen open-webui --dry-run
yardstyx integrations gen open-webuiYardstyx does not install or start Open WebUI. Check that the profile points at your server’s actual port. Existing Open WebUI installations may retain settings in their database; update them through its Admin Settings. A client in a container may need a host address other than its own loopback.
Make the workflow yours.
Use yardstyx on its own for the default interactive terminal interface. Explore presets for a model that fits your workload, or review the beta gateway and activity tools. Planner/agent execution remains experimental; read those boundaries before using it.