Research Questions: What We Need to Answer About AI Workflows

Open questions · evidence-led · last updated 3 October 2026

LAST UPDATED (all 20 question cards): 3 October 2026. A source-specific timestamp is shown separately when a finding has one.

Last updated for the question cards below: 3 October 2026, unless an entry names a source-specific timestamp.

These are practical AI-workflow questions Token Optimisation is actively trying to answer. Open questions stay open: evidence, limitations, experiment design and contribution status are shown separately. A snapshot from one PC must not become a universal concurrency rule.

OBSERVED ON ONE MACHINE · ONE WORKLOAD

12 concurrent GPT-6 Luna Low sessions: supplied snapshot

The ranges below are owner-provided observations. The raw screenshot/log, sampling cadence, session start/end and software-version join are not attached to this finding; this is not a controlled concurrency ceiling or multi-machine benchmark.

~39–71%CPU use, observed range

25.6–26.0 / 31.8 GBRAM used / total, as supplied

~5.8–6.1 GBFree RAM, as supplied

~10% · negligibleGPU use · disk activity

Observation label: one desktop and one 12-session workload. Exact run timing and hardware-to-sample record binding remain to be attached. Open the visual version.

Machine context checked separately: Intel Core i5-14400F (10 cores/16 logical), 31.78 GiB physical RAM, AMD Radeon RX 9060 XT, Windows 11 Home build 26200, OpenCode 1.18.31. The inventory is a separate local read; the 12-session range summary is not yet bound to a timestamped raw capture from that inventory. Interpretation supplied with the observation: RAM appears to be the first local constraint; CPU has headroom; the GPU is not the compute bottleneck for cloud Luna inference. This is a hypothesis from one workload, not a universal conclusion.

Questions we are testing

1. How many concurrent Luna/OpenCode lanes can one desktop PC realistically support?

Why it matters: Capacity planning should use verified results and failure rates, not open-session count.
Current evidence: Owner-provided 12-lane Luna Low snapshot above; one machine/workload only.
What we know: CPU ~39–71%, RAM ~25.6–26.0/31.8 GB, free ~5.8–6.1 GB, GPU ~10%, disk negligible.
What we do not know: Ceiling, success rate, actual task concurrency, quality or effects on verified output/hour.
Experiment needed: Staged 5→8→12→16→20→24 lane sweep with stable workloads and a stop condition.
Data required: Model/version, lane count, CPU/RAM/GPU/disk samples, starts/ends, failures/retries and verifier-passed jobs.
Status: 12-lane observation recorded; concurrency ceiling OPEN.
Last updated: 3 October 2026.
Related article/tool/infographic: 12-session observation · infographic · operating rules.

2. Is RAM the primary local bottleneck for cloud-AI concurrency?

Why it matters: It may guide a hardware purchase and safe scheduling limits.
Current evidence: The single 12-lane snapshot shows limited free RAM and lower CPU/GPU readings; owner interpretation only.
What we know: At that observation, RAM was ~25.6–26.0 GB used and CPU ~39–71%.
What we do not know: Causality, saturation, paging latency, or which process/lane owns the memory.
Experiment needed: Collect idle baseline, per-stage samples and matched lane-count intervals; separate commit charge, resident memory and available physical RAM.
Data required: Synchronized RAM/commit/pagefile/CPU, per-lane process working set and task acceptance.
Status: Initial observation suggests RAM may bind first; causal test OPEN.
Last updated: 3 October 2026
Related article/tool/infographic: context budget method · context rules · snapshot visual.

3. Could this current CPU support 24 concurrent Luna Low lanes with 64 GB RAM?

Why it matters: It separates memory-upgrade capacity from CPU/scheduler limits.
Current evidence: System inventory identifies an Intel Core i5-14400F; no 24-lane or 64-GB run is recorded.
What we know: 10 physical cores/16 logical processors on the current system inventory; the 12-lane sample is separate and unbound to a raw system capture.
What we do not know: Whether 24 lanes remain useful, stable, quality-verified or limited by CPU, RAM, Bridge, provider allowance or tool contention.
Experiment needed: Test on the same CPU with 32/64 GB memory under matched task fixtures; never extrapolate from a single snapshot.
Data required: Installed/available memory, CPU frequency/utilization, per-lane resource distribution, retries, crashes and verified outputs.
Status: NOT TESTED; no capacity claim.
Last updated: 3 October 2026
Related article/tool/infographic: hardware/economics method · safe recovery rules · current observation visual.

4. How much RAM does each additional OpenCode lane really add?

