STARGAZE Release 01

Software
with a horizon.

Stargaze is the software house of Pranav Dwivedi. Autonomous agents, local-first tools and vision systems, built close to the metal and released when they hold.

See the systems Back to Pranav
EST. 2026 SOFTWARE / SYSTEMS / VISION SCROLL
01 / The branch

Built close
to the metal.

01

Local first

The useful version runs on your hardware. Local models, local files, local control, with the cloud as an option rather than the foundation.

02

Quiet by default

No dashboards that perform. No notifications that beg. Software should do the work and stay out of the way until it has something worth saying.

03

Real world

Agents that touch devices, vision that reads a moving batter, interfaces that survive actual use. The test is outside the demo.

02 / In the hangar

Systems,
not demos.

The first four systems being folded into Stargaze. The full index, including the public lab projects, lives on the work page.

01 JARVIS Core Autonomous personal AI for rooted Android and Linux. Memory, tools, device control. Private build 02 AXIOM Core Local agent interface, voice pipeline and cross-device brain sync. Private build 03 Cricket Motion Lab MediaPipe batting analysis, bat velocity and swing trajectory scoring. Public lab 04 VISA-PAY 2.0 Lab A zero-dependency fintech interface study built around fluid micro-interactions. Public lab
All six systems
03 / Engineering

Small pieces,
held together.

01

Boring foundations

Files, processes and local sockets before new infrastructure. The least surprising layer is usually the one that survives the longest.

02

One job per tool

Each service should be small enough to explain, replace and debug on its own. Integration is a contract, not a pile of shared state.

03

Ship the edge

The first release does not need every feature. It needs one useful path through the system that works on a real device, on a bad connection.

04 / Release 01

Coming
into view.

Stargaze is in private build. The first public release will collect the core systems under one roof, with the agents first and the lab projects alongside them.

Ask about early access
StatusPrivate build
Window2026
First outSystem 01
BranchIndependent

The
name.

Why the branch is called Stargaze.

Stargaze is the part of the work that looks past the current release. It is a software house, not a personal brand: a place to hold the agents, tools and vision systems under one standard.

The name is a direction, not a promise. The useful version is built close to the metal, released when it holds, and allowed to stay small enough to understand.

Release 01
scope.

The first public shape of the branch.

01 / CoreAgents

JARVIS and AXIOM as the first systems, with the memory and tool layers made legible.

02 / LabVision

Cricket Motion and the sports-vision work, starting with a reliable batting session.

03 / ToolsDevices

The Android and Linux utilities that make the rest of the work possible.

04 / WebThe branch

A public home for the release notes, the systems and the status of each build.

05 / DocsThe rules

A short explanation of what runs locally, what leaves the device and why.

06 / AccessEarly users

A small group of people who will use the systems on real devices before the wider release.

The
core.

The systems that define the branch.

01JARVIS

Persistent personal AI across rooted Android and Linux. Memory, tools, device control and model routing.

Private
02AXIOM

Local agent interface with a voice pipeline, embedded console and cross-device sync.

Private
03Agent Visibility

A console pattern for showing what an agent is doing, what it tried and what failed.

Lab
04Mobile Harness

A real shell and coding loop on Android, built for the device in the pocket.

Lab

The
lab.

Public experiments with a clear question.

01Cricket Motion

Batting analysis with pose estimation, bat velocity and swing trajectory scoring.

Public
02VISA-PAY 2.0

A zero-dependency fintech interface study built around fluid micro-interactions.

Public
03PiXel Arena

A tournament engine with brackets, live leaderboards and hardened Firestore rules.

Public
04Watch Together

Serverless watch parties that keep the room in the browser.

Public
05HonestBroker

A market simulation with spreads, slippage and fills that do not flatter the user.

Public

The tool
bench.

Small software that repairs or extends a machine.

01Plutooth

Bluetooth recovery on rooted Android, without ADB or a desktop.

Public
02Remote PC

A lightweight remote-control bridge for a desktop from a phone or browser.

Public
03MTProto.zig

An obfuscated TLS proxy written in Zig as a protocol exercise.

Public
04Local Network Chat

Peer-to-peer chat over a LAN, hosted as a static page.

Public
05Insta

A tiny peer-to-peer chat with no backend or sign-up.

Public

Architecture in
one page.

The shape the systems share.

01Device

The phone or laptop is the first target. Local files, local sensors and a real permission model.

02Runtime

Python and Kotlin for the working layer, with TypeScript for interfaces and tooling.

03Models

Local first, hosted when necessary. The router must make the trade-off visible.

04Memory

A file-backed store with an inspectable index, not an invisible personality.

05Tools

Small, named actions with explicit inputs and a recovery path.

06Interface

State, intent and failure visible in the same place.

Local first,
concretely.

