PaperlayerView exact revision on arXiv

Source-linked AI summary

Beyond Benchmarks: Can Small Open-Weight Models Get Real Coding Work Done?

Vaibhav Jain

arXiv:2610.34241v1cs.SE

TL;DR

The report asks what it takes for an open-weight model to complete coding work, rather than merely generate text. It retrospectively traces serving, agent integration, session continuity, and task verification, then reports bounded delegation outcomes and their limits.

  • Problem

    A checkpoint can load and answer questions yet fail to inspect files, call tools, maintain a long session, or preserve a repository contract.

    Source: §1 · p. 2

  • Method

    The author retrospectively analyzes saved configurations, code changes, integration tests, inference logs, debugging records, and coding-study results.

    Source: §3.1 · p. 4

  • Results

    26 retained-code successes in 30 delegated trials in the first study and 11 verified substitutions in 45 Nemotron delegated sessions under a stricter contract; direct frontier execution had lower measured frontier cost per verified result in the two studies with a direct arm.

    Source: §14 · pp. 25–26

  • Takeaways & Limitations

    Running a model or producing persuasive text is insufficient: the engineering journey also required executable tool calls, less fragile sessions, and code passing independent checks.

    Source: §14 · p. 25

    The verified coding tasks have no validated visual-design, end-user usability, or full-product experience metric.

    Source: §12 · p. 23

Abstract

from arXiv · show

Making an open-weight language model generate text is not the same as making it finish coding work. This retrospective empirical systems experience report follows my engineering work from July to October 2026 across coding clients, model-specific serving recipes, vLLM, SGLang, llama.cpp, and MLX. Models behind a nominally compatible endpoint still differed in tool-call formatting, turn control, context behavior, cache reuse, and reliability. A served model, coherent text, executed tool calls, and code that passes independent behavioral checks proved to be distinct levels of progress. The evidence includes 4,165 coding-agent gateway turns from my own sessions, 623 debug jobs, and three separate delegation studies with hidden behavioral checks and a fixed Claude Opus 5.5 parent. Saved cold-prefix requests had a median time to first token of about 69.4 s, versus 2.8 s for high-reuse requests (observational). In a 45-trial study, direct coding passed 15/15 and delegation to a quantized Qwen3-Coder 30B-A3B worker passed 12/15 and 14/15. On a second 15-task suite under a fixed artifact contract, the completed replacement cohort had 45/45 for direct coding and 12/45 for a Nemotron Cascade 2 worker (11 worker substitutions). Sixteen sessions stopped by a subscription limit before any model call were replaced; counting them as failures gives 37/45 and 8/45. A Qwen3-Coder worker passed 0/45. In both studies with a direct arm, direct coding had lower API list-price-equivalent frontier cost per verified success. A post-hoc diagnostic found that 19 of 36 artifacts rejected only for renamed parameters passed the hidden checks unchanged; they are not counted as successes. The contribution is an evidence-qualified account of serving, agent protocol, session continuity, artifact validation, and verification in practice. The studies are not pooled and do not rank models or runtimes.

1. Introduction: From a Running Model to Finished Work

The report asks what must work between an available open-weight checkpoint and coding work a developer can trust. It traces the engineering layers involved and distinguishes apparent progress from verified task completion, while limiting its claims to practitioner-facing model configurations and bounded task evidence.

1. Introduction: From a Running Model to Finished Work

  • A model’s progress spans serving, coherent text, executed tool calls, and task-specific behavioral checks; success at earlier levels does not establish verified completion.An endpoint can satisfy the first three levels while failing the fourth, and failure to execute tool calls can prevent measurement of the fourth.Source: §1 · p. 2
  • 19 of 36 artifacts rejected only for renamed parameters passed the original hidden checks unchanged, but were not official successes because they bypassed parent review and application.The diagnostic shows that an interface contract can reject functionally correct code before normal parent review; it does not establish what a study would have scored without that rule.Source: §1 · p. 3
  • The contribution is a retrospective account of runtime and recipe constraints, operational failures, cache continuity, and bounded verified-task and delegation-economics studies.The author frames these as case studies from the engineering journey, not a summary of the entire project.Source: §1 · p. 3