Why it matters: Incremental memory cost informs a capacity model.
Current evidence: No matched before/after lane memory sample is attached.
What we know: Only the one 12-lane aggregate range above.
What we do not know: Per-lane working set, shared browser/tool process overhead and background cache.
Experiment needed: Measure idle, one-lane, and staged lane additions with the same task and fixed sampling interval.
Data required: Process-to-lane joins, working sets, shared processes, pagefile/commit, start/end and accepted outputs.
Status: NOT MEASURED.
Last updated: 3 October 2026
Related article/tool/infographic: measurement boundary · agent safeguards · snapshot visual.

5. How linear is OpenCode memory growth as lane count increases?

Why it matters: Nonlinear growth can make a simple per-lane estimate unsafe.
Current evidence: No time-aligned multi-level lane sweep has been reconciled.
What we know: One 12-lane owner-supplied reading does not establish a curve.
What we do not know: Idle baseline, caching, tool/browser fan-out or nonlinear scheduler costs.
Experiment needed: Repeat randomized lane-count blocks and plot ranges, not a smoothed causal curve.
Data required: Same model/task/software, RAM samples, concurrency, warm/cold state, failures and verifier outcomes.
Status: OPEN; no linearity claim.
Last updated: 3 October 2026
Related article/tool/infographic: break-even variables · cost scenarios · current snapshot.

6. At what concurrency level does CPU become the bottleneck instead of RAM?

Why it matters: The first binding resource can change with lane and tool mix.
Current evidence: One user-supplied 12-lane range showed CPU ~39–71%; no saturation sample or queue attribution.
What we know: CPU had apparent headroom in that reported window, not necessarily at peak bursts.
What we do not know: Scheduler contention, per-core saturation, throttling, or concurrency threshold.
Experiment needed: Increase lanes gradually with tool-heavy and model-wait workloads isolated; stop on predeclared pressure criteria.
Data required: Per-core CPU, frequency/thermal events, run queue, lane phases, RAM/commit, output quality.
Status: NOT TESTED.
Last updated: 3 October 2026
Related article/tool/infographic: acceptance signals · bounded recovery · snapshot visual.

7. Does Luna Low, Medium or High materially change local CPU/RAM consumption?

Why it matters: Reasoning tier may affect local orchestration as well as remote usage.
Current evidence: The 12-session reading is Luna Low only; historical model/session aggregates do not join to contemporaneous resource samples.
What we know: No matched tier comparison.
What we do not know: Whether tier changes local process memory, tool calls, wait time or only remote provider behavior.
Experiment needed: Same task, concurrency, context and software, with tier as the single independent variable.
Data required: Per-lane process resources, provider request counts, model usage, tool calls and verified outcomes.
Status: NOT TESTED.
Last updated: 3 October 2026
Related article/tool/infographic: routing method · cost scenario tool · infographics.

8. Does reasoning tier affect process size, tool-call count or browser/terminal overhead?

Why it matters: Different local overhead can change useful concurrency even if inference is cloud-hosted.
Current evidence: No matched per-tier process/tool measurement.
What we know: Session aggregates by variant exist, but they are not concurrency or per-job runtime evidence.
What we do not know: Which added memory or I/O is caused by tier vs task/context/browser state.
Experiment needed: Pair identical tasks at each tier, record local process tree/resource samples and verified tool events.
Data required: Version, tier, tool-call count, per-process memory, browser/terminal baseline and output acceptance.
Status: NOT TESTED.
Last updated: 3 October 2026
Related article/tool/infographic: request measurement · agent rules · infographics.

9. How much GPU usage comes from Windows Terminal/browser rendering rather than inference?

Why it matters: A utilization number needs process/engine attribution before it can diagnose an inference bottleneck.
Current evidence: GPU was reported around 10% in the 12-lane cloud Luna snapshot; it does not identify the process or GPU engine.
What we know: Cloud Luna inference is remote; local graphics/rendering can still use GPU, but the reported share is not attributed.
What we do not know: Terminal/browser rendering contribution, exact sampling method and VRAM use during the observation.
Experiment needed: Compare idle desktop, browser/terminal-only and cloud-session phases with per-process engine counters.
Data required: GPU engine/process samples, screen/session state and synchronized timeline.
Status: OBSERVED UTILIZATION ONLY; attribution OPEN.
Last updated: 3 October 2026
Related article/tool/infographic: local/cloud factors · single-workload chart · visual index.

10. What is the real concurrency ceiling before Bridge/scheduler contention?

