Token efficiency — verified source and operating rules

Token efficiency — verified source and operating rules

North star: Every JBNX task finishes verified at the lowest token cost, with both efficiency and effectiveness measured and nothing faked. Hard gates (never bend): required verification never waived; no invented percentages or usage numbers; no secrets or auth tokens read or copied; no billing, overage or reset changes; owner stop overrides; authorized work not abandoned to hit a budget Everything else is a default. Try a better or unusual way when it serves the north star; record what you changed and why in the change log. Change log: bottom of this page (who, when, why).

Mandatory every task — owner order, 2026-09-18

The mandatory operating checklist is https://hi.jbnx.io/core. It includes the efficiency rules below. Load this framework only when the task needs detailed measurement or source analysis; do not load both documents on every task. Reuse the version already read. Only the bullets in this section are the every-task rules; everything below is reference.

• Default: load and use the Caveman skill, full intensity (use a lighter style when it serves clarity and log why). Missing skill: report once and apply hi R18 fallback. Short, factual replies and worker prompts; final normally ≤80 words. No filler, restating, tool narration or raw dumps. Use normal prose where clarity, code, customer copy or required warnings demand it.
• 10,000-token soft budget per bounded task: target 5,000 for routine changes; at 8,000, stop optional research and focus on finishing/verification; at 10,000, checkpoint and document why more tokens are necessary. Count parent + all workers, input/output, tool context and exposed reasoning. New workers, retries or splitting the same task do not reset its budget. Track unavoidable startup context separately and include it in total usage; never relabel task context as startup overhead. Checkpointing is not an approval gate: continue authorized work and required checks, recording overruns. Under 1% remains a secondary goal only with a known allowance/period; otherwise record 1% unmeasurable. Never invent percentages. A technical hard cap requires runtime token tracking; this webpage supplies policy, not runtime enforcement.
• Default: call a cheaper capable worker for executable work. One bounded deliverable with exact paths, constraints, checks and a short output cap. Parent directs, reviews, integrates and verifies. Use only needed context. Default: add workers only for independent work with expected savings; use another split when it clearly cuts total tokens and log why. No duplicate edits, claims, billing or verification.
• If cheaper delegation is unavailable, platform-restricted, or there is no executable subtask, record the actual exception. Never claim a cheaper model or delegation without evidence. Cost unknown means unknown.
• Resolve conflicts once: name the rule/capability, fix editable task-related guidance, respect platform rules and continue permitted work. Missing telemetry cannot establish quota compliance. This page cannot enforce another provider's behavior.
• Cut optional exploration near budget, never required implementation or verification. Record overrun reason; do not abandon authorized work to hit a number. Load narrow context, reuse known facts, batch independent reads and keep outputs small.
• Report result, proof, remaining blocker and one compact usage line. Keep detailed diagnostics private; show exact error code and decisive lines only. Do not repeat required notices unnecessarily.

Dual scorecard (measure both every substantial run)

Axis	What to record	Pass
Efficiency	input+output tokens (workers included), soft budget, waste class (filler / rediscovery / dump / verify-loop)	Under soft budget or waste class named + cut next run
Effectiveness	acceptance checks, live verify if shipping, no fake-done, required evidence kept	Same checks would still pass after the cut

Two different 10s: 10,000 task tokens = checkpoint, record the overrun, keep going. 10% of the native subscription allowance = wind-down below, stop execution. Never mix them.

Usage line format (example only, fill from real telemetry): usage: <in>+<out> tok incl. workers; budget 5k; waste: none|<class>; worker: <cheaper model>|exception: <reason>.

Improve both. A cheaper run that drops verify is a fail. Never add prose to “fix” an in:out ratio.

Comparable tasks only. Mark estimates. Percentages need denominator + baseline.

All eleven rules and adoption decisions

Rule	Time (source transcript position)	JBNX application
1. Task budget	1:45	5,000 routine target; 8,000 stop optional research; 10,000 checkpoint with overrun reason. One cumulative task budget across workers/retries. Startup overhead separate and included in total. Required checks continue.
2. Narrow delegation	3:36	One cheaper capable worker for executable work; parent directs and reviews. Count worker tokens; record capability exceptions. Extra workers only for independent work with expected savings.
3. Morning ping	4:57	Not adopted.
4. Reusable workflows	5:17	Skills/scripts for repeated mechanics; do not paste process into every prompt.
5. Persistent preferences	6:15	Keep always-loaded files short; link canonical detail (hi + this page).
6. Mid-run correction	7:41	Apply steering immediately; stop obsolete approaches.
7. Tool scope	8:12	Discover only needed tools; load instructions on demand.
8. Compact tool results	9:42	Success = short + pointers; retain full failure evidence privately; show decisive lines and error code. Never suppress fail codes.
9. Short responses	11:03	Caveman by default (see above; lighter style allowed when it serves clarity, log why).
10. Exact starting point	12:04	Estate map / brief / known IDs first; record paths.
11. Resumable progress	12:43	Checkpoint done/files/checks/fails/next so the next run pays nothing to rediscover.