2. Scope: What Counts as Useful Work

  • The report separates coding-agent engineering experience from directly scored outcomes on selected TypeScript fixtures; neither is a representative evaluation of end-to-end software projects.The target was a working developer laptop alongside ordinary applications, balancing model capability against memory for context, cache, and responsive iteration.Source: §2 · pp. 3–4
  • “Small” refers to the evaluated worker configurations, including 4-bit 30B-class models with about 3B active parameters, not every model below a parameter threshold.The report does not claim results for dense 3B models, 70B models, or every configured open-weight checkpoint.Source: §2 · p. 4

3. Evidence, Workloads, and Boundaries

The report assembles retrospective evidence from saved engineering records, operational logs, and bounded coding studies, distinguishing measured outcomes from observations. It also explains why an early distributed-inference direction was set aside without treating that choice as a benchmark verdict.

3.1 Where the observations came from

  • The author re-checked reported counts against saved records and distinguishes operational measurements, hidden-check outcomes, implementation changes, and engineering observations.Readers cannot directly check the private records.Source: §3.1 · p. 4
  • 4,165 gateway turns and 623 debug jobs complement coding studies, integration records, and task-level pilots in the evidence base.These records have different units and selection procedures; operational turns came from the author’s sessions rather than randomized prompt assignments.Source: §3.1 · pp. 4–5
  • Model and workload selection followed practical problems rather than randomized matched assignments, so saved records explain engineering behavior rather than rank speed or reliability.Some results lack machine or runtime details, and most individual pilot cells have a single run.Source: §3.1 · pp. 4–5

3.2 What counts as a result

  • A verified trial requires task-specific hidden behavioral checks; a later verified substitution also requires parent inspection, confirmed application, and retained worker code.Parent approval or an emitted artifact alone does not establish verification.Source: §3.2 · p. 5
  • API list-price-equivalent frontier cost estimates published API prices from recorded frontier-model tokens; it excludes local-worker costs and is not the author’s subscription bill.An early stop can lower measured cost without yielding useful software, so it is not counted as a saving.Source: §3.2 · p. 5

4. The Early Detour: Splitting Inference Across Laptops

  • Wi-Fi distributed inference reached conversational chat, but coding-agent sessions remained too slow and cumbersome; the author moved to one serving node at a time.No matched distributed-versus-single-node benchmark was preserved, so the decision is not a measured verdict on either approach.Source: §4 · p. 6

5. One Model, Several Runtimes: Deployment Was Not Portable

Serving a checkpoint did not make its deployment portable: model behavior depended on the full runtime and client recipe. Repeatable setup and coding-client compatibility required separate engineering work.

5. One Model, Several Runtimes: Deployment Was Not Portable

  • Finding a working model-specific configuration and preserving it as a repeatable installation were distinct challenges.Setup scripts encountered dependency, kernel, driver, context-limit, and runtime-version problems.Source: §5 · pp. 6–7
  • Laptop deployment required trading a larger checkpoint’s potential capability against context capacity, responsiveness, and memory headroom, without a controlled model-size comparison.Quantization reduced weight memory but did not remove runtime, KV-cache, or concurrent-application costs.Source: §5 · pp. 7–8
  • A deployment recipe—not a model name—became the practical unit of compatibility, spanning checkpoint revision, quantization, runtime, parser/template, context, and agent client.A successful startup still had to be reproducible and expose the behavior the coding client expected.Source: §5 · p. 7
  • Selected integration cases included tool-parsing and output-limit workarounds, a pinned checkpoint revision, compiler and serialization fixes, and task-verified bounded coding runs.These were selected cases, not runtime or model rankings.Source: §5 · pp. 7–8

6. From Text Responses to Tool-Using Coding Clients

A nominally compatible API did not ensure that models and clients handled tools, turns, and session state alike. The gateway was simplified toward translation and protocol checks, but end-to-end client behavior still required testing.

