NewtonLab: Building an Interactive Physics Laboratory

Eight interactive mechanics experiments, developed with GPT-6 Astra, explore the possibilities of reasoning models and agentic workflows for scientific software.

Try the live demo: NewtonLab — Interactive Physics Laboratory. Explore motion, forces, energy, and orbits directly in your browser, with adjustable parameters, animated diagrams, live graphs, and guided challenges. No account or software installation is required.

A block rests on an inclined plane. Increase the slope, and it begins to slide. A pendulum swings through its lowest point, exchanging gravitational potential energy for kinetic energy. A satellite accelerates toward its closest approach to a planet, then slows as it moves away. In NewtonLab, these familiar mechanics problems become interactive experiments that connect equations, motion, force vectors, and live measurements.

NewtonLab was developed with GPT-6 Astra, using initial instructions followed by additional prompts for each laboratory. This experience provides a practical perspective on a central question in agentic AI: how much of the journey from an experiment brief to an implemented, checked application can a reasoning model carry out autonomously, and where does human guidance still contribute?

Recent models such as GPT-6 Astra and Claude Fable 5.1 are designed for demanding reasoning and extended work involving code, research, and tools. Astra was the model used for NewtonLab; Fable 5.1 belongs to the broader context of this discussion. The project makes the engineering requirements behind that ambition tangible: connecting a physical model to a usable interface, preserving numerical consistency, and providing evidence that the experiment behaves as intended. OpenAI documentation, Anthropic documentation.

Eight experiments, one coherent laboratory

NewtonLab contains eight browser-based experiments aimed at high-school mechanics. Each provides an environment for changing conditions and examining their consequences.

Experiment	What learners can investigate
Inclined plane	The transition from static to sliding friction, applied forces, and energy accounting.
Projectile motion	Launch angle, gravity, linear air resistance, wind, and reaching targets.
Collisions and momentum	Mass ratios, restitution, friction, and momentum exchange at impact.
Mass–spring system	Oscillation, damping, surface friction, and the relationship between mass, stiffness, and period.
Pendulum	Small- and large-angle motion, gravity, quadratic air resistance, and measured periods.
Lever and balance	Torque, pivot position, beam weight, moment of inertia, and rotational balance.
Circular motion	Inward tension, tangential velocity, string release, and breaking limits.
Orbital motion	Bound and escaping trajectories, energy, angular momentum, and equal areas in equal times.

The interaction pattern supports deliberate exploration. Learners adjust parameters, run or pause an experiment, advance time in small steps, and inspect the resulting measurements. Guided challenges turn selected relationships into questions with observable outcomes: tune a pendulum to a two-second period, balance unequal masses, or establish an orbit with sufficient clearance above the planet.

The distinction between prediction and observation is built into several experiments. In the pendulum lab, the small-angle formula supplies a reference period, while the displayed measured period comes from crossings of the simulated trajectory. In the orbital lab, a completed revolution must actually be observed before a measured period appears. This gives learners a way to compare a theoretical expectation with the behavior of the implemented model.

What “one shot” means for a project like this

Here, “one shot” describes a user interaction: one sufficiently detailed brief initiates a complete development workflow. The system can plan the work, implement it, run checks, examine failures, and revise the result without requiring the user to prescribe every intermediate step. This usage is distinct from one-shot learning, where a model receives one example.

For a NewtonLab module, that initial brief could specify the physical assumptions, adjustable quantities, visual representations, challenge conditions, and acceptance criteria. The agent would then need to keep these requirements consistent across the solver, controls, graphs, explanations, and tests.

The surrounding software, often called an agent harness, makes this process executable. It gives the model access to project files, command execution, test results, and other tools, while managing the state of the work. Agent workflows can also divide suitable work among specialized roles, such as implementation and review. Reliable continuation and explicit progress records are established concerns in designing these systems. Anthropic’s discussion of agent harnesses.

NewtonLab’s development involved follow-up prompts for every laboratory. It is therefore an example of iterative, agent-assisted development, with one-prompt completion serving as a useful evaluation target. The relevant question is how much coherent work the agent can complete between human interventions, and whether the resulting software satisfies the scientific and interaction requirements. An honest account of this process includes the human contribution alongside the model’s capabilities.

Scientific correctness creates a demanding engineering task

An educational simulation must do more than draw plausible motion. Friction must oppose sliding and allow an object to remain at rest when the forces permit it. A collision must be resolved at contact, even when a fast-moving object crosses the contact point between rendered frames. An orbital calculation must distinguish an escaping trajectory from one that intersects the planet.

NewtonLab addresses these requirements through models suited to each experiment. Ideal circular motion uses an analytical solution. The mass–spring module uses exact linear solutions, with event handling for dry friction. The nonlinear pendulum uses numerical integration. The orbital solver adjusts its integration steps and compares its trajectory with an independently calculated geometric conic.

These choices make the project a useful setting for evaluating agentic development. The work demands decisions about assumptions, mathematical methods, event handling, and presentation, with consequences that can be checked. Producing additional code is only useful when those pieces agree.

During preparation of this article, all 114 automated tests passed on the inspected project version. The checks cover analytical comparisons, conservation relationships, event detection, invalid-input handling, challenge behavior, and shared application controls. Several modules also test that playback remains consistent across different rendering frequencies.

Passing these checks supports specific claims about the implementation. It does not establish improved student learning or complete agreement with physical apparatus. The models deliberately simplify reality: orbital motion omits atmospheric drag and additional attracting bodies; the pendulum uses an ideal string and an approximate drag coefficient; projectile air resistance follows a linear teaching model. These assumptions define what each experiment can explain.

Internal reasoning and latent-space research

The observable development process should also be distinguished from the model’s internal mechanism. Continuous latent-space reasoning is a specific research direction: Coconut, for example, feeds hidden-state representations back into a model without decoding each intermediate state into words. Hao and colleagues, Training Large Language Models to Reason in a Continuous Latent Space.

The documentation reviewed for Astra and Fable 5.1 does not establish that they use this particular mechanism. Internal reasoning, tool use, and autonomous task execution can therefore be discussed without attributing an undisclosed architecture to either model. For NewtonLab, the accessible evidence lies in the delivered software and its behavior.

A practical direction for scientific software

NewtonLab runs its simulations entirely in the browser, without accounts, an application backend, or runtime AI services. Its HTML, CSS, JavaScript modules, and SVG graphics form a static application that can be hosted independently of a model provider. This architecture allows the finished educational tool to remain usable without an ongoing inference service.

The project offers a concrete basis for studying autonomous development: a bounded scientific task, an inspectable implementation, and explicit checks. A future evaluation could give different models the same lab brief and starting repository, fix the available tools and execution budget, and record correctness, cost, elapsed time, and human interventions across repeated runs.

For researchers and educators, the opportunity is to express an experiment clearly enough that an agent can carry more of its implementation and verification. NewtonLab shows what the resulting artifact can contain: interactive mechanics, visible assumptions, measured outcomes, and tests that make the software open to scrutiny.

Open NewtonLab and try an experiment: change a ramp’s angle until a block starts sliding, tune a pendulum to a two-second period, or adjust a satellite’s launch conditions and observe whether it completes an orbit. Each offers a direct way to explore both the physics and the scientific software developed with GPT-6 Astra.