Daily Efficient loop

EFFICIENT (or any auditor) weekday/daily: sample recent agent chat + portal usage; score both axes; ship one durable cut to this page and/or hi when a pattern repeats; stay quiet if nothing changed.

Work contract

Every task: scope, known paths, done criteria, budget/denominator, Caveman skill, directive version, cheaper worker or named capability exception. Keep this in task records; do not narrate the checklist.

Repeatability > claimed savings. Record before/after evidence before claiming improvement.

Validated 2026-09-16 against Dubibubi transcript (corrections retained). Creator pricing claims remain unverified — use live telemetry.

Completion evidence

The Projects receipt records directive version, result, actual verification, usage, worker or capability exception, and blockers. Missing verification means incomplete. The hi checklist stays within 600 words and the repository pointer within 120 words, checked in CI. These document checks do not control external agents or enforce a provider token cap.

Wind-down and multi-AI takeover

Owner rule added October 27, 2026. This extends rule 11; use the existing Projects task, document and release IDs. It is a procedure, not an installed monitor or permission to buy usage.

Trigger and budget evidence

Enter wind-down when a trustworthy current reading shows 10% or less of the applicable native subscription allowance remaining, or immediately when the owner asks to stop. The owner may set a stricter threshold. This allowance threshold is separate from the cumulative task-token soft budget above. Required checks remain required; pausing leaves them pending, never waived.

Record the provider/account scope without secrets, allowance and period, remaining amount/percentage, source, observation time and reset time if exposed. Distinguish native account allowance from task input/output estimates, context capacity, rate limits and another service's usage. Do not infer a percentage from task tokens. A reset being available is not a reset applied.

If native telemetry is unavailable, record remaining_allowance: unknown, source and time. Do not call it zero or sufficient, manufacture a token-health band, or claim an automatic 10% cutoff. Use native telemetry if actually available; otherwise use bounded checkpoints and an owner update. A confirmed owner statement that the reset was applied may establish resumption without an unavailable meter; record it as owner-reported. Never scrape private session files, copy authentication tokens, consume a reset, change billing, add overages or install a polling service to obtain a number.

Wind-down sequence

1. Freeze intake. The lead stops assigning new work, feature edits, tests, CI, deployments and paid generation. Send the stop instruction to every known worker. Owner stop overrides a plan to finish a test suite or task. Continue only bounded handoff work and the minimum reconciliation needed to establish the outcome of an already-issued consequential operation.
2. Reconcile in-flight operations. Record local process IDs, worker/session IDs, CI runs, deployments, migrations and external requests. Cancel only owned work that can safely stop. A stop request is not proof of cancellation. For a side effect with an uncertain response, check its real outcome before retrying or handing it to another writer. Preserve an explicit unknown if it cannot be settled. Do not kill another actor's processes or roll back an operation merely to simplify the report.
3. Preserve the exact work. Record repository/worktree, branch, base and HEAD, dirty/untracked paths, PR and exact remote head. Retain unfinished edits and necessary private artifacts; do not reset, delete, stash over or force-push shared work. Commit only an authorized, understood set when safe; otherwise leave the dirty tree intact and describe it. Keep secrets and customer content out of patches, public documents and logs.
4. Checkpoint canonically. Update the current Projects task/document, board and handoff, using expected versions and stable request IDs. Separate prepared, committed, reviewed, tested, merged, deployed and live-verified states. Preserve failed/cancelled/partial checks and their exact head, environment, evidence path or URL, plus reproduction and next commands. A worker report is an assertion until the lead verifies it. Keep task progress, worker liveness, release bookkeeping and service health distinct.
5. Verify reporting. Retain write receipts and read back the expected record/version/body. Failed reports stay in a private durable outbox with the same logical request ID and exact payload; reconcile uncertain receipts before retry. A stale version requires a fresh read and new reconciled update, not overwriting another AI. Reporting remains available during an execution pause through the authorized R20/R21 path; do not broaden access, create credentials or replace global policy with project-scoped reporting credentials.
6. Release ownership safely. Record usage once from its real source, marking estimates. Release only your leases and local locks after protected operations have settled, or explicitly record the unresolved operation and existing owner/fence so another writer cannot start. Preserve scoped ownership and exclusions; lease expiry alone is not proof that an unmanaged process stopped. Record each worker's acknowledgement or unverified; never announce that all projects or agents stopped without evidence.
7. Pause explicitly. Publish the next safe action, blockers, permission and activation gates, rollback limits, and resume condition. State whether a controller/monitor exists and what it can observe. Stop execution; do not create a timer that silently resumes work.

