After Astra’s launch: work, methods and new questions

Launches foreground capability lists and scores. A few days later, a useful question is what people have made and what others can inspect, edit or continue using. This topic starts with work, then examines methods, workflows and debate.

A 3D scene, an educational website and a personal blog pose different questions: can the output remain editable, can motion explain a mechanism, and can a website convey a particular person? They are not comparable benchmark tasks, but they make distinct possibilities observable.

• Astra launch record ↗Existing coverageStart with official positioning and access conditions, then explore the work below.

In his September 5 record, Simon Willison asked Astra to use Blender on a Mac to create a pelican riding a bicycle. He shared .blend files, Python scripts and a session transcript across three iterations. The useful distinction is the deliverable: the scene retains 3D structure that can be edited in Blender, beyond a rendered image.

The author then requested more background and detail, retaining earlier and later versions. For demonstrations or teaching scenes, this suggests a workflow: describe the scene, let the assistant operate the actual tool, and keep objects, materials, lighting and cameras in an editable file. Judge object relationships, appearance and subsequent edits, alongside the first impression.

This is the author’s example. We read the process and inspected the file links without reproducing the Blender scene in this review. One example does not establish general modeling ability or predict timing on other tasks and devices.

• Using Blender with coding agents on macOS ↗Author’s record · September 5Includes scene files, code and the session transcript for comparing iterations.

V2EX author int64ago shared the experience of building an educational website with Astra and published the vistep source. The stated goal is to visualize everyday mechanisms. The public repository describes short visual stories, adjustable experiments and bilingual explanations, giving readers concrete material to inspect.

A useful design goal is to keep motion, readouts and prose connected to the same explanation. Changing gear tooth counts should change speed relationships; changing a compression setting should reveal the corresponding image and information loss. These are our proposed criteria for reading and making explanations, not findings that every scene on that site has passed them.

The author reports substantial quota use, without a complete cost experiment suitable for a controlled comparison. The work and approach can be introduced now; suitability for young readers or improvement over a static explanation requires observation, beyond scene counts or code size.

• The author’s build post ↗V2EX · September 6The author’s account of tool use and the project’s purpose.
• vistep source ↗Author’s repositoryExplore the work, models and production material; repository claims do not establish learning outcomes.

Justin3go shared an Astra-assisted homepage rebuild on V2EX. On the live site, we observed a consistent combination of paper collage, an illustrated portrait and blue emphasis, followed by work, biography, experience and contact sections. The work link led to the project section with links to the actual projects.

The useful idea extends beyond a visual style: work and everyday interests share a narrative, letting visitors understand a person through specifics. For an AI-assisted personal website, actual projects, experience and the qualities you want visitors to remember give the design a clearer starting point.

We checked the homepage and work entry, without auditing the full site or testing phones, screen readers or sustained performance. The post does not separate model-generated work from human adjustments. It supports a discussion of expression and interaction, not a claim that Astra autonomously designed everything.

• Author’s post ↗V2EX · September 6Identifies the tool used for the rebuild; inspect the result separately.
• Justin3go’s website ↗Live work · Viewed September 7Explore the homepage narrative and project links.

Robocurve’s September 4 report tested Astra on YAM arms with two tasks. The figure redraws its reported Astra completion counts. Objects were reset by hand and graders knew the model; two tasks do not establish general robot ability.

Compare the linked trial records: the bowl example received a successful human judgment; the puzzle example terminated with done but was graded partial, at stage 3. The model’s completion signal and the physical outcome need separate checks. We read these records without operating the arms or reproducing the experiment.

For your own project, define the final state and identify the step that repeatedly fails. Picking up, moving above a target and placing correctly each require observation; an impressive movement alone does not complete the task.

• Robocurve experiment report ↗Third-party experiment · September 4Tasks, results and limitations.
• Block trial record ↗Published trial logAn example judged successful by the operator.
• Incomplete puzzle trial ↗Published trial logThe termination signal and human verdict differ.

Little Dorrit Editor asks models to locate handwritten edits and recover the intended revision. On September 7, the board showed F1 of 0.7778 for Astra through OpenRouter and 0.7316 for Fable 5.1. Their reported 95% intervals overlap, and Claude inputs undergo resizing and recompression; the scores do not settle performance on every document task.

For example, crossing out “Friday” and writing “Thursday” calls for a replacement, rather than a transcription of both words. This is our illustrative example, not a model test. When processing annotations, ask for the location, original text, proposed revision and uncertain cases, then accept changes against the source image.

F1 combines precision and recall; it is not character-recognition accuracy. The technical report also notes the small dataset. Further work on layouts, languages and actual revision workflows would add useful evidence.

• Little Dorrit Editor board and examples ↗Project page · Read September 7Inspect metrics and input-processing notes.
• Benchmark technical report ↗Authors’ methodsExplains scoring, sample size and interval estimates.

OpenAI’s September 6 internal report describes researchers using concurrent coding agents, contributing more code and running more experiments. It also notes other research bottlenecks: code and experiment volume do not directly measure scientific progress.

Individuals and small teams can examine the division of responsibility: delegate defined tasks while retaining decisions about priorities, which results merit further work, and when to scale, pause or stop. Wider automation calls for clearer acceptance questions, beyond simply opening more sessions.

These are internal observations across time, involving different models and changing tools. They provide relevant context for Astra, without attributing every change to it or estimating gains for external teams.

• Research acceleration: The view inside OpenAI ↗OpenAI internal observations · September 6Includes methods and measurement limits to read alongside the charts.

An Alien Mind, published the same day and signed by Jakub Pachocki, discusses incomplete understanding of capability generalization and monitoring, arguing for caution about rapid progress. Such an insider’s reasoning warrants attention without waiting for another model release.

Separate the observations the author cites, the inferences he makes and the actions he advocates. This is a guide to a perspective; we have not independently verified every internal event and do not treat predictions as established events.

• An Alien Mind ↗Signed article by Jakub Pachocki · September 6The original connects capability, monitoring and development pace.

This topic starts with the available material. Further work, explanations and user reports will be added around specific questions. These questions remain open; useful methods and perspectives can matter without a new product announcement.

• How do quality, revisions and total cost compare on the same task?
• Do these works remain usable on phones and understandable to newcomers?
• What recurring problems emerge in sustained use beyond official descriptions?