Tancho

Tancho is an on-board model for disaster reconnaissance flights. Given the frame the aircraft is looking at and an observation goal expressed as numbers, it emits a viewpoint sequence — where to fly next, what to point at, how long to dwell — which a separate safety layer checks before the aircraft flies it.

Only that face has been measured. The scene-reading face described below has no valid evaluation task yet, so do not read the sentence above as a claim about it.

It is a fine-tune of nvidia/Cosmos3-Edge, developed in Japan by Vox, in Tokyo and published under the v13s namespace. The task design, the training-data preparation, the fine-tuning runs and the evaluation were all carried out in Japan by Vox; Nebius AI Cloud supplied the compute. The weights are publicly available free of charge under the same licence as the base model. First published 2026-09-12; card updated 2026-09-13.

Where this model was developed

Tancho was developed in Japan, by Vox, which operates from Tokyo. The task was designed, the training data prepared, the fine-tuning runs executed and the results evaluated in Japan by Vox. Nebius AI Cloud supplied rented compute; it contributed no model design, no data and no evaluation. The base model is NVIDIA's, used under its published licence, and the footage is public Japanese government data.

Two roles, one trained tower, and what was deliberately removed

These are two intended application roles. Only the Generator role has been trained and evaluated on the viewpoint task for this release. Only the autoregressive tower was fine-tuned, and both roles are answered as text. The project's own development plan says a checkpoint may be published as having two trained faces only if that integration succeeds; it has not been attempted, so this page does not make that claim.

Face	Input	Output	In the loop
Scene role ("Reasoner")	frames, telemetry, mission context	scene reading, what is still unknown, an observation goal	outer; median 30 s is a design target, not a measurement
Viewpoint role ("Generator")	the current view, plus the goal, target position and size, the approved volume, required pixels, depression angle and viewing direction as numbers	an ordered list of viewpoints: local-ENU position, target coordinate, dwell time	outer

Detection and area segmentation are not Tancho's job. They were removed on 2026-09-11 after measuring the base model against purpose-built components on the same ground truth and the same metric:

Task	Purpose-built component	Base Cosmos3-Edge	Ground truth
Finding people	detector, F1 0.588–0.654	F1 0.024–0.065	same 30 frames, 82 people
Finding vehicles	detector, F1 0.564–0.568	F1 0.224–0.332	same 10 frames, 77 vehicles. Ten frames cannot carry a difference claim; no test was run
Slope-failure area	cell classifier, IoU 0.718	IoU 0.675	same 30 frames, 19–5–6 on paired tiles, p=0.0066

The detector range is the best two of seven configurations tried on the same ground truth; across all seven it runs from 0.061 to 0.654, so the range above is a selected one. Only the slope-failure row carries a test, and it is the only one of the three that should be read as a measured difference. The people and vehicle rows are descriptive results on these packs; their numerical gaps do not establish generalization to other flights.

Fine-tuning did not repair either task. Detection went 0.332 → 0.228 on vehicles alone, against 17 frames and 27 updates, and that drop carries no test either. Slope-failure segmentation is worse than it looks: the run on 30 frames returned an empty answer for every frame (IoU 0.000) because four empty targets dominated the loss, and the 0.467 figure comes from re-running on the 26 frames left after dropping them, at 36 updates. Both runs were small, so this is not evidence that Cosmos3-Edge cannot learn. It is evidence about which component should carry which job at this scale.

The detector numbers depend on imperfect labels. The same person read each pack twice, so these are not independent readers. The bounding-box pack had agreement F1 0.753. The people pack had agreement 0.677 under different instructions and effort on the two passes; repeatability under an identical procedure remains unmeasured. Neither agreement value is a mathematical ceiling on model performance.

Measured result: the viewpoint-sequence task

For the viewpoint role the model is given the frame the aircraft is currently looking at, together with an approved volume, a target position and size, a required pixel count, a depression-angle range and a desired viewing direction, the latter all as numbers. It must return a viewpoint sequence satisfying the specified geometric and flight-envelope checks. Passing these checks does not establish real-flight safety or image quality. Targets come from a deterministic path planner, so the task uses no human labels.

On 40 evaluation items excluded from training, the fine-tuned model satisfied every requirement on 21 (2026-09-12). Those are the weights in checkpoint/detect240/. The run that first produced this result kept no checkpoints — it was configured not to, to keep storage down — so it was re-run on 2026-09-12 under identical conditions: same training pack, same 240 updates, same base revision, same evaluation answers. It reproduced every number on this page exactly, including the per-checkpoint ladder (6, 18, 21) and the cross-fit selection, which again chose the 240-update export on both halves. Requirements are: the flight contract, matching the named target, staying inside the approved volume, meeting the required pixel count, the depression-angle range, and the viewing direction.