6. From Text Responses to Tool-Using Coding Clients

  • Client and checkpoint combinations differed in tool-call formatting, thinking channels, tool loops, and session identifiers, so fixing one combination rarely fixed others.The same nominal API did not guarantee the same model behavior.Source: §6 · p. 8
  • The gateway was simplified toward a thin translator, with Claude-path validation limited to protocol and security checks and upstream failures propagated as errors.The client still had to be exercised end to end; the changes did not prove every failure was fixed.Source: §6 · p. 9
  • Synthetic gateway checks for Qwen3.5-122B-A10B on SGLang ranged from 2/12 to 12/12 passes, but configurations changed and the Python harness was not Claude Code.Separate existing-codebase checks were 1/3 and later 1/1 with a different task mix; those results were not combined with synthetic scores.Source: §6 · p. 9
  • Real-client episodes exposed failures that schema checks missed, including a lost working directory and streamed tool arguments handled as replacements rather than appended fragments.The episodes could derail an agent before proposed code quality was tested.Source: §6 · p. 9
  • Selected records included 294 tool-call outcomes and 144 no-tool-call stop outcomes among 492 prompts, with 54 lacking a saved parsed response.These were not exhaustive prompt outcomes or coding success rates; a stop without a tool call could be an appropriate final response.Source: §6 · p. 10

7. Long Sessions: Context and Cache State Are Part of the Integration

Long-session usability depended on both conversation continuity and runtime cache state. Saved observations and engineering changes point to application-layer prompt stability, session routing, and auxiliary requests as relevant parts of that integration.

7.1 Gemma session observations

  • Among 85 cold Gemma jobs, 54 took 65–82 seconds; some selected warm requests had TTFT near one second.Warm jobs with recorded decode throughput had a median of 38.5 tokens/s across 206 records.Source: §7.1 · p. 11, Table 3 · p. 11

7.2 Broader gateway-turn observations

  • Table 4’s warm group reused at least 8,000 prefix tokens, while its cold group reused none; these differently composed observations do not rank model speed or establish a patch effect.The cohorts differ from Table 3’s definitions, and machine provenance is incomplete.Source: §7.2 · p. 11, Table 4 · p. 11

7.3 Application-layer cache discipline

  • For exact-prefix reuse, the application kept message sequences append-only where practical and avoided reserializing tool messages or changing frozen-prefix metadata.MLX cache fingerprints were intended to include rendering inputs that affect output tokens and exclude irrelevant changing fields; hybrid-attention restore handling was also added.Source: §7.3 · p. 12

7.4 Auxiliary requests and session affinity

  • Among 65 saved auxiliary requests, 44 recorded no cached-prefix reuse; high-reuse timing records showed median TTFT of 12.2 seconds for auxiliary requests versus 2.7 seconds for main requests.These differently composed observational groups do not estimate latency caused by auxiliary requests or prove eviction in each case.Source: §7.4 · p. 12
  • Session affinity mattered alongside prefix stability: the practical principle was to preserve both the token prefix and the route to compatible cache state.The records did not isolate a speed gain from the affinity change; the application–runtime boundary can also prevent reuse when an upstream gateway changes a prefix.Source: §7.4 · p. 12

8. When the Protocol Worked, Coding Could Still Fail

Passing the tool protocol or a type check did not establish that the requested behavior was implemented. Artifact contracts, execution limits, and worker attribution introduced additional distinctions between attempted code and verified completion.

8. When the Protocol Worked, Coding Could Still Fail

  • A valid tool call and successful type check could still leave requested behavior incomplete, as illustrated by a session that reimplemented existing functionality without updating state.The example was a contemporaneous account without saved execution artifacts and remained subject to private-workload review.Source: §8 · pp. 12–13
  • Worker artifacts could fail repository contracts before code was inspected or behavior tested, while changed public signatures and malformed JSON also blocked assessment.The bounded invoice artifact failed export-preservation validation; the saved status did not identify the missing declaration.Source: §8 · p. 13
  • A 120-second worker timeout produced no candidate implementation, while the direct run fell below the intended 2,500-token workload threshold; this bounded evaluation rather than establishing worker inability.The worker stub remained untouched, so no behavioral test of its implementation was possible.Source: §8 · p. 13
  • A scorer pass alone did not establish worker substitution: one delegated arm passed with zero recorded delegation events, and another lacked inspect/apply events.Tracing the broken layer mattered alongside obtaining candidate code.Source: §8 · p. 13

9. Case Study: Coding Tasks with Hidden Behavioral Verification

The case studies test whether open-weight workers can produce task-verified coding outcomes within a fixed Claude Opus 5.5 parent workflow. They distinguish verified substitutions from artifacts that were rejected, rewritten, or only passed post-hoc checks.

