Verifiedon 2026.7.1
Action boundary
Before you act
- Expected result
- A run ledger distinguishes request arrival, queue wait, processing, first useful output, completion, errors, and concurrent load.
- Failure mode
- An average time from a quiet single request is presented as the service experience under real workload conditions.
- Rollback
- Keep the capacity assumption out of the decision record and route only the bounded load already proven.
Performance has stages
For an operator, “it took six seconds” is an unhelpful sentence. Record when work arrived, when it began processing, when the first useful output became available, when it completed, and whether it was queued, retried, or cancelled. Pair the timing with input size, output size, concurrency, and the quality score from the same fixture.
Context is a trade-off, not a trophy
More supplied context can improve grounding or preserve constraints; it can also change resource use, queueing, latency, and failure behavior. Test representative short and long inputs. Do not infer maximum usable context from a marketing limit or one successful run. Your workload has its own threshold.
Lab: load steps, not a hero run
Choose a load ladder that starts at one and steps toward the intended concurrency. Hold each step long enough to observe queueing and failures. Stop at the first pre-declared guardrail breach: unacceptable tail latency, quality decline, errors, resource exhaustion, or an operator safety limit.
Record percentiles or another agreed tail measure rather than only the mean. If the system is interactive, the slowest few users matter.
Learner artifact — annotated run ledger: Make a table or chart with a visible test date, fixture set version, concurrency step, completion count, error count, median and tail time, and quality score. Redact any request bodies, user IDs, endpoints, and credentials. Its alt text should name the trend and the stop point.
Checkpoint
A route is quick at concurrency one but its longest responses breach the agreed limit at concurrency four. What belongs in the decision record?
The observed boundary: fixture pack, environment, load steps, the tail result, and the rule that was breached. “Fast” is not the result; the safe operating envelope is.
Evidence note
This lesson provides a measurement method only. It does not claim a particular GPU, provider, model, or OpenClaw runtime will achieve a given throughput.
Source provenanceVerification and sources
Review receipt rr_local_models_context_performance_fixture
- Outcome
- approved
- Method
- source-review
- Reviewer
- academy-specification-review
- Reviewed
Evidence
- academy-spec — curriculum-local-models-contract; snapshot
1c60fa76ac90…
Limitations
- Approval covers the original workload, benchmark, routing, quota, and fallback method for 2026.7.1; it makes no universal provider, model, GPU, performance, privacy, or savings claim.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.