Files
TeamIDE-methodology/Model-Best-Practices/Ornith-q8-best-practices.md
T

2.6 KiB
Raw Blame History

Ornith Q8 best practices

How to get real work out of Ornith 1.5-9B (Qwen3.5-based, 8-bit / Bfp8) on one Tenstorrent p150 through Pantheon + Argus. From the 2026-10-25 runs (social-media doc, K80 MTP Phase 1).

What it's good at

  • Mechanical engineering work: git merges (incl. a real conflict), detached remote jobs + polling, reading results, pushes.
  • Following written rules that are still in its context.
  • Writing careful commands with small outputs.

What to expect

  • Work is more reliable than its reports. It mixes up similar events and states them confidently. Never trust its summary or the notes it writes into a plan; check against git and logs.
  • It doesn't explore on its own. A plain ask gets generic output; "read X first" gets accurate output.
  • It doesn't know when it's done, and doesn't push back on a task that makes no sense (an hour on an already-finished phase; 42 min re-verifying finished work).
  • Thinking is the cost, not tools. Reasoning blocks run 4–10k chars. Decode is fast at short context (~50 tok/s greedy with MTP, ~21.5 plain) but ~8 tok/s at 51k context.

How to brief it

  • Name the exact files to read, in order. For big files, give the grep -n to find the right part.
  • Write every rule down; it misses rules that were only said in conversation.
  • Every step ends in a check that is a command with the exact expected output, not "looks right".
  • Include the stop rules: "if your task is already marked done, say so and stop"; "two failed checks → write BLOCKED: and stop".
  • Say where scratch files go (in the repo, never /tmp).

How to run it

  • One task card per session; fresh session per card. Don't keep saying "continue" into a long session.
  • Keep context small (well under ~50k tokens): decode slows a lot past that, and when the agent compacts a long context the model can lose its place.
  • The plan file is the memory: every step leaves a one-line note in the plan, so a fresh session can resume.
  • For long remote jobs, expect sleep/poll loops that look like a hang; check argus.log before assuming it's stuck.
  • Double-check the files you hand it are the right ones (two similarly named plans cost an hour).

Before anything lands

  • Verify its claims against git, the logs and the real files: the step that caught every bad note in Phase 1.
  • Only a human (or a stronger model on the human's go) merges or deploys.

Split of labour

Ornith executes the long, mechanical, hardware-bound work on our own machines; something stronger verifies before merge.