SuperNav: An Agentic Navigation System for Any Task in Any Scene

SuperNav: An Agentic Navigation System for Any Task in Any Scene
Jinkai Zhang, Jingyi Xu, Yuanhong Yu, Jiarui Guo, Hujun Bao, Xiaowei Zhou, Sida Peng (corresponding) - Zhejiang University / Shenzhen University / Causa Robotics
arXiv:2610.12126v1 [cs.RO], submitted 2026-10-08 · arXiv:2610.12126 · Project page · Code: zju3dv/SuperNav (custom "Other" license)
Code status: agent runtime, navigation tools and Skills, experiment recipes and evaluation are released; Learned Executor weights on HuggingFace the0xka1/SuperNav-Learned-Executor; InteriorGS single/multi-object test sets on yyh929/HabitatGS-Benchmark. The README release checklist still leaves "AI2-THOR demand-driven benchmark" and "real-robot deployment (Unitree Go2)" unchecked, and the repo ships no real-robot drivers.

One-line summary

SuperNav performs no navigation-specific fine-tuning. It wraps an off-the-shelf multimodal LLM in a specialized agent harness: the MLLM interprets requests, reads scenes and makes decisions, while motion is delegated to interchangeable backends through a unified visual-point interface - the model points at a destination inside an observation image and revises its decisions from execution feedback. It reaches 78.00% success on single-object navigation (best baseline UniNaVid: 34.00%), 59.50% on demand-driven navigation (OmniNav Action Former: 37.50%), and 73.33% SR / 0.4105 SPL at the 1 m threshold on a 120-episode HM3D-OVON val-unseen subset, with deployment on a real Unitree Go2.

1. The problem: task generality and scene generality, each blocked by an old route

Figure 1 (paper Fig. 1): Skill-guided sofa search. The Agent rechecks candidates, recovers from a blocked doorway, and verifies completion - the whole loop is driven by MLLM judgment.

Navigation for a general-purpose service robot is not "go to a coordinate"; it is "satisfy a sentence". Finding a specific object, visiting several targets in order, or fulfilling a high-level need such as "find a place to rest" differ not only in what is sought but in how the robot explores, tracks progress and decides completion. The paper decomposes this into two axes: task generality (adapting to different requests) and scene generality (working in environments unseen during training and system development).

Modular zero-shot pipelines (SemExp, VLFM, ApexNav and relatives) score observations for semantic relevance with a pretrained vision-language model and fold those scores into goal-directed exploration. The scores adapt to new observations, but the task logic is hard-wired: when the model participates, when exploration hands off to goal confirmation, and when execution ends are all fixed by the workflow. Change the request from "find a category" to "find this instance", "visit several targets", or "satisfy an abstract need", and goal interpretation, progress tracking and completion conditions all change - the workflow must change with them.

End-to-end methods (NaVid, UniNaVid, StreamVLN and relatives) try to cover many tasks in one model, but their generalization is capped by the coverage of navigation training data: they fine-tune a pretrained VLM on paired instructions and trajectories, learning associations among observations, instructions and behavior. Whether those associations survive new visual appearances, spatial layouts and interaction conditions is an open question, and the paper's cross-environment evaluation shows exactly that - substantial task-completion gaps for the evaluated methods in unseen scenes (Section 5).

SuperNav's starting point is a division of labor: let the MLLM use its existing general capabilities to interpret requests, understand visual observations and reason about next actions, and delegate motion execution to navigation tools, with no navigation-specific fine-tuning of the MLLM. The design borrows from general computer-use agents, where harnesses sustain tool use and context management. Adapting to a new request or scene therefore requires neither retraining the model nor rewriting a pipeline: the MLLM selects and composes available capabilities at runtime.

2. Three blocks of the harness: the Agent loop, agent-oriented Tools, Navigation Skills

