Tests whether the candidate estimates before sending. Strong answers use a rule of thumb and name its limits.
A common approach to tokenization is subword units. For English prose a rough rule is about 3 to 4 characters per token with common tokenizers, stated as approximate and tokenizer-dependent.
example document: 12000 characters of English prose
rule of thumb (approximate, tokenizer-dependent): about 4 characters per token
estimate = 12000 / 4 = 3000 tokens (planning range about 3000 to 4000)
same characters as hex at about 2 characters per token: 12000 / 2 = 6000 tokensCode, numbers, hex and non-Latin text carry fewer characters per token. The only exact count comes from the tokenizer that will process the input.
def estimate_tokens(chars, chars_per_token):
return chars / chars_per_token
def fits(tokens, budget):
return tokens <= budget
bad = []
if estimate_tokens(12000, 4) != 3000.0:
bad.append("prose estimate should be 3000")
if estimate_tokens(12000, 3) != 4000.0:
bad.append("dense estimate should be 4000")
if not fits(3000.0, 8000):
bad.append("3000 should fit budget 8000")
if fits(9000.0, 8000):
bad.append("9000 should exceed budget 8000")
if bad:
print("FAIL: " + "; ".join(bad))
raise SystemExit(1)
print("PASS: 12000 chars estimate 3000 to 4000 tokens, budget check holds")The program above is a plain estimator, not a real tokenizer. It proves the planning arithmetic used in the model answers.
Tests understanding of attention cost and long-context reliability. Strong answers separate cost from quality.
In the basic form, attention cost grows with the square of the sequence length. Efficient variants exist, so this is a statement about the basic form only.
basic attention cost grows with the square of the sequence length (efficient variants exist)
length 4000: proportional to 4000^2 = 16000000
length 8000: proportional to 8000^2 = 64000000 = 4 x 16000000
doubling the length quadruples the pairwise costLong-context use is less reliable than short-context use. Models tend to use information at the start and end of long inputs better than the middle, a tendency reported in studies, not a law.
Tests judgment about truncation and summarization. Strong answers keep the task, the constraints and the freshest evidence.
Summarize stale history into decisions and keep raw text for disputed facts. Anything that differs between models or tools must be said to vary, so measure the short version against the long one.
Keep raw | Summarize or drop | Why |
|---|---|---|
The task statement and constraints | Old tool chatter | The task defines correctness; chatter does not. |
Disputed log lines | Settled earlier turns | Raw lines settle arguments; summaries can blur them. |
The current failing case | Passed cases from hours ago | The failing case drives the next step. |
About 3000 tokens at 4 characters per token, planning range 3000 to 4000. The rate is approximate and tokenizer-dependent.
Long inputs are used less reliably, and middle placement is weakest as a reported tendency. Place key facts at the start or end and verify they were used.