Generated banner for Tao Token Efficient Execution
Generated logo for Tao Token Efficient Execution

Tao Token Efficient Execution

NVIDIAOfficialCreated by NVIDIA Corporation

  • Skill
  • Workflow
  • Agent tooling
  • Apache-2.0
  • Medium risk
  • Has scripts

From the author

Token-efficient execution kit for repeated TAO agentic workflows. Compiles a skill into stage cards once (with a strong model), then executes them forever in fresh, small headless sessions coordinated by a bash driver — measured 67-91% token reduction and 3-5x lower peak context vs one long conversation. Use when a TAO workflow will be run repeatedly, when token cost matters, when the target model has a small context window, or on trigger phrases like "token efficient", "reduce token cost", "card pack", "stage cards", "run this workflow on a small model", "compile this skill into cards".
— the description by NVIDIA Corporation

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The TAO Token-Efficient Execution kit optimizes agentic workflows by replacing long, context-heavy conversations with a series of fresh, stateless headless sessions. By compiling a skill into discrete 'stage cards' using a strong model, the system enables smaller, more cost-effective models to execute complex tasks reliably. State is maintained on disk rather than in chat history, significantly reducing token consumption and context window pressure. The kit includes a bash-based driver for orchestration, harness adapters for tool interception, and a structured contract for state management.

What it does

  • Compiles complex agentic workflows into a series of discrete, stateless stage cards.
  • Executes workflows using fresh agent sessions to minimize context window usage.
  • Maintains persistent state on disk through a defined contract, avoiding reliance on chat history.
  • Uses a bash driver to manage stage routing, job waiting, and error handling.
  • Provides harness adapters to record executed commands and guard against known failure modes.
  • Enables the use of smaller, more efficient models for executing pre-compiled workflows.

When to use it

  • When a specific agentic workflow needs to be run repeatedly.
  • When reducing token costs and context window usage is a priority.
  • When the target model has a limited context window.
  • When you need to ensure deterministic execution of a multi-stage process.
  • When you want to avoid the performance degradation associated with long, single-session conversations.

Advantages

  • Significant reduction in token consumption (measured 67-91% reduction).
  • Lower peak context requirements (3-5x reduction).
  • Improved reliability by using pre-compiled, verified stage cards.
  • Stateless execution prevents model drift and context-related errors.
  • Clear separation between the one-time compilation cost and the efficient execution phase.

Usage examples

“Compile this skill into cards for token-efficient execution.”
The agent reads the skill and workspace, then generates a set of stage cards and a driver configuration to enable stateless, low-token execution.
“Run this workflow on a small model using the card pack.”
The bash driver initiates the workflow, executing one stage card per session and managing state via on-disk contracts.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/tao-token-efficient-execution/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip tao-token-efficient-execution.zip -d .agents/skills

Documentation by NVIDIA Corporation

TAO Token-Efficient Execution

Run a staged TAO workflow as a series of fresh headless agent sessions — one stage card per session — instead of one long conversation. State lives on disk, never in chat history, so no session ever rereads the run's past.

Measured on real workflows (same tasks, same outcomes, billed tokens):

WorkflowOne long conversationCard executionPeak context
DEFT AOI loop9.6M2.5M (-74%)242k → 59k
AutoML (VCN classify)5.8M0.5M (-91%)198k → 42k
HuggingFace finetune1.7M0.5M (-67%)119k → 42k

The mechanism: an agent API is stateless, so a long conversation resends its entire history with every message — by mid-run that is ~100k+ tokens of skill text, spec edits, and training logs reread on every tool call, of which the current step needs ~3k. Cards make each step's 3k explicit and drop the rest.

The three layers

  1. Core (harness-agnostic) — stage cards (markdown, env-var contract), a bash driver (stage routing + job waiting), and on-disk state contracts (references/CONTRACTS.md).

  2. Harness adapters (adapters/) — guard + recorder implemented per harness: hooks for Claude Code, extensions for Pi. Same logic, ~150 lines each. Guards block known dead ends before tokens are burned; the recorder appends executed commands to commands.log so later sessions reuse instead of re-derive.

  3. Card packs (per application skill) — compiled cards living next to the skill they were authored from, e.g. skills/applications/tao-run-deft-aoi/cards/ and skills/applications/tao-run-automl/cards/. Each pack ships its own driver.sh and README.md (version pin, required env, how to run).