Figure 2 (paper Fig. 2): (a) the Agent loop maintains context for MLLM reasoning, Skill loading and Tool calls; (b) Navigation Skills guide search, candidate rechecking, recovery and completion; (c) agent-oriented Tools support observation, motion, goal-progress tracking and closure, with point navigation sharing one image-space goal interface across geometric and learned backends.

The Agent loop organizes the request, visual observations and interaction history into a continuing process. Initialization opens a session and returns the first observation, from which the MLLM interprets the goals and completion conditions. At each subsequent step it picks one operation among observe, move, update goal state, or read Skill guidance, using the current context and task progress. Tool returns and retrieved instructions enter the context for the next decision, so execution feedback genuinely changes the plan: after approaching a candidate the MLLM inspects the new images, judges whether the candidate satisfies the request, and either records completion or keeps searching.

Long-horizon execution requires local decisions to stay connected to earlier evidence and unfinished goals. Goal records keep pending and completed items; a textual interaction history retains inspected areas, candidate clues and failed attempts. To control the growing image context the harness prunes media only: once an image has been processed and superseded by newer observations, its media payload is dropped from subsequent requests, while textual history, task state and image paths are preserved so the MLLM can fetch earlier images from the workspace on demand. This limits repeated image transmission without losing evidence.

Agent-oriented Tools bridge MLLM decisions and executable environment operations. The suite covers initialization, observation, turning, visual-point navigation, goal-progress management and termination. The design principles are "inputs easy for the MLLM to specify, returns useful for the next decision, destination representations consistent across motion backends". An observation returns four RGB images labeled front, right, back and left relative to the robot heading; the MLLM selects a destination via

$$\mathrm{PointNav}(d,\,[u,v]),\qquad u,v\in[0,1] \tag{1}$$

where $d$ identifies the view and $[u,v]$ are horizontal and vertical coordinates normalized from its top-left corner. The Agent may point at a candidate object or at visible floor, to approach a target or to obtain a new view. The Tool executes the movement internally and returns new four-view images, execution status and concise diagnostics; the turning Tool returns the same kinds of feedback. Destination selection is thus tied directly to visual rechecking, with no separate observation call needed after every movement.

Interchangeable motion backends are the payoff of the visual-point interface: destination selection is decoupled from the execution mechanism. The geometric backend (Geo-based Executor) uses depth, camera calibration and pose to associate the selected pixel with an environment location, then plans and follows a path to a reachable goal; simulation supplies rendered depth and a navigation mesh, robot deployment uses sensed geometry and localization. The learned backend (Learned Executor) follows NoMaD's goal-conditioned generative-policy design but replaces destination-image goals with marked points in reference observations, predicting local displacement increments and a stopping signal from the selected image-point pair and recent RGB. Both backends accept visual destinations and return observations with execution feedback, so the Agent's decision workflow is unchanged.

Navigation Skills package reusable navigation experience as procedural guidance the MLLM reads on demand. Each Skill is a Markdown bundle describing applicable situations, evidence to inspect, recommended steps and linked references; the bundle comprises a main navigation Skill, backend-specific tool-use instructions, and references for exploration, recovery and entrance search, together covering search, recovery and completion. The harness exposes Skill names and descriptions so the MLLM can discover the relevant package and load it into the decision context. Crucially, Skills influence decisions only by entering context: they add no environment capability and programmatically enforce neither action sequences nor semantic judgments - each operation is still chosen by the MLLM from the current request and feedback.

flowchart TD
    REQ[human request] --> INIT[open session and first 4-view observation]
    INIT --> LOOP{agent loop}
    LOOP -->|read| SKILL[Navigation Skills markdown guidance]
    SKILL --> LOOP
    LOOP -->|observe| OBS[4-view RGB front right back left]
    OBS --> LOOP
    LOOP -->|PointNav d u v| NAV[motion backend]
    NAV --> GEO[Geo-based Executor depth and navmesh]
    NAV --> LEARN[Learned Executor flow policy]
    GEO --> FB[new 4-view plus status and diagnostics]
    LEARN --> FB
    FB --> LOOP
    LOOP -->|update| PROG[goal progress pending or found]
    PROG --> LOOP
    LOOP -->|prune media only| CTX[context keeps text history state image paths]
    CTX --> LOOP
    LOOP -->|judge satisfied or blocked| CLOSE[termination tool closes session]