What the principle means in the build.

  • The primary task works with the network switched off.
  • The app tells you when a cloud model is being used.
  • Files stay readable on the device that created them.
  • A failed sync does not erase the local copy.
  • The user can export the useful data without a support ticket.
  • A local model can be swapped without rebuilding the interface.

Model
routing.

The choice between local and hosted is part of the product.

A router should not be a magic switch. It should know the task, the device, the latency budget and the privacy cost. If a request needs a hosted model, the interface should say so before the data leaves.

The first version is deliberately simple: a small policy table, a visible decision and a manual override. The interesting work is not the model list. It is making the trade-off understandable when the user is in a hurry.

Memory, without
theatre.

What the system keeps and how you can inspect it.

01Facts

Stable preferences and context, stored with a source and a date.

Inspect
02Episodes

A compact record of what happened in a session, not a transcript of everything.

Inspect
03Tools

A log of calls, arguments and results, with a clear failure state.

Inspect
04Forget

A direct way to remove a memory and see what changed.

Control

Tools and
permissions.

The rules that keep an agent useful without making it reckless.

  • Every tool has a name, a scope and a visible result.
  • Destructive actions require a confirmation that names the target.
  • The agent can explain why it chose a tool, not only which one.
  • A failed call leaves the workspace in a recoverable state.
  • The permission model is the same on phone and desktop.
  • The user can stop the loop without killing the app.

Voice as an
interface.

Speech is a channel, not a personality.

The voice layer is useful when the hands are busy or the screen is far away. It is not a reason to make every interaction a performance. The system should support a short command, a longer dictation and a silent fallback.

The hard parts are interruption, confirmation and the moment a spoken request turns into a tool call. Those are interface problems before they are model problems.

Vision as a
sensor.

A camera is only useful if it produces a decision.

Cricket Motion started with a simple question: can a phone camera tell a batter something useful about the swing? The answer has to be more specific than a skeleton on a screen. It has to connect a measurement to a change in the next repetition.

The first release is a session tool, not a coaching oracle. It should capture cleanly, show the useful angle and keep the data honest about what it can and cannot see.

Android as a
first-class target.

The phone is a computer, not a preview.

Most of the work assumes a rooted Android device can be a real workstation. That means Termux, local files, background services and a permission model that is treated as part of the product.

The constraint is useful. A tool that survives a phone has fewer hidden assumptions than one that only runs on a desk with a reliable power supply.

Security
posture.

The baseline for a system with device access.

  • Secrets stay out of the repository and out of the interface.
  • The agent cannot silently widen its own permissions.
  • Tool output is treated as untrusted input.
  • Network access is visible and can be disabled.
  • A local backup exists before a migration touches the data.

Release
cadence.

A rough sequence, not a promise of dates.

  1. NowPrivate buildCore systems used daily on real devices. Scope is still moving.
  2. NextRelease 01The first public bundle: agents, lab projects and the branch site.
  3. AfterEarly accessA small group tests the install, the permissions and the recovery paths.
  4. LaterPublic labThe public tools and experiments get a stable home and a shorter path to source.
  5. LaterThe archiveThe older builds are indexed without pretending they are current.

What we will
not build.

The boundaries are part of the design.

  • A dashboard that exists only to look busy.
  • An agent that hides its tool calls from the person using it.
  • A cloud dependency for a task that can run locally.
  • A release that needs a tutorial before the first useful action.
  • A feature that makes the recovery path harder to explain.

Open
questions.

The problems still on the bench.

01How local?

How much useful intelligence can run on a phone before the hosted model becomes an honest requirement?

Core
02How visible?

How much agent state should the interface show before it becomes another dashboard?

UX
03How safe?

Which permissions can be delegated without making the user responsible for every tool call?

Security
04How useful?

What does a cricket session need to change in the next repetition, not only in the report?

Vision
05How open?

Which parts of the core can be public without turning the release into a support burden?

Branch

The
bench.

The tools under the current build.

01Python

Agents, vision, local services and the glue that holds the lab together.

02Kotlin

Android interfaces, rooted-device tools and the Compose layer.

03TypeScript

Agent interfaces, web surfaces and the visibility console.

04Zig

Small systems work where explicit control is worth the friction.

05MediaPipe

Pose estimation for the cricket experiments.

06FastAPI

Local service boundaries that stay readable.

07Termux

The phone as a real shell, not a remote preview.

Early
access.

Release 01 is still in private build. If you want to test it on a real device and can live with rough edges, say what you would use it for.

Send a note
StatusPrivate build First outAgents + lab BranchIndependent

Field
notes.

Short observations from the build.

01The phone is the test

A feature that only works on the desk is still a prototype, whatever the release notes say.

Note
02Visible failure

An agent that can say what went wrong is more useful than one that only succeeds on the happy path.

Note
03The cost of magic

Every hidden step saves a click and spends a little trust. Use it carefully.

Note
04Small releases

A narrow release that holds is better than a broad one that needs a rescue plan.

Note