Cards shrink the model's job; they don't remove it. The driver owns routing and waiting (deterministic), helper scripts own state commits (deterministic), and the model executes one pre-planned stage: run verbatim commands, read a gate table, decide pass/fail from real output, fill in the one dynamic value. If a stage ever becomes 100% deterministic, graduate it out of the card into the driver or a helper script.

Quick start — run a shipped card pack

# plugin installs export TAO_SKILL_BANK_PATH automatically; standalone users set it first:
export TAO_SKILL_BANK_PATH=/path/to/tao-skill-bank

# one-time: scaffold ~/.tao-kit/kit.env and check harness prerequisites
bash "$TAO_SKILL_BANK_PATH/skills/core/tao-token-efficient-execution/scripts/install.sh"

# edit ~/.tao-kit/kit.env: set WS (and VENV for the AutoML pack) and MODEL;
# export your provider's API key in your shell — never put it in kit.env.
# then launch a pack driver detached (leave stderr attached: config errors print immediately):
nohup bash "$TAO_SKILL_BANK_PATH/skills/applications/tao-run-automl/cards/driver.sh" > /dev/null &

# monitor
tail -f ~/.tao-kit/automl/driver.log

The driver waits while jobs run (activity-based, not process-based), fires one fresh session per stage, halts on committed errors (no auto-retry — an operator decides), and exits 0 only after verified completion. DEFT prepares its inference handoff and passes the completion audit; AutoML requires its DONE marker with no trailing failure. Round-cap exhaustion exits nonzero.

Starting a pack driver is side-effecting work: complete the tao-launch-workflow gate (platform, credentials, image, datasets, launch review) before launching it, exactly as for in-conversation execution. Pi guards are not an OS sandbox: use an isolated trusted worker, not a workstation containing unrelated credentials (see adapters/pi/README.md).

Quick start — author a pack for another workflow

One authoring session with a strong model compiles the skill into cards (measured: ~10 minutes, one-time cost; every later run executes them):

  1. Read references/authoring_prompt.md (the round-0 contract) and references/authoring_prompt_v2.md (rules distilled from measured small-model failures: one command per step, mechanical state gates, exact artifact paths, explicit termination, bounded self-repair).

  2. Fill in run parameters — everything concrete for the target machine. Whatever you leave out, execution sessions will burn tokens rediscovering.

  3. The authoring session reads the skill + inspects the workspace + writes cards into skills/applications/<skill>/cards/. It must NOT run the workflow.

  4. Copy a shipped pack's driver.sh and edit its three config points: the stage→card routing table, the working() predicate, and the paths block. (templates/driver.template.sh is the harness-portable skeleton.)

references/CARD_AUTHORING.md reconstructs a real authoring session play by play.

Model floor (measured, execute-side)

Authoring always needs a strong model. Execution was measured across sizes:

Model classCard executionNotes
Frontier (e.g. Claude)flawlessreference bar: 0 guard fires, clean labels
~400B MoEnear-flawlesscorrect results; a few guard saves
~35B MoEworkflow-dependentAutoML clean end-to-end; DEFT completed but with sloppy stage labels
~30B dense w/o tool disciplinebelow floorfabricated results, loops; guards catch but cannot fix

Raw-skill execution (no cards) did not complete honestly on ANY of the small models measured — aborts, protocol violations, or falsely declared success. Cards are what make small-model execution possible, not a minor optimization.

Report, don't patch: when an execution model fails a card, report it and stop (the driver's no-auto-retry halt enforces this). Never edit cards or state to cover a model's mistakes; only genuine card-authoring defects get fixed, explicitly.

Files

PathWhat
references/CONTRACTS.mdprogress log, STAGE_DONE, commands.log, env contract
references/authoring_prompt.md / _v2.mdcard compilation prompts
references/CARD_AUTHORING.mda real authoring session, annotated
templates/driver.template.shdriver skeleton (three config points)
templates/kit.env.templateper-host config (~/.tao-kit/kit.env)
adapters/pi/, adapters/claude-code/guard + recorder per harness
scripts/install.shprerequisite check + kit.env scaffold
scripts/analyze_usage.pyper-session token accounting from session JSONL
scripts/smoke_test.shno-GPU adapter test (guard, recorder, accounting)