3. What counts as "arrived" and what counts as "done"

Instance-level arrival uses navigation-mesh geodesic distance. For a target $g$ with approved viewpoint set $V_g$ and shortest geodesic distance $d_{\mathrm{nav}}$ on the scene navigation mesh, arrival at position $p$ requires

$$\min_{v\in V_g} d_{\mathrm{nav}}(p,\,v) < 1\,\mathrm{m}. \tag{2}$$

Single-object success requires the final saved position to satisfy this test plus an explicit STOP; multi-object success requires saved trajectory positions to satisfy the targets in order, followed by explicit STOP, with earlier targets not required to remain near the final position. Scoring tests the complete approved viewpoint set at each stage using Habitat's MultiGoalShortestPath, without interpolating between saved positions; the initial position may satisfy a goal and one position may satisfy consecutive stages. Scoring happens after execution and is never returned as policy feedback - a clean separation between evaluation and the signals the policy may see.

SPL uses the dataset-provided global reference: for multi-object tasks, the shortest route over approved viewpoints in the fixed target order, computed by dynamic programming; for single-object tasks the local and global references coincide. The reference reaches the viewpoint positions themselves and is not shortened to the 1 m arrival regions; the denominator caps SPL at one. All methods share the same reference per task, SR and SPL average over all 150 tasks in each set, and failed tasks receive zero SPL.

4. Learned Executor: turning "a point in an image" into a sequence of local displacements

Figure 3 (paper Fig. 6): Learned Executor architecture. A point selected in a fixed reference image is fused with a bounded, age-aware RGB history; the policy predicts displacement increments and a stop score; the executor converts increments to motion and returns fresh observations for replanning.

A local request specifies a reference RGB image $I^{\mathrm{ref}}$ and a normalized pixel $q\in[0,1]^2$; both stay fixed for the request while the current observation $I_t$ changes with motion. Images are resized to $224\times 224$, a red ring with a central dot is drawn at $q$ to obtain $\widetilde{I}^{\mathrm{ref}}=\mathrm{Mark}(I^{\mathrm{ref}},q)$, and after ImageNet-statistic normalization a shared DINOv2 ViT-S/14 backbone $\phi$ encodes them into 384-dimensional global features. An observation projection and a goal MLP produce 256-dimensional tokens:

$$z_i = W_o\,\phi(I_i),\qquad g_t = \mathrm{MLP}_g\!\left([\phi(I_t);\ \phi(\widetilde{I}^{\mathrm{ref}})]\right). \tag{3}$$

The goal MLP has dimensions $768\to 256\to 256$ with a ReLU between its linear layers. By concatenating current and marked-reference features, $g_t$ relates the fixed destination to the current view using RGB inputs alone - no depth, no mesh.

As the robot moves, the selected destination may leave the current view, making earlier observations useful context. At observation index $t$ a history index set $\mathcal{S}_t$ containing the initial and current frames is selected, with $K_t=|\mathcal{S}_t|\leq 12$. Selection starts from a stride-two sequence plus the current frame; when it exceeds the budget the older half is repeatedly thinned while preserving endpoints, retaining observations across the local request with finer sampling toward the present. Because selected frames are not equally spaced, each frame's age is encoded with a projected sinusoidal embedding $\psi$:

$$h_i = z_i + \psi(t-i) + e_o,\qquad c_t = \mathrm{Mean}_{\mathrm{valid}}\!\left(\mathrm{Transformer}\big([\{h_i\}_{i\in\mathcal{S}_t};\ g_t+e_g]\big)\right). \tag{4}$$