9. Case Study: Coding Tasks with Hidden Behavioral Verification

  • The first repeated evaluation covered five TypeScript task categories, three conditions, and three trials per category and condition, scored with hidden behavioral checks.The fixed parent was Claude Opus 5.5; the worker was a Qwen3-Coder 30B-A3B IQ3 model, and a gateway path dropped a duplicate system message and truncated messages above 1,800 characters.Source: §9 · p. 13

9.1 Multi-trial comparison

  • In the batch-labeled condition, 14/15 trials were verified; five of those used batch calls and nine used single delegation, making this an adaptive policy rather than a clean batching comparison.Source: §9 · p. 14
  • The first study’s repeated trials covered only five task categories, so run-level intervals do not establish success-rate differences across new coding tasks.The data used three runs per task-condition cell and one worker configuration.Source: §9.1 · p. 14

9.2 Verified worker contributions

  • The earlier three-task comparison reported 3/3 verified with retained worker code for the newer arrangement and 0/3 for the earlier one.The saved summary does not characterize the arrangements well enough to isolate a mechanism.Source: §9.2 · p. 15

9.3 A Second Task Suite Under a Fixed Artifact Contract

  • The second suite used 15 synthetic TypeScript repositories and a fixed artifact contract requiring JSON, static interface checks, parent inspection, application, and passing sealed checks.The Nemotron and later Qwen cohorts were not contemporaneous or randomized together, and their results should not be pooled.Source: §9.3 · p. 15
  • 45/45 direct sessions were verified, versus 11 Nemotron worker substitutions plus one parent-rewrite verification and 0/45 Qwen substitutions.The completed replacement cohort is reported; the 16 pre-inference subscription-limit interruptions were replaced, and counting them as failures changes direct and Nemotron verification to 37/45 and 8/45.Source: Table 5a · p. 15, Table 5c · p. 16, §9.3 · pp. 16–17

9.4 When the Interface Rejects Correct Code

  • 19 of 36 artifacts rejected solely for dropping leading underscores passed hidden checks unchanged in an offline diagnostic, but were not scored substitutions.The frozen scores remained 12/45 for Nemotron and 0/45 for Qwen; the artifacts never entered normal parent inspection and application.Source: Table 5d · p. 18, §9.4 · p. 18, Figure 4 · p. 19

10. Case Study: The Cost of Delegating Implementation

The cost study compares direct frontier execution with a workflow in which a frontier parent specifies, reviews, and may recover a local worker’s implementation. Across the measured studies, delegation did not lower frontier cost per verified success, within the limits of the tested tasks and accounting.

10. Case Study: The Cost of Delegating Implementation

  • Delegation adds parent-context, specification, review, and recovery costs to worker cost, while the study measured frontier terms only.Local worker expenditure, including hardware and electricity, was not measured and must not be treated as zero.Source: §10 · p. 20
  • Direct execution had the lowest measured frontier cost per verified success across the five structured task categories.The cost totals include failed trials; direct execution also had the lowest mean frontier cost per trial in every category.Source: Table 6 · p. 20, §10 · p. 20
  • Nemotron delegation used roughly 8.6 times the direct frontier cost per verified success on the second suite.Failures are included in the spending numerator; Qwen’s cost per verified success is undefined because none were verified.Source: Table 7 · p. 21, §10 · p. 21
  • The cost finding is limited to selected tasks, study-era parent pricing, the tested worker configuration, and the delegation contract.The report does not generalize the result to cascades or model routing broadly; it contrasts its workflow with a prior positive counterexample.Source: §10 · p. 21

11. Practical Lessons Across the Journey

The report recommends evaluating coding agents at the verified-task boundary and treating deployment, session continuity, and delegation as workload-specific systems decisions. Open-weight workers produced useful verified contributions, but the tested delegation arrangements did not reduce measured frontier cost per verified success.

Define success at the task boundary

  • Serving, coherent answers, executed tools, and behaviorally verified code are distinct milestones; test the actual client and resulting behavior.A harness PASS label or plausible response is not a substitute for checking the task boundary.Source: §11 · p. 22

Treat deployment as a full recipe

  • A workable deployment depends on the full recipe and workload, including checkpoint, quantization, runtime, template, context, gateway, client, and resident memory.On a working laptop, a larger model may leave less room for KV cache, context, and other applications.Source: §11 · p. 22

Make session continuity an application-level responsibility

  • Stable prefixes, affinity to reusable cache state, and auxiliary requests matter because a continuous conversation can still incur a costly new prefill.The report proposes a bounded validation-error repair experiment, not a claim that repair improves verification or cost.Source: §11 · p. 22