Files

references/CONTRACTS.md

Kit contracts — the on-disk state that replaces chat history

Every contract here exists so a fresh session (or the driver, which is plain bash) can answer "where are we?" without any conversation memory.

Run directory ($RD)

One directory per run, created under $WS/results/. Everything a session learns that later sessions need MUST land in $RD. The driver selects the newest run dir matching the pack's glob that is newer than its launch marker — runs never share state.

Progress marks — how the driver routes

Two equivalent conventions; a pack uses exactly one:

  • Simple packs (progress.log): each completed stage appends one line, <stage> ok (failures append <stage> FAIL). The driver routes on the last ok line only — error lines never advance routing, and a trailing FAIL halts the driver (no auto-retry; an operator decides).

  • Skill-tooling packs (loop_log.jsonl): when the application skill ships its own commit machinery (e.g. DEFT's commit_stage.py, which validates evidence before writing), ALL state writes go through it and the driver routes on the last status=="ok" entry. Cards never hand-roll state writes that the skill's tooling owns.

STAGE_DONE <card-id> — explicit termination

Every card ends with: print exactly STAGE_DONE <card-id> as the final message and stop. Measured failure this prevents: models that cannot end a turn burn hundreds of messages per session. The harness adapter enforces a hard tool-call budget (PI_KIT_TURN_BUDGET) as the backstop.

commands.log — reuse, don't re-derive

The recorder adapter appends every substantive executed command (with a timestamp) to $RD/commands.log. Guard-blocked commands are never recorded. The driver injects the tail into each session's prompt; cards instruct the executor to reuse recorded commands instead of re-deriving them. This is the single biggest defense against small-model drift: the correct command exists, so the model's job is to run it, not to reinvent it.

Environment contract

Cards reference ONLY driver-exported constants ($WS, $RD, $ITER, container images, mount strings, script paths). Two hard rules, both from measured failures:

  • The executor's shell is fresh per tool call — variables set in one call do not survive to the next. Anything that must persist is either a driver export or a file in $RD.

  • Cards never contain <placeholders> the executor must fill by searching. Exact paths, exact flags, one copy-paste command per step.

Per-host values (workspace, venv, model, images) come from ~/.tao-kit/kit.env, sourced by every pack driver. Credentials are never written anywhere — drivers check presence of the API key variable and abort with the export instruction if missing. Pi keeps provider credentials in the harness process but strips them and arbitrary startup hooks from bash tool subprocesses. See the adapter README for the isolated-worker requirement.

Driver obligations

  1. Route on the last committed ok mark (see above), mapping stage → card.

  2. Wait on real activity (container CPU%, runner processes), not on the agent — cards launch long jobs detached and end the turn. Idle zombie containers must not count as work (check CPU, not existence).

  3. Halt on committed errors and on N consecutive no-progress rounds. Check failure status before any completion marker. Never auto-retry a committed failure. Exhausting the round cap must return nonzero; only verified completion returns zero. For DEFT, loop_stop alone is insufficient: the driver must prepare the inference handoff and pass the completion audit.

  4. Snapshot state into the prompt (progress tail, commands.log tail) so the fresh session starts with everything it needs and nothing more.

  5. Write nothing into the skill bank checkout — sessions and driver logs go to ~/.tao-kit/<pack>/.

Guards — block dead ends before tokens burn

Guards are advisory-with-teeth: they block a tool call and return a reason that tells the model WHY and WHAT TO DO INSTEAD. Framework guards (turn budget, near-duplicate-command loop breaker, no-fabricated-results verification, destructive-command safety net) ship in the adapters and are env-configurable. Workflow guards (GPU quirks, disk headroom, container CLI quirks) are added one per discovered failure mode — see the adapters' README for real examples and the pattern to copy.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs an API key, Needs Python, Needs Node.js

The author says: Requires bash, jq, Python 3.10+, and a headless agent harness with tool interception (see adapters/ for supported versions). The shipped card packs additionally need docker and the prerequisites of their application skill.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • References to credential files
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA Corporation
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/tao-token-efficient-execution · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA Corporation or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download tao-token-efficient-execution.zip