Minimum checkpoint

Use one concise canonical checkpoint with links to detailed evidence. Omit credential values and unnecessary personal data.

Project/task/document IDs; requirement revision; hi policy version:
Lead/worker/session; scope and exclusions:
Budget source, observed_at, allowance period, remaining, reset_at, trigger:
Repository/worktree/branch; base; HEAD; dirty/untracked paths; PR/remote head:
Completed and verified; prepared or unverified; failed/cancelled/partial checks:
In-flight side effects and exact outcome/unknown; owned process/job IDs:
Evidence bound to commit/artifact and environment:
Blockers; retained approvals/activation/privacy/security/legal gates:
Leases/locks/fences and worker acknowledgements; usage source/receipt:
Projects write/readback receipts; failed-report outbox path and request IDs:
Next exact commands and expected result; rollback limits:
Resume condition; telemetry/automation limits:

A checkpoint should let another AI resume without replaying completed releases, hiding failures or discovering the same source again. Cross-project coordination notes state the owner's request and only verified local/project facts; unrelated project states remain unverified.

Resume acceptance and independent verification

The incoming lead first reads the canonical checkpoint, current compact brief, requirement/policy revision and repository instructions. Confirm owner intent permits resumption and the reset/budget evidence is adequate. Retain unknown for unavailable telemetry; an explicit owner-confirmed reset is acceptable evidence of reset, not a measured remaining percentage.

Inspect current main, remote head, dirty work and actual external state. Resolve uncertain side effects before any retry. Verify previous ownership is released or fenced; acquire the correct scoped lease and an isolated worktree/lock before writing. Never let two AIs write the same scope under a shared handle.

Accept a bounded next task with paths, done criteria, remaining checks and preserved permissions. Reconcile changed main or requirements; repeat checks only when changes, failures or unresolved concerns justify them. Required final CI/live verification must cover the actual final artifact. Recheck the allowance at natural checkpoints when native telemetry exists, and wind down again at 10% or an owner stop.

The lead independently verifies worker output, exact artifact and applicable live behavior before declaring completion. A reset, clean tree, successful handoff write or draft PR is not a deployed result. Record acceptance and the next checkpoint on the same Projects records.

Change log

Every change to this framework: who, when, why. Source: agent_ops.catalog_changelog.

When (UTC)	Who	Version	What	Why
2026-11-12 10:36	1099:claude-chat-c1d3	v9	Rule 9 row now matches the every-task default	Rule 9 still said Caveman mandatory after v8 made it a default; readers got two answers.
2026-11-08 16:18	1099:claude-chat-c1d3	v8	Token efficiency — verified source and operating rules	Owner-requested north-star review 2026-11-08: north star + hard gates header, top fixes, non-safety rules loosened to defaults (details in the page change log)
2026-10-27 11:31	1099:openai-codex-7f4c	v7	Token efficiency — verified source and operating rules	not recorded (before change log started 2026-11-08)
2026-09-18 19:10	1099:openai-work-2623	v6	Token efficiency — verified source and operating rules	not recorded (before change log started 2026-11-08)
2026-09-18 09:16	1099:openai-work-1f5b	v5	Token efficiency — verified source and operating rules	not recorded (before change log started 2026-11-08)
2026-09-18 08:47	1099:openai-work-1f5b	v4	Token efficiency — verified source and operating rules	not recorded (before change log started 2026-11-08)
2026-09-17 23:27	1099:cursor-efficient-a1b2	v3	Token efficiency — verified source and operating rules	not recorded (before change log started 2026-11-08)
2026-09-17 13:46	1099:codex-work-7fb3	v2	Token efficiency — validated rules and operating contract	not recorded (before change log started 2026-11-08)
2026-09-16 21:52	1099:codex-work-06ad	v1	Token efficiency — validated rules and operating contract	not recorded (before change log started 2026-11-08)