Evaluate delegation per verified outcome

  • In both studies with a direct arm, delegation did not reduce measured frontier cost per verified success.The proposed follow-up would test one bounded repair attempt while measuring acceptance, verification, time, and cost, but was not run.Source: §11 · p. 22
  • Count worker code separately from verified application, include parent specification, inspection, recovery, and failed attempts, and price verified outcomes.A repair attempt may recover contract-rejected work, but adds turns and cost; only a study with the same accounting could establish its effects.Source: §11 · p. 22

Verify artifacts by behavior

  • A strict name-preservation gate can reject code that passes behavioral checks unchanged, so verify artifacts by behavior when practical.Parent acceptance remains a separate filter, and the post-hoc test did not replace frozen scores.Source: §11 · p. 22

Bound claims about model size

  • The report does not infer a model-size threshold or rank dense and mixture-of-experts architectures from its unmatched configurations.Larger dense checkpoints impose a practical resource burden, while active-parameter counts can obscure an MoE model's weight-memory burden.Source: §11 · p. 22

Value open-weight contributions

  • Open weights enabled inspection and modification of checkpoints, quantization, runtimes, templates, parsers, cache behavior, and routing, while useful local work remained distinct from lower frontier expenditure.The first study retained verified worker code in 26 of 30 trials; the Nemotron study had 11 verified worker substitutions in 45 sessions under a stricter contract.Source: §11 · p. 22

12. Limitations and Evidence Quality

The evidence is retrospective and bounded: records come from evolving, selectively saved work, and the task studies cover selected fixtures rather than representative software projects. Missing metadata, nonrandomized comparisons, scorer provenance, and accounting choices constrain what can be inferred.

Evidence quality and provenance

  • The report is not a reproducible controlled comparison across runtimes or clients: recorded changes, script PASS verdicts, and contemporaneous notes are different evidence types.The gateway turns are the author's own convenience sample, not a representative production-user cohort; prompts and tool results may contain third-party or confidential information.Source: §12 · p. 23

Private-workload and distributed-phase boundaries

  • Some private-codebase observations are reported only as generic aggregate or qualitative experience, and their use remains subject to publication-permission review.Distributed-phase records document what was built and decided, but there are no matched throughput or latency measurements to support numerical performance claims.Source: §12 · p. 23

Scorer development

  • No independently preserved pre-run snapshot of the first suite's hidden tests is available, so changes to hidden scoring logic before the later save cannot be ruled out.The study was not preregistered; the second suite's tasks, hidden checks, worker settings, and model revisions were frozen and hash-recorded before scoring.Source: §12 · p. 23

Task and outcome scope

  • The multi-trial benchmark covers five selected TypeScript tasks, not controlled real websites or broadly representative software projects.The tasks do not include validated visual-design, usability, or full-product experience measures; “real coding work” refers to agent integration and bounded task-checked implementations.Source: §12 · p. 23

Delegation study conditions

  • Sixteen pre-inference spend-limit rejections were replaced despite the written keep-all-sessions rule; counting them as failures gives 37/45 direct and 8/45 Nemotron verified.The later studies used one Claude Code parent, ran on one laptop at different times without resetting its prompt cache, and the client version changed during Nemotron execution.Source: §12 · p. 24

Worker inputs and diagnostic checks

  • The first 45-trial study omitted a separately provided constraint list from worker inputs, and two reconstructed prompts were truncated at 1,800 characters; both were failing trials.The later underscore-relaxation check was post hoc, bypassed one validation gate, and did not replay parent review or application, so it is diagnostic rather than a revised score.Source: §12 · p. 24

Operational records and cache evidence

  • Selected gateway and debug records, incomplete machine/runtime metadata, and inconsistent memory and background-activity logs prevent hardware-normalized inference comparisons or controlled multitasking conclusions.The cold and warm cache cohorts differ in evaluated prefix work and may differ in other aspects, so their TTFT differences are descriptive, not causal; the report does not quantify each patch's causal benefit.Source: §12 · p. 24

Cost accounting

  • The cost tables report API list-price-equivalent frontier cost by token/cache category, not invoiced amounts or total system cost.Hardware, engineering time, energy, and depreciation were not measured, so “cheaper” is limited to that specified frontier-cost comparison.Source: §12 · p. 24

