Dino-GSP Major Update: AI geometry drawing enters the product loop

Dino-GSP shipped a set of developer-facing open capability updates on June 29, 2026.

This is not just one more button or one more endpoint. The update moves AI geometry drawing closer to a real product loop: users can start AI drawing inside your product, your backend can keep control of authentication, quotas, and risk checks, the Open Platform can track usage, rendering can use an explicit viewport, and AI-generated figures can follow a shared style template.

For EdTech SaaS products, question bank systems, AI math products, courseware editors, and curriculum content platforms, the practical message is clear: AI geometry drawing no longer has to live in an external tool. It can become a stable workflow inside your own product.

Related announcements:

Embedded editor: keep AI drawing inside your product

Starting with @dajiaoai/[email protected], embedded editor mode can enable the AI chat panel.

That means the geometry editor inside your product is no longer only a manual drawing board. A user can type a natural language request inside the embedded editor, such as "draw triangle ABC, construct its three medians, and mark centroid G", then let AI generate or revise the geometry figure.

For end users, the workflow feels direct: open the problem editor, describe the figure, see it generated, then keep dragging or editing.

For product teams, the important part is that this capability does not bypass your system. The SDK emits an aiRequest event. The host page listens for it and sends the request to your backend. Your backend performs user authentication, quota checks, and logging, then calls the Dino-GSP embedded-mode AI drawing API. The streamed response is passed back into the editor through editor.ai.consumeStream().

The boundary is explicit:

The frontend hosts the editor and consumes the returned stream
The host backend owns user identity, business quotas, plans, and risk controls
Dino-GSP handles model calls, geometry instruction generation, and streamed output
The Open Platform records application-level usage and point consumption

API and metering: make AI drawing operable

Generating a geometry figure is only the first step.

Once AI drawing enters a real product, product teams immediately need answers to operational questions:

Which application made the calls?
How much did each call consume?
How are canceled, disconnected, or failed requests accounted for?
Can the host system still apply its own user quota and plan limits?
Can issues be traced back at the application level?

The Open Platform console now supports application-level AI usage and point consumption. The embedded editor AI drawing flow is bridged by the SDK, while actual billing follows the AI token usage produced by the Dino-GSP backend. If a request consumes AI tokens, it is settled according to actual consumption.

That makes the integration more suitable for product operations. A development team can use Dino-GSP as the underlying AI geometry capability while continuing to manage user quotas, plans, call limits, risk rules, and customer billing inside its own business system.

In short: Dino-GSP draws the geometry figure and provides Open Platform usage evidence; the host product keeps its own commercial and user management boundary.

Render API: use viewBound to control export viewports

When a geometry figure enters a question bank, slide deck, handout, or report, export output has to be controllable.

Many automatic diagram workflows used to break at the final step: the figure was generated, but the exported image had too much blank space, was too tight, had inconsistent aspect ratios, or required manual cropping per problem.

This update moves Render API requests to the viewBound viewport parameter. /api/render, /api/render-svg, and /api/render-tikz use { left, right, bottom, top } to describe the logical viewport. Output canvas size is computed as width = right - left and height = top - bottom.

That matters for batch content production.

A question bank can set stable export bounds for different problem types. A courseware product can keep diagrams in a consistent aspect ratio. Publishing and curriculum platforms can put exported figures into an automated pipeline instead of cropping every image by hand.

Successful render responses also return fuller export metadata, including objectKey, the actual viewBound, and scale. That makes archiving, debugging, and reuse easier.

Templates: keep generated and exported diagrams consistent

Geometry figures in education products need to be correct, but they also need to look consistent.

If line widths, fonts, colors, point styles, and labels vary across the same question bank, the content immediately feels uneven. AI drawing can amplify this problem: one image may look acceptable, but batch generation without shared style control creates maintenance cost.

Render API and the intelligent generation API now support a template field. Render API can use template to specify the render template, and /api/agent/run also accepts an optional template field to guide the style of generated results.

This is especially useful for three kinds of teams:

Question bank and publishing teams can unify geometry figure style across exams, solutions, and handouts
EdTech SaaS products can let different schools, tenants, or brands use different visual standards
AI math products can keep generated figures aligned with product UI, report templates, and exported assets

Templates turn AI drawing from "generate an image" into something closer to "generate a reusable asset according to product standards".

Where this update fits first

This open capability update is worth evaluating if your product includes any of these workflows:

Question bank editors where teachers or operators generate geometry diagrams directly from problem text
AI solving products where explanation steps need synchronized visual geometry
Courseware and lesson planning tools where teaching diagrams are generated in the editor and exported to slides or handouts
Curriculum content platforms where geometry figures should be editable, exportable, and manageable assets
EdTech SaaS products that need professional geometry capability without building a geometry model and board engine from scratch

Geometry diagrams used to sit outside the product flow as manual illustration work. Now they can move into the product itself: user request, AI generation, editor presentation, backend metering, template-based export, and content asset reuse.

That is the key step for AI geometry drawing to become a real product capability.

How to start

Development teams can evaluate the update with this path:

Upgrade to @dajiaoai/[email protected] or later
Enable or keep the default ui.aiChatPanel in embedded editor mode
Listen for the SDK aiRequest event and forward the payload to the host backend
Authenticate the user and check quota on the host backend, then call the Dino-GSP embedded-mode AI drawing API
Consume the returned stream with editor.ai.consumeStream()
Pass viewBound in the new format when using Render API
Pass template when generated and rendered diagrams need shared style control
After launch, monitor application usage and point consumption in the Open Platform console

You can read the SDK, API, and AI integration docs on the Dino-GSP Open Platform, or try AI drawing first on the Dino-GSP main site.

Dino-GSP will keep pushing geometry drawing, dynamic editing, AI generation, format export, and product integration in the same direction: turning geometry diagrams from manual illustration work into a capability products can call, manage, and reuse.