Why it matters: Local CPU/RAM headroom may not be the next limit.
Current evidence: No matched Bridge queue, worker-slot or scheduler contention study is bound to the 12-lane observation.
What we know: The system’s configured concurrency and the actually overlapping active jobs are different counts.
What we do not know: Queue latency, lock contention, rejected work, callback receipts or scheduler CPU.
Experiment needed: Stage load on the existing Bridge/scheduler only with explicit owner authorization and read-only observers.
Data required: Enqueue/start/end timestamps, attempts, lock/queue wait, callback acknowledgements and verifier outcome.
Status: NOT TESTED; no worker changes from this page.
Last updated: 3 October 2026
Related article/tool/infographic: acceptance method · checkpoint/fence rules · visual index.

11. Does 5 → 8 → 12 → 16 → 20 → 24 lanes improve verified output faster than allowance burn?

Why it matters: Throughput is useful only when tied to accepted results and comparable resource usage.
Current evidence: One 12-session resource snapshot; no matched output/allowance sweep across lane counts.
What we know: The Pro 100 weekly allowance percent/reset is not exposed by approved machine sources.
What we do not know: Whether extra lanes increase accepted output, retries, latency or allowance burn.
Experiment needed: Pre-register the lane steps, job fixtures, quality rubric, safety limits and workload window.
Data required: Verified outputs, provider usage, allowance snapshots, waits, retries and human minutes per step.
Status: NO COMPARABLE LANE-SWEEP DATA.
Last updated: 3 October 2026
Related article/tool/infographic: verified-job economics · cost calculator · visual index.

12. At what concurrency does more parallelism reduce output per token?

Why it matters: More simultaneous work can create retries, context repetition or review overhead.
Current evidence: No matched output/token results across lane counts.
What we know: Token counts need an accepted-output denominator; one request count is not enough.
What we do not know: Any saturation point or marginal cost at higher concurrency.
Experiment needed: Compare the same task set and verifier across lane steps, including failed/retried calls.
Data required: Input/cache/output tokens, retries, verified outputs, active hours and resource usage.
Status: OPEN QUESTION; no optimum inferred.
Last updated: 3 October 2026
Related article/tool/infographic: calculated scenario limits · calculator · visual index.

13. Can verified daily output double without doubling Pro 100 allowance consumption?

Why it matters: Value requires accepted work and allowance consumption over aligned periods.
Current evidence: £89 charge user-recorded; billing period/account-wide usage and verified output are incomplete. Latest public status checked 3 October 2026: account-wide allowance use, a matched lane sweep, and a complete verified-job denominator remain UNKNOWN; no productivity or allowance-efficiency conclusion is published.
What we know: One scoped local Bridge snapshot had zero usage/verified-output rows; other clients are outside its scope.
What we do not know: Allowance percentage/reset, whole-account usage, baseline output and human time.
Experiment needed: Instrument complete matched days with an approved account-usage source and an acceptance ledger.
Data required: Allowance snapshots, verified jobs, output quality, tokens, failures/recovery and staff minutes.
Status: IN PROGRESS; no productivity verdict.
Last updated: 3 October 2026
Related article/tool/infographic: method article · measured subscription mode · visual index.

14. How much RAM is fixed Windows/browser overhead versus per-lane overhead?

Why it matters: The fixed baseline and incremental lane cost lead to different upgrade and scheduling choices.
Current evidence: Only aggregate used/free ranges were supplied for the 12-session workload.
What we know: The current machine inventory was checked separately; it is not bound to the sample’s timestamp.
What we do not know: Idle baseline, per-process working set, shared browser/terminal cost and memory slope.
Experiment needed: Capture idle, browser-only, one lane and staged lane counts with stable windows.
Data required: Process-to-lane mapping, working set, available RAM, commit, pagefile and workload phase.
Status: NOT ISOLATED.
Last updated: 3 October 2026
Related article/tool/infographic: capacity economics · safe checkpoints · observed ranges.

15. How much capacity would 64 GB RAM unlock on this same CPU?

Why it matters: A memory upgrade might help only until another limit binds.
Current evidence: Current RAM inventory and a 12-lane usage range; no 64-GB configuration has been measured.
What we know: Current CPU inventory is i5-14400F (10 cores/16 logical); no capacity claim follows from this alone.
What we do not know: Whether 64 GB permits more useful accepted jobs or simply shifts the limit to CPU/scheduler/provider.
Experiment needed: Same CPU, workload, software and verifier, comparing memory capacity only after a safe baseline.
Data required: Matched per-lane resource, failures, costs, throughput and independent verifier results.
Status: NOT TESTED; do not buy hardware from this observation alone.
Last updated: 3 October 2026
Related article/tool/infographic: break-even framework · cost inputs · visual index.

16. Would 96 GB or 128 GB create useful capacity or move the bottleneck?

