Velocity — Token Production Rate

The formula

Velocity is the rate of output token production per unit of session time. It answers a simple question: how many tokens of useful output am I generating per hour? A velocity of 5,000 tokens/hour means you’re producing 5,000 output tokens for every hour of active session time. A velocity of 500 tokens/hour means you’re spending most of your time on input, context management, or waiting — not generating output.

session_time is the wall-clock duration of the active session — from first prompt to last response. It includes the time you spend composing prompts, the time the model spends generating, and the time you spend reviewing output. Velocity captures the full loop, not just model inference speed.

What velocity measures

Velocity measures your throughput — how much output you produce per unit of time invested. It is the AI-coding analog of lines-of-code-per-hour, but measured in output tokens rather than lines. Unlike lines of code, output tokens are a direct measure of the model’s productive work, not your typing speed.

Velocity is influenced by several factors: how quickly you compose prompts (your input velocity), how long the model takes to respond (inference latency), how much output you request per turn (prompt design), and how much time you spend reviewing or editing between turns (your review loop). Improving any of these increases velocity — but not all improvements are equal.

Why velocity is a secondary metric

The fundamental insight: high velocity without yield is fast waste. An operator who generates 10,000 output tokens per hour but sends 50,000 fresh input tokens with no cache reuse has high velocity but low yield. They are burning tokens quickly — efficient at producing volume, inefficient at producing value.

This is why SigRank treats velocity as secondary. Yield is the headline because it measures the architecture of the cascade — whether signal is compounding. Velocity measures the speed of the cascade — how fast tokens flow. Speed without architecture is noise. Architecture without speed is still signal (just slower signal). The priority is architecture first, speed second.

Consider two operators. Operator A produces 3,000 tokens/hour with a yield of 50 (efficient cascade, moderate speed). Operator B produces 8,000 tokens/hour with a yield of 2 (fast cascade, wasteful). Operator A is the better AI coder — their output compounds. Operator B is generating more volume but burning context to do it. Velocity alone would rank B higher; yield correctly ranks A higher.

How velocity interacts with yield

Velocity and yield measure orthogonal dimensions. Yield measures cascade efficiency (output × cache reuse / input²). Velocity measures production rate (output / time). They share the output term but diverge everywhere else.

When velocity matters

Velocity matters most for throughput-oriented tasks where raw output volume per hour is the goal:

• Bulk code generation — generating boilerplate, scaffolding, or repetitive implementations where quality is uniform and volume is the bottleneck.
• Large refactors — applying a consistent transformation across many files or functions.
• Test suite generation — writing comprehensive test cases for an existing module.
• Documentation writing — generating API docs, README files, or inline comments across a codebase.

For precision tasks — debugging a subtle race condition, making an architecture decision, reviewing a security-critical change — yield matters more than velocity. These tasks reward careful, efficient cascades over raw throughput. Use velocity as a diagnostic to understand your working style, not as a target to maximize at the expense of yield.

How to improve velocity without sacrificing yield

• 1. Request larger outputs per turn. Instead of asking for one function at a time, request a complete module or feature. This increases output per turn without increasing input or breaking cache — both yield and velocity go up.
• 2. Reduce review-loop overhead. Time spent reviewing and editing between turns is session_time that doesn’t produce output. Trust the cascade — if your context is stable and your prompts are specific, the output quality is high enough to reduce round-trip edits.
• 3. Batch related requests. Instead of five sequential turns (“write the function,” then “add types,” then “add tests,” then “add docs,” then “add error handling”), batch them into one turn: “write the function with types, tests, docs, and error handling.” One turn, large output, same cached context.
• 4. Maintain cache continuity. Cache reads are faster than fresh input processing — high cache hit rate reduces model latency, which increases velocity. Context discipline improves both yield and velocity simultaneously.

FAQ

What is velocity in AI coding?

Velocity = output / session_time. It measures how many output tokens you produce per unit of session time. High velocity means you’re generating output quickly; low velocity means you’re spending time on input and context management without proportional output.

Why is velocity a secondary metric?

High velocity without yield is fast waste. An operator generating 10,000 tokens/hour with no cache reuse has high velocity but low yield — they are burning tokens quickly. Yield measures efficiency; velocity measures speed. Speed without efficiency is just faster waste. Yield is the headline; velocity is context.

How does velocity interact with yield?

They measure orthogonal dimensions. You can have high yield and low velocity (efficient but deliberate — precision work) or high velocity and low yield (fast but wasteful — volume without context discipline). The best operators have both: efficient cascades that also produce a lot of output quickly.

When does velocity matter?

Velocity matters most for throughput-oriented tasks: bulk code generation, large refactors, test suite generation, documentation writing. For precision tasks — debugging, architecture, security review — yield matters more. Use velocity as a diagnostic, not a target.