AWS published a Grok 4.7 reasoning-effort experiment on October 13. Not a model launch, but a test of how deeply to let the same model think:

Model: Grok 4.7 on Bedrock (500K context)
Tasks: 3 synthetic tasks (fault diagnosis, maintenance schedule, budget)
Levels: low / medium / high / xhigh
Runs: tasks × levels × 6 = 72 runs
Grading: single provable answer + required final line

Results:

Accuracy: xhigh 18/18 > medium, high 17/18 > low 15/18 (67/72 total)
Mean output tokens: low 1,184 → medium 6,430 → high 6,778 → xhigh 9,147
Mean tool calls: flat, 17.2–18.7 across levels
Median time: 18s at low → 106s at xhigh

Deeper thinking scores higher at ~7.7x tokens and ~6x time.

The interesting finding: same tools, more thought

Flat tool calls are the headline:

Same facts gathered (tool calls flat)
More deliberation over them (tokens up 8x)

Extra effort bought reasoning, not exploration. AWS notes the clearest xhigh edge on constraint satisfaction, the scheduling task weighing candidates against each other. Single-path tasks ran fine on low.

Fault diagnosis:   low 5/6, medium 6/6, high 6/6, xhigh 6/6
Maintenance sched: low 5/6, medium 5/6, high 5/6, xhigh 6/6
Budget migration:  low 5/6, medium 6/6, high 6/6, xhigh 6/6

Only the hard weighing needed the top level.

Why this is not a general accuracy gap

AWS's own caveats:

- 6 runs per cell: indicative direction, not statistical proof
- Small synthetic proxy for long-horizon work (18–106s runs)
- Vendor-published experiment, not an independent benchmark

Do not read low's 15/18 as a general score. The transferable value is the method: same job, same harness, repeated runs, graded final lines.

Setup notes: effort goes through the reasoning parameter on the Responses API or additionalModelRequestFields on Converse. The default is high, so unset latency-sensitive calls overspend reasoning tokens by inheritance.

response = client.converse(
    modelId="us.xai.grok-4.7",
    messages=[{"role": "user", "content": [{"text": "question"}]}],
    inferenceConfig={"maxTokens": 3000},
    additionalModelRequestFields={"reasoning_effort": "xhigh"},
)

The practical rule: set effort per request, not per agent

The most portable idea: effort is a request parameter.

Planning and verification → high / xhigh
Result formatting and transforms → low
Answers reviewed downstream → low is efficient
Must be right first time → higher is safer

Plus an operations tip: without ground truth in production, token volume is the signal. Flag runs with far fewer tokens than the level's baseline, or zero tool calls, for review. That is what AWS's example flag_for_review function does.

It pairs with our reasoning high vs max guide: start low, escalate only on verification failure.

CodeBridge mini lab: run your jobs six times each

1. Pick 2 jobs (1 complex plan + 1 simple transform)
2. Run low / high / xhigh × 6 each
3. Record:

   [ ] success rate (fixed criteria, graded final line)
   [ ] mean output tokens (multiplier per level)
   [ ] median elapsed time
   [ ] cost per success
4. Judge by: did xhigh cut failures enough to pay for itself?

Never trust a single run. Repetition is the premise of this experiment.

Conclusion: reasoning budget is a wallet, not a quality slider

Think deeply only on hard trade-offs; run the rest cheap.

High effort for complex planning and verification, low for simple classification and transforms, with the boundary drawn from a table of repeated runs, not gut feel. That is the cheapest lesson here.

Further reading

References

Go deeper with a course

Deciding when to raise effort and when to hand to a human connects directly to per-request selection. Practice wiring classification and priority decisions into code.