Why it matters: More memory has cost and platform constraints; theoretical concurrency is not useful throughput.
Current evidence: No 96/128-GB run or matched throughput data.
What we know: Capacity must be evaluated with the same CPU, workload and acceptance test.
What we do not know: Motherboard/support compatibility, effect on concurrency, economics and verifier-passed output/hour.
Experiment needed: Check hardware compatibility first, then staged controlled measurements.
Data required: Board/memory configuration, memory pressure, CPU/scheduler metrics, cost and accepted work.
Status: NOT TESTED.
Last updated: 3 October 2026
Related article/tool/infographic: total cost boundary · visual index.

17. What happens to latency when every lane becomes tool-heavy simultaneously?

Why it matters: Tool calls can load CPU, browser, storage, scheduler and external services differently from model waits.
Current evidence: The supplied 12-lane finding does not separate tool-heavy phases or provide latency percentiles.
What we know: No tool-heavy concurrency comparison is currently bound.
What we do not know: Queueing, tail latency, timeouts, contention and accepted task outcomes.
Experiment needed: Use the same benign tool workload in staged concurrency, with bounded duration and stop thresholds.
Data required: Tool call intervals, queue time, retries, CPU/memory, errors and verifier acceptance.
Status: NOT TESTED.
Last updated: 3 October 2026
Related article/tool/infographic: acceptance signals · tool/recovery rules · visual index.

18. How does context size affect local OpenCode memory?

Why it matters: Context length could correlate with local serialization, caching or editor state, but the mechanism must be measured.
Current evidence: No controlled context-size versus local-memory dataset is bound to this lane.
What we know: Provider token usage and local process memory are different measures.
What we do not know: Incremental memory caused by context size after holding tools, history and lane count constant.
Experiment needed: Vary one context component or size under fixed software/model conditions and repeat.
Data required: Request tokens, process working set, history size, tool schemas, runtime and acceptance.
Status: NOT MEASURED.
Last updated: 3 October 2026
Related article/tool/infographic: request boundary · context cost · visual index.

19. Does cached-input share correlate with better allowance efficiency?

Why it matters: Cache billing and allowance accounting may differ, but a correlation needs aligned authoritative usage.
Current evidence: One bounded canary had zero cached input; historical session aggregates are separate and lack job/allowance joins.
What we know: Provider cache fields must be reported separately; weekly allowance percent/reset is not exposed by the approved machine source.
What we do not know: Any relationship to Pro100 allowance burn or verified output.
Experiment needed: Paired workloads with cache eligibility, provider usage and authoritative quota snapshots.
Data required: Input/cache/output per request, allowance deltas, aligned timestamps and accepted outcomes.
Status: NO CORRELATION CLAIM; quota source unavailable.
Last updated: 3 October 2026
Related article/tool/infographic: cache fields · API scenarios · visual index.

20. When is local Qwen more efficient than adding another cloud Luna lane?

Why it matters: Route choice should include quality, hardware, power, model runtime, cloud usage and human review.
Current evidence: No matched Qwen-vs-Luna accepted-work comparison is available for this 12-lane observation.
What we know: A local/cloud break-even method exists; example values are illustrative, not production results.
What we do not know: Equivalent task quality, real local energy use, cloud allowance impact or verified output rates.
Experiment needed: Paired same-task tests with a common verifier, comparable windows and complete costs.
Data required: Model/version, local wattage, API usage, runtime, retries, failures, review time and accepted output.
Status: NOT TESTED; no route recommendation.
Last updated: 3 October 2026
Related article/tool/infographic: break-even method · quality-gated routing · visual index.

Community evidence contributions

We welcome reproducible, high-level measurements. Submissions are not automatically trusted or published. Records begin as UNVERIFIED COMMUNITY DATA; only independently reproducible or source-supported records may be promoted to VERIFIED. Do not send credentials, prompts, private chat, account/session identifiers, private paths or customer records.

Contribution format

evidence_label: UNVERIFIED COMMUNITY DATA
CPU model / cores: ...
RAM installed (GB): ...
GPU model / VRAM: ...
OS / build: ...
OpenCode version: ...
Model / provider / reasoning tier: ...
Concurrent lanes: ...
Workload description (high level): ...
Average / peak CPU and sampling window: ...
RAM used / free and sampling window: ...
GPU usage / source: ...
Failures / retries: ...
Runtime range / actual terminal time: ...
Verifier / accepted outputs: ...
Waits (resource / auth): ...
Context and token counters (input / cached / output): ...
Human intervention minutes: ...
Notes and limitations: ...
Consent to publish these redacted measurements: YES / NO

Email only the high-level, redacted record to hello@tokenoptimisation.co.uk. Sending a record is not consent to publish; keep private fields out. Related: the 12-lane visual snapshot, agent rules, token rules, and cost calculator.