Three things must not be placed beside that 21.

1. The base weights. They were never measured on this task. An earlier 1/40 figure belongs to a different task with different pixel requirements.
2. The deterministic planner. It scores 40/40 because it defines what "satisfied" means and also generates the training targets. Quoting it as a comparison is a tautology.
3. The earlier 17/40. Same task, same answers, run before the training data was fixed. Two things were fixed at once — 134 of 480 targets that disagreed with their own prompt, and 165 viewpoints sitting exactly on the edge of the height band — so which one mattered is not separable. Paired per item the difference is 9 wins, 7 losses, 24 ties, sign test p=0.80. This comparison does not establish an improvement; it also does not establish equivalence. The 17/40 is a cross-fit selection result; the paired fixed 240-update comparison is 19/40 versus 21/40.

Per requirement, the 240-update export scores: flight contract 40/40, target match 40/40, approved volume 40/40, depression angle 37/40, required pixels 24/40, viewing direction 37/40. In the earlier fixed 240-update run, approved volume was 39/40, required pixels 28/40, depression angle 36/40 and viewing direction 31/40. These are descriptive differences across runs with both training fixes applied. Only 3 of the 40 items can be satisfied without moving the aircraft, so the requirements genuinely constrain position.

An earlier experiment used the desired viewing direction as a unit vector rather than as words. That comparison is confounded twice over: the update budget changed at the same time, and it was run on the earlier evaluation pack, the one retracted below — so its numbers are not on the same scale as the 21 and are left out here deliberately. Checkpoint selection was cross-fit: the 40 items were split, one half chose the checkpoint and the other half scored it, and both halves chose the same one. These items therefore also participated in checkpoint selection; they are not an untouched final test set. All training and evaluation items come from one flight.

Retracted numbers

Retracted	What was wrong
27 / 40	The required pixel counts it used (120 px for vehicles) had no provenance, and almost nothing in the available footage reaches 120 px: none of the 82 labelled people and 3 of 184 vehicles. Re-derived from operational intent, the task gives 17, then 21.
17 / 40	Same task, run with 134 of 480 training items mismatched. Corrected to 21.

Required pixel counts are now derived from a distance and a decision: a person judged "standing or fallen" at 50 m (76 px), a vehicle judged "buried or overturned" at 80 m (126 px). These two distances were set by Vox, not by an operator, and will be re-derived in field use.

Public checkpoint and subsequent research

The published checkpoint is the v7 detect240 export. Subsequent local research uses mixed240 and current288 with a conditional router. Those checkpoints and routing results are not the weights or performance of this release. No continuous camera trajectory generation or learned-model flight execution has been validated here.

The Reasoner face has no valid task yet

This is the honest gap. Three candidate evaluation tasks were built and all three were dropped before spending any GPU time, each because a rule that never looks at the image already solved them:

• per-tile "is it worth flying closer": ground truth collapsed into whether the detector happened to fire (majority 0.504; the recorded agreement statistic of 0.624 is not a mathematical model-performance ceiling)
• per-target "is it worth flying closer": apparent size alone reaches 0.739 against a 0.665 majority, and apparent size is computable from distance and real size
• "which candidate to look at next": the priority table reaches 1.000, because its inputs are all already in the candidate list

The common cause is that the inner loop now emits everything the decision needs. Whatever the Reasoner is worth lies on the other side of that boundary — what the detector and the classifier do not name at all. Defining that task needs footage the project does not yet hold.

Training

Item	Value
Base	nvidia/Cosmos3-Edge
Base revision	a9d944e2c6a1bf9f48b92ad16348e70c5f1836ba
Cosmos Framework revision	0fe093eafbac390ffb7906a6f4ed9f558fe42c4c
Starting weights	the pinned pretrained base revision, with a fresh fine-tuning run. The trainer refuses to start if a checkpoint load path is set, so these weights carry no earlier Tancho fine-tune — in particular none of the retired parent-40 line described under History
What was fine-tuned	the autoregressive tower only. The image encoder is frozen, and the base model's diffusion tower and VAE are untouched
How the viewpoint sequence is produced	as JSON text, greedy decoding, 768 new tokens at most. Not by the diffusion tower
Training data	disaster-viewpoint-train-v4: 480 items, one viewpoint each, every target produced by the deterministic planner
Updates	240, chosen by cross-fit on a split of the evaluation items; both halves chose the same export
Run	41 minutes on one rented GPU
Hardware	Nebius AI Cloud
Intended runtime	NVIDIA Jetson Orin NX 16GB. Not yet measured on that device.