13. Related Work

The report situates its contribution alongside work on coding evaluation, inference systems, agent reliability, and routing economics, while distinguishing its narrower executed delegation studies from those efforts. Its contribution is the combined engineering account and bounded studies, not a new general-purpose benchmark.

Coding evaluation

  • SWE-bench and SWE-Lancer address repository-level resolution and economic value with independent end-to-end checks; this report extends neither dataset.Its own tasks are much narrower and focus on operational and economic conditions around smaller self-hosted workers.Source: §13 · p. 24

Inference systems

  • vLLM and PagedAttention address KV-memory management, while SGLang describes structured execution and RadixAttention prefix reuse; this report claims neither as original.It documents application-layer prompt-stability difficulties and operational latency associated with cache state in long agent sessions.Source: §13 · p. 24

Cascades and agent reliability

  • FrugalGPT [5] provides cascade context, but supervised code delegation has a distinct accounting unit because the parent specifies and verifies the worker artifact.Jarmak [9], Harness-Bench [11], and Fan et al. [12] address reliability chains, harness sensitivity, and tool-interface effects; the report does not claim those general conclusions as new.Source: §13 · p. 25

Related evaluation settings

  • The cited studies differ in evaluation scope: serbulent-av reports single-H100 agentic coding pilots and a separate 8× H200 evaluation, while Nixon et al. [8] study governance-restricted research-data preparation.These settings should not be conflated with the report's delegation contract and frontier-cost accounting.Source: §13 · p. 25

Economics and routing

  • Peng, Lin, and Lee [6] simulate hybrid routing, whereas this report executes a frontier-parent/local-worker contract and measures frontier cost per task-verified outcome, not local hardware cost.Scrouting [13] uses reverse-direction routing, so the report's negative result does not reject cascades generally; Ariño de la Rubia and Pafka [7] also underscore variability and limited precision in three-trial cells.Source: §13 · p. 25

Contribution relative to prior work

  • The report's contribution combines runtime/client interoperability, cache and version-management observations, operational failures, and verified delegation studies with separate validation, review, and frontier-spending accounting.It presents this as an evidence-qualified account rather than a new general-purpose benchmark.Source: §13 · p. 25

14. Conclusion

The conclusion distinguishes running an open-weight model from delivering verified coding work through an agent, and reports bounded evidence that workers can contribute verified code. In the two studies with a direct arm, direct frontier execution had lower measured frontier cost per verified result; these findings concern tested combinations, not general model or delegation verdicts.

The engineering journey

  • A model running, producing persuasive text, executing tools, and leaving code that passes independent checks are distinct stages of coding-agent progress.The same nominal API could conceal differences in model behavior, runtime state, and interface failures.Source: §14 · p. 25

Bounded delegation results

  • Open-weight workers produced verified contributions: 26 retained-code successes in 30 first-study delegated trials and 11 verified substitutions in 45 Nemotron sessions under a stricter contract.The conclusion also notes that Qwen had no end-to-end verified success under that contract and that parent review rejected additional proposals.Source: §14 · p. 25

Measured economics

  • In the two studies with a direct arm, direct frontier execution had the lower measured frontier cost per verified result.The conclusion says these are properties of tested combinations, not final verdicts on the models or delegation itself.Source: §14 · p. 26

Outlook

  • The report describes increasing optimism from roughly three months of hands-on work, while explicitly not measuring an industry-wide rate of progress.The observations concern one engineering journey and its evolving integration problems.Source: §14 · p. 26
  • The gap between generating code and delivering trustworthy work remains substantial, while the conclusion frames ongoing community work as grounds for optimism.It credits researchers, serving-system engineers, maintainers, and open-source contributors for making systems accessible and improvable.Source: §14 · p. 26

Statements and data availability

Underlying research records are privately preserved and unavailable publicly or on request, limiting independent reproduction and audit. A sanitized subset may be considered after review, but no public release is currently authorized.

Data availability

  • Underlying records and raw research artifacts are privately preserved and unavailable publicly or on request, limiting independent reproduction and audit.The paper reports aggregated results and describes methodology where possible; a sanitized subset may be considered after privacy, intellectual-property, and publication-permission review, but no public release is currently authorized.Source: Statements and data availability · p. 27

Related papers

Loading 2610.34241v1…