Figure 4 (paper Fig. 7): Variable-length visual memory. Each row lists every stride-two candidate on a shared observation-index scale; colored frames are selected for this fusion pass, gray frames are omitted but remain in history. Repeated thinning of the older candidate half caps the input at 12 observations, selecting 5, 10 and 11 frames at $t=8,24,60$.

Fusion uses a four-layer, four-head Transformer of width 256 and feed-forward width 1024; padding is excluded from attention and pooling and the goal token participates in the mean. At inference, projected image features are cached before age embeddings are added so a selected frame can be reused with its updated age. The 12-observation budget applies per fusion pass while the feature cache retains earlier observations within the local request.

The policy predicts eight two-dimensional displacement increments, all in the robot frame at prediction time (forward $x$, left $y$). Let $P$ be expert ground-plane positions, $T$ the target frame index and $R_t$ the transform from world-plane displacements to the robot frame at $t$; the normalized training target is

$$A_k = \mathrm{clip}\!\left(\frac{R_t\big(P_{\min(t+k,\,T)} - P_{\min(t+k-1,\,T)}\big)}{0.25\,\mathrm{m}},\ -1,\ 1\right),\quad k=1,\ldots,8. \tag{5}$$

Clipping is componentwise and increments after the endpoint are zero. Multiplying predictions by 0.25 m yields metric displacement increments; summing them in the fixed prediction-time frame gives the corresponding relative waypoints. A one-dimensional U-Net generates the increment sequence conditioned on the fused representation $c_t$; following flow matching, the model interpolates between the normalized sequence $A$ and Gaussian noise $\epsilon$ and regresses the flow velocity:

$$x_\tau = (1-\tau)A + \tau\epsilon,\qquad \mathcal{L}_{\mathrm{flow}} = \frac{1}{16}\,\mathbb{E}\!\left[\left\|v_\theta(x_\tau,\tau,c_t) - (\epsilon - A)\right\|_F^2\right], \tag{6}$$

with $\tau\in[0,1]$ and the factor $\tfrac{1}{16}$ averaging over sequence components; the flow network receives the rescaled time internally. For classifier-free guidance, 10% of training samples replace the goal token with a learned null token while retaining the observation history. Separate heads predict a stopping probability $p_t$ and an auxiliary remaining-step estimate $\hat r_t$ from $c_t$; supervision uses the expert observation-index gap $r_t=T-t$ and stopping label $y_t=\mathbf{1}[r_t\leq 2]$ (the gap includes turning primitives). The total objective is

$$\mathcal{L}_{\mathrm{flow}} + 0.5\,\mathcal{L}_{\mathrm{stop}} + 0.002\,\mathcal{L}_{\mathrm{remaining}}, \tag{7}$$

with binary cross-entropy (positive-label weight 3) for stopping and squared error for the remaining gap. Training runs 45,000 updates at global batch 256 with AdamW, learning rate $10^{-4}$ for policy layers and $10^{-5}$ for the pretrained visual backbone, weight decay $10^{-6}$, 500 warmup updates then cosine decay; bfloat16 mixed precision, gradient-norm clipping at 1, EMA decay 0.999; the backbone is fine-tuned jointly and inference uses the averaged weights.

In closed loop, a new goal saves the reference image and aligns the robot with that view's capture direction. Each replanning call samples from $x_1\sim\mathcal{N}(0,I)$ with four Euler steps:

$$x_{\tau-1/4} = x_\tau - \tfrac{1}{4}\,v_{\mathrm{guided}}(x_\tau,\tau,c_t),\qquad v_{\mathrm{guided}} = v_u + 2\,(v_c - v_u), \tag{8}$$

where $v_c$ retains the goal token and $v_u$ uses the null goal with the same observation history. The executor picks one of 16 sampled sequences by endpoint-direction agreement and path straightness; selected increments are rescaled by 0.25 m and normally only a prefix of three is executed, each increment's direction and length determining a heading change and travel distance that the simulator adapter realizes as turn-then-translate primitives. Fresh RGB is then acquired and another sequence predicted toward the same reference goal. A local stop is confirmed when $p_t\geq 0.1$ holds on at least two consecutive replanning calls and the motion-progress condition is met: either (i) at least four executed primitives in total and at least three since the first above-threshold prediction in the current streak, or (ii) no executed primitives in the previous cycle. A below-threshold prediction resets the streak; the auxiliary remaining-step estimate does not gate stopping.

5. Experiments: four task families, two backends, one real robot

Main experiments use GPT-5.6 Terra with the Geo-based or Learned Executor, reporting SR (%) and SPL (0-1). On Habitat-GS and AI2-THOR the comparisons are NaVid, UniNaVid, StreamVLN and OmniNav's Action Former, each keeping its native inputs and history mechanisms. Habitat-Sim provides $640\times 480$ RGB-D at $90^\circ$ horizontal FOV and 1.25 m camera height; in InteriorGS evaluation the MLLM receives images at $256\times 192$. Geo-based Executor defaults to a 0.7 m standoff, 0.75 m candidate snap limit, 0.3 m follower goal radius and 200 follower steps - local execution limits distinct from benchmark success thresholds.

Table 1 (paper Table 1): single-object, multi-object and demand-driven results. Instance tasks use viewpoint geodesic distance <1 m; demand-driven tasks use 2 m bounding-box regions; counts in the header.

Method	Single SR	Single SPL	Multi SR	Multi SPL	Demand SR	Demand SPL
NaVid	24.67	0.1599	2.67	0.0216	17.00	0.0920
UniNaVid	34.00	0.1833	1.33	0.0131	25.00	0.0943
StreamVLN	13.33	0.1036	0.00	0.0000	25.50	0.0775
OmniNav (Action Former)	27.33	0.2133	4.00	0.0275	37.50	0.1213
SuperNav + Geo-based	78.00	0.4127	34.00	0.1388	59.50	0.1801
SuperNav + Learned	68.00	0.2059	34.00	0.0862	45.00	0.1603

Figure 5 (paper Fig. 3): Ordered multi-object navigation in simulation. The Agent visits a washing machine, a potted plant and a mahjong table in order.

On single-object tasks the Geo-based backend's 78.00% is 2.3x the strongest baseline's 34.00%; on demand-driven tasks 59.50% versus 37.50%. On multi-object tasks both backends reach the same SR (34.00%) but Geo-based is more path-efficient (SPL 0.1388 vs 0.0862). Ordered progress (paper Table 4) shows SuperNav leading every multi-object stage: at SR5 Geo-based scores 39.47% and Learned 34.21% while all four baselines score 0.00 - the baselines collapse entirely by the fifth target, exposing ordered long-chain completion as the weak point of end-to-end fine-tuned methods. On demand-driven tasks Geo-based leads the first five stages (SR5 24.32%), but no method completes six or more stages; only 3, 2 and 1 tasks are eligible for stages six, seven and eight, so long sequences remain open.

Table 2 (paper Table 2, excerpt): category-level navigation on HM3D. Thresholds apply to the shortest navigable-path distance from the final position to the nearest goal viewpoint; external entries are published results.

Method	OVON 0.25m SR	OVON 0.25m SPL	OVON 1m SR	OVON 1m SPL	HM3Dv2 0.2m SR	HM3Dv2 1m SR
MTU3D	40.80	0.1210	-	-	-	-
SoftNav	66.70	0.2570	-	-	-	-
AstraNav-Memory	-	-	62.50	0.3490	-	-
ApexNav	-	-	-	-	76.20	-
MSGNav	-	-	-	-	-	74.10
SuperNav + Geo-based	68.33	0.3837	73.33	0.4105	80.30	86.50
SuperNav + Learned	65.00	0.1355	70.83	0.1443	79.00	85.40