A caution about model size. The upstream Cosmos3-Edge is a multi-part model, and its diffusion tower and VAE account for most of its bytes. Those parts were not fine-tuned and take no part in producing a viewpoint sequence, so the base model's overall size is not a description of what was trained here. Quote the fine-tuned tower, not the family.

What is in this repository

Path
checkpoint/detect240/	the export, 31 files, 4.569 GiB. 00000.safetensors (3.966 GiB) and 00001.safetensors (0.570 GiB) carry the weights; the rest are the tokenizer, the processor config and the framework's own assets
README.md	this page
NOTICE.md, SOURCES.md, licenses/	licence terms, attribution and the upstream licence text
HISTORY-parent40.md, EVALUATION_*.md, evidence-summary.json	the retired parent-40 line, kept as a record

Every uploaded file was checked against the SHA-256 recorded when the training job retained it: 31 of 31 match, and the byte total agrees exactly.

Loading needs the pinned Cosmos framework revision above, not a plain transformers call. The exported weights contain the fine-tuned autoregressive tower and frozen image encoder. The diffusion tower and VAE are not used for viewpoint JSON generation.

Limitations

• Training and evaluation come from the same flight. Cross-site generalization has not been measured for this model. Results from a separate slope-failure classifier cannot supply a discount factor or an estimate of Tancho performance at a new site.
• No real flight has been run with this model in the loop. The measured task is a geometric one built by the project; it does not predict behaviour in flight.
• Speed on Jetson Orin NX is unmeasured. The outer loop is designed for a median of 30 s and a maximum of 60 s; that is a target, not a measurement.
• Object state cannot be judged from the available footage. No person in the labelled set exceeds 69 px, so "standing or fallen" has never been tested.
• Cross-site generalization of the area components is partial. A slope-failure classifier taken to an unseen site falls to IoU 0.589; reading a few dozen frames from that site and adding negatives brings it back (0.548 → 0.682, 25–9, p=0.0090), but all three test splits are from the same site, so this is not a cross-site result.
• Wildfire, mountain search-and-rescue and wildlife survey have no footage at all. Any statement about fitness for those is inference, not measurement.
• The ground truth for the viewpoint task is defined by the planner, not reviewed twice by people. The task does not need a second reading, but this is not external validation.

Data and licences

All footage is public UAV video published by the Geospatial Information Authority of Japan (GSI), under the Japanese Public Data License 1.0, whose text permits commercial use and requires attribution and a statement of any processing. No client footage was used.

These weights were trained and scored on one event only: Omachi, Nagano, 13 October 2019 (Typhoon Hagibis). All 480 training items and all 40 evaluation items are tiles from that single flight, split so that no evaluation tile appears in training. The Aso Bridge and Sannoudani River footage (2016 Kumamoto earthquake) belongs to the detector and slope-failure experiments and to the retired parent-40 line; it is not in this model's training set.

One note on the split. SOURCES.md and the archived evidence-summary.json mark Omachi as evaluation-only. That policy was written for the retired three-way observation task, and the viewpoint task draws from the training split of a separately built tile pack. No decision record exists that widened the policy explicitly, so it is recorded here rather than left to be discovered.

The base model is provided under OpenMDW 1.1, which permits commercial use and derivatives with no copyleft. This release keeps the licence text and the upstream attribution and copyright notices; see NOTICE.md for the separate documentation, model and data terms, and SOURCES.md for attribution. Cosmos and NVIDIA are not used as marks of this model, and nothing here implies endorsement by NVIDIA, Nebius or GSI.

Original documentation and code in this repository are MIT licensed.

History

The earlier line of work — the parent-40 Reasoner checkpoint and a three-way no_action / inspect / abstain task — was retired on 2026-09-09 when the task itself failed to hold still: the same reviewer answered 9 of 15 repeated questions the same way, and on the sets that decided the question every fine-tuned model scored below a rule that ignores the image. That record is kept in HISTORY-parent40.md. It contains a 21/40 that is unrelated to the viewpoint result above.

Contact

tancho@vox.delivery