On the 120-episode HM3D-OVON val-unseen subset, with no OVON-specific training or adaptation, SuperNav reaches 73.33% SR / 0.4105 SPL at 1 m and 68.33% / 0.3837 at 0.25 m. The Learned Executor retains most of the success but loses path efficiency (SPL 0.1355 / 0.1443). The paper is careful to note that MTU3D, AstraNav-Memory and OmniNav's slow-system A-star branch use the same underlying navigation-mesh path-query and follower mechanism as the Geo-based Executor, which is why Geo-based is the primary OVON comparison; published entries also differ in evaluation subsets and protocols, so cross-table readings need care.

Table 3 (paper Tables 3 and 6): OVON ablations and interaction statistics. Each variant uses 120 episodes and GPT-5.6 Terra (high) unless noted; Table 6 means include all 120 episodes, successes and failures.

Variant	0.25m SR	0.25m SPL	1m SR	1m SPL	Calls	Nav	Turns	Path (m)
w/o Navigation Skills	35.00	0.2460	54.17	0.3894	7.43	5.33	0.10	7.56
w/o Agent-oriented Tool Design	52.50	0.2230	65.83	0.2855	30.28	10.72	17.56	23.60
w/o Skills and Tool Design	31.67	0.1870	54.17	0.3417	15.37	5.61	7.72	10.47
Grounding Motion Tool	55.83	0.3201	62.50	0.3624	-	-	-	-
SuperNav (GPT-6 Astra medium)	71.67	0.4579	79.17	0.4974	-	-	-	-
SuperNav (GPT-5.6 Terra high)	68.33	0.3837	73.33	0.4105	11.17	8.76	0.41	16.44

Three conclusions fall out of the ablations. First, removing Navigation Skills hurts more than restricting the interface to the front view: at 0.25 m, SR drops from 68.33% to 35.00% without Skills, versus 52.50% with Skills but front-only interaction - procedural guidance is worth more than the four-view panorama itself. Second, Tool design complements Skills: keeping Skills but going front-only drops SR and SPL while explicit turns explode (17.56 vs 0.41 for the full system), calls rise from 11.17 to 30.28 and path length from 16.44 m to 23.60 m - the Agent is forced to substitute "spin around" for "just look". Third, external language grounding does not beat the Agent's own pointing: the LocateAnything-based Grounding Motion Tool (55.83% / 62.50%) trails direct point selection (68.33% / 73.33%). Finally, the harness is model-agnostic: holding it fixed and swapping Terra (high) for Astra (medium) improves both SR and SPL (71.67% / 79.17%), showing the decision model is interchangeable.

Figure 6 (paper Fig. 5): Real-world navigation on a Unitree Go2. The robot searches for (a) a basketball and (b) another Go2, and (c) visits a printer followed by a trash bin.

On the real robot, the Go2 combines four directional RGB cameras with robot-provided LiDAR and odometry for geometric execution: camera intrinsics, mounting extrinsics and the pose associated with the selected observation relate image-space goals to the LiDAR map; a voxel-grid mapper accumulates LiDAR into a height-based 2D traversal-cost map at 0.05 m voxel and grid resolution; ReplanningAStarPlanner computes paths and a lookahead follower issues linear and angular velocity commands at 10 Hz via proportional heading control; localization uses reported odometry with no additional loop-closing SLAM. SuperNav revises routes at blocked passages, verifies targets and transitions between goals, demonstrating transfer of the harness from simulation to hardware.

6. Runtime: Codex CLI plus MCP, with hard timeouts

The Agent loop is implemented with the Codex CLI and environment operations are exposed through MCP. Each non-interactive Codex process launches with a task-specific working directory and CODEX_HOME holding its configuration, Skill snapshot and logs; native Skill loading needs filesystem reads and execution uses danger-full-access with interactive approval disabled. Instructions permit read-only access to the prescribed Skill bundle and require scene perception and action through MCP tools, forbidding filesystem or shell inspection of scene assets, ground-truth annotations, trajectories and evaluator metadata; an MCP whitelist restricts exposed environment tools. Benchmark configurations set timeouts of 3,600 s per Codex execution, 180 s for MCP startup and 300 s per tool call; the harness accepts an achieved or blocked outcome from hab_close_session only after successful closure, records missing or unsuccessful closure separately, and the batch runner handles exceptions including timeouts before continuing. The Skill snapshot manifest records file inventories, file hashes and a bundle hash checked before installation or reuse, and a visibility probe verifies the discovered name, description and source path, blocking startup on failure.

7. Limitations and risks

Author-stated limitations. SuperNav relies on the underlying MLLM for semantic judgments and is therefore bounded by its capabilities; geometric execution depends on available maps or scene geometry; MLLM inference incurs computational cost and substantial latency variability, making task duration less predictable; the demand-driven evaluation measures ordered navigation to relevant targets rather than completion of the underlying activities; extending to more real-world settings and improving reliability on long navigation sequences are left as future work.

Additional limitations from this reading. First, ordered multi-goal and long chains remain the clear weak spot: multi-object SR is only 34.00% despite 78.00% single-object, and no method completes six or more demand-driven stages - the harness solves generality of judgment but not reliability of long sequential execution, and progress bookkeeping drifts as chains lengthen. Second, cost and reproducibility: each episode carries a 3,600 s budget and decisions go through commercial MLLM APIs, so replay cost is high and coupled to a vendor; the paper's own admission of latency variability is a concrete engineering obstacle for real deployment. Third, protocol heterogeneity in the HM3D comparison: external entries differ in subsets, thresholds and step budgets (500 / 2,000 / 4,000 actions; 0.25 / 1 / 0.2 m), and although the paper documents this, a single table can still be misread as a same-protocol comparison. Fourth, the real-robot evidence is qualitative (Figure 6) with no quantitative hardware benchmark, and the geometric backend's reliance on LiDAR plus odometry is unvalidated in unstructured outdoor scenes.

8. Code and reproducibility

The repository zju3dv/SuperNav provides the agent runtime, navigation tools and Skills, experiment recipes and evaluation utilities for Habitat-GS and AI2-THOR, with a supernav CLI and a built-in browser demo (supernav web --demo). Released per the checklist: runtime/tools/Skills/recipes/evaluation, Learned Executor weights (HuggingFace the0xka1/SuperNav-Learned-Executor), and the InteriorGS single/multi-object test sets (yyh929/HabitatGS-Benchmark, 150 episodes each with reference trajectories). Not released: the AI2-THOR demand-driven benchmark and real-robot deployment (no robot drivers in the repo). Bundled recipes default to gpt-6-astra with medium reasoning; task manifests and ground truth ship separately from the source package. Readers reproducing the main tables should note that InteriorGS scene assets must be fetched separately from spatialverse/InteriorGS and converted, and that Habitat requires a dedicated venv with the CUDA-enabled SDK.

9. Takeaway

SuperNav's contribution is not a stronger navigation model but a clean division of responsibility: keep request interpretation, scene understanding and decision-making with the pretrained MLLM's general capabilities, push motion down into interchangeable tools, and stitch the two together with a visual-point interface, progress bookkeeping, media-only context pruning and Markdown Skills into an agent that sustains work. The numbers - 78.00% / 59.50% / 73.33% - show that without navigation fine-tuning one can beat both fine-tuned and modular camps across instance, multi-object, demand-driven and category-level tasks; the Astra-for-Terra swap improving scores shows the harness is decoupled from the decision model; the Go2 deployment shows the interface transfers from simulation to hardware. It also honestly exposes the two hurdles not yet crossed - long sequential execution and MLLM latency - which are precisely where agentic navigation goes next.

Golden quote

"Our key insight is to let the MLLM focus on interpreting requests, understanding scenes, and making decisions while preserving its general-purpose capabilities and delegating motion execution to navigation tools." - Keeping judgment with the general model and motion with the tools is the origin of every design choice in SuperNav.