DEV Community: OpenTiny

TinyVue v3.31 Released: New Components & Optimized Documentation With Multiple Practical Feature Upgrades

OpenTiny — Wed, 12 Aug 2026 06:28:49 +0000

Release Overview

TinyVue v3.31.0 is officially launched, bringing the following updates:

New Component: SliderButtonGroup (1 new component)
New Features & Prop Enhancements (6 items): Modal before-close, Drawer destroyOnClose, SVG URL encoding for Image, Tag round, resizable Alert sizes, Switch display-only
Docs & Demos: Complete API docs and examples for Flowchart component
Bug Fixes: 52 bug fixes for improved overall stability

Full detailed Release Notes: TinyVue v3.31.0 Release Notes

New Contributors

We have 3 first-time contributors for this release: @Malusnow, @xuxiao1797, @cfljue. They contributed fixes for dialog-select multi-selection sync, wildcard support for file-upload, and fluent-editor line height formatting respectively. A big welcome to our new partners, and sincere thanks to all new & existing contributors for their hard work on TinyVue 👏

Feature Breakdown

1. New Component: SliderButtonGroup

SliderButtonGroup is a brand-new component introduced in v3.31.0. Similar to ButtonGroup, it contains multiple SliderButton items. An animated white background slider indicates the active option. When users switch selections, the highlight block slides smoothly between buttons. It supports text & icon variants, plus small / medium / large size options, ideal for page mode switching scenarios.

<template>
  <tiny-slider-button-group v-model="value">
    <tiny-slider-button label="1">Today</tiny-slider-button>
    <tiny-slider-button label="2">This Week</tiny-slider-button>
    <tiny-slider-button label="3">This Month</tiny-slider-button>
  </tiny-slider-button-group>
</template>

<script>
import { TinySliderButton, TinySliderButtonGroup } from "@opentiny/vue";
export default {
  components: { TinySliderButton, TinySliderButtonGroup },
  data() {
    return { value: "1" };
  },
};
</script>

2. Flowchart Component Docs & Examples Completed

We have fully supplemented API documentation and demo cases for the Flowchart component.
Flowchart enables custom workflow diagram creation without third-party libraries. It supports stateful nodes & links, click events on nodes/links/blank canvas areas, and custom node templates via slots. Link styles can be configured through dedicated settings.

<template>
  <tiny-flowchart :data="data" :config="config" />
</template>

<script setup>
import { TinyFlowchart } from "@opentiny/vue";
import { reactive } from "vue";
const { createNode, createLink, createConfig } = TinyFlowchart;

const config = createConfig();
config.width = 960;
config.height = 260;

const data = reactive({
  nodes: [
    createNode("1", 1, "Submit Application", "2024-01-01", null, 1, 1),
    createNode("2", 2, "Supervisor Approval", "2024-01-02", null, 1, 3),
    createNode("3", 3, "Process Completed", "", null, 1, 5),
  ],
  links: [
    createLink("1", "2", "0 r2", 2, "solid"),
    createLink("2", "3", "0 r2", 3, "solid")
  ],
});
</script>

Unlike traditional DOM-based components, Flowchart renders via Canvas and provides multiple static helper methods:

createNode: Quickly generate node objects
createLink: Generate connection line objects
createConfig: Set canvas width, height and global configurations

Structured array data can be directly mapped from backend responses without manual coordinate maintenance on the presentation layer.
Supported use cases include basic workflows, card-style branch diagrams, grid route charts, dynamic approval progress updates, click event handling, approver roster display with createItem, and fully customized node slots.

3. Existing Component Enhancements

This release delivers multiple practical prop upgrades. The most noteworthy improvement is modal close interception logic: Previously, un-saved form validation logic needed to be handled in outer parent components. Now Modal provides a native before-close callback to centralize close confirmation workflows.

Component	New Prop	Usage Scenario
Modal	`before-close`	Intercept close actions to prompt users about unsaved edits
Drawer	`destroyOnClose`	Destroy internal content on close to retain no residual form state
Image	SVG URL encoding	Directly render SVG images with special characters in URLs
Tag	`round`	Fully rounded tag style
Alert	size (small / medium)	Compact alert banner variants
Switch	`display-only`	Read-only static display of switch status

These upgrades require no changes to your business data structures; you can adopt them per component on a page-by-page basis during version upgrade.

Key Bug Fixes

Fixed issue where size prop failed to take effect for buttons inside form-item (PR #4206); adjusted padding-top of inline form-item to 12px
DatePicker: Fixed blank panel after half-selection clearing; resolved one-day date offset bug across multi-timezone environments for DatePicker / DatePanel
FileUpload: Added wildcard support for video/* and audio/* MIME types to align with HTTP standards; fixed errors triggered when webkitGetAsEntry() returns null (PR #4226)

About OpenTiny NEXT

OpenTiny NEXT is an enterprise-grade intelligent frontend solution built on Generative UI and WebMCP core technologies. It delivers intelligent upgrades for legacy products including the TinyVue component library and TinyEngine low-code engine, while launching Agent-native products such as front-end NEXT-SDKs, AI Extension, TinyRobot AI Assistant and GenUI. The suite empowers AI to interpret user intentions and complete tasks autonomously, accelerating intelligent transformation for enterprise applications.

Join the OpenTiny Open Source Community

WeChat Assistant: opentiny-official

Official Website: https://opentiny.design
TinyVue Repository: https://github.com/opentiny/vue (Star ⭐ appreciated)

If you wish to contribute, locate issues tagged good first issue in the repository. Feel free to leave comments with any questions or feedback!

GenUI SDK v1.3.0 Released: Cross-Framework Compatibility, One-Click Component Library Switch, Fully Enhanced Renderer & Playground

OpenTiny — Wed, 12 Aug 2026 03:15:47 +0000

Preface

GenUI SDK is a solution built by the OpenTiny team based on Generative UI concepts, designed to boost display and interactive capabilities of large language models. The SDK delivers integrated front-end & back-end capabilities fully compliant with OpenAI specifications, with built-in Vue and Angular renderers. It supports custom component libraries, interactive behaviors and theme styles. Developers can build AI chat applications from scratch rapidly, or embed Generative UI capabilities into existing business systems.

We are thrilled to announce the official launch of GenUI SDK v1.3.0. This version iterates around five core directions: decoupled core packages, pluggable material systems, enhanced renderer capabilities, cross-frame collaborative rendering, and comprehensive Playground upgrades. It thoroughly resolves pain points such as tight coupling, weak framework compatibility and limited custom extensibility in earlier releases, making the SDK more flexible, stable and better suited for enterprise intelligent implementation scenarios.

Open Source Repository: https://github.com/opentiny/genui-sdk (Star ⭐ appreciated!)
Official Website: https://opentiny.design/genui-sdk

Version Feature Overview

📦 Independent Core Packages & Pluggable Material System

Standalone core package: @opentiny/genui-sdk-core published to npm. Low-level core utilities including protocol definitions, prompt generation, streaming Schema parsing, Delta incremental patches and JSON repair can be imported independently for custom Agents and server pipelines.
Fully decoupled materials: UI materials are completely separated from renderers. Multiple independently publishable material packages are released, supporting one-click switching between OpenTiny and Element Plus component libraries.
Smooth legacy compatibility: Legacy components are provided for both Vue and Angular, enabling incremental upgrades without massive refactoring of old projects.

⚡ Renderer Capability Enhancements

Auto-fill default props: Unified automatic default value injection for Vue and Angular, acting as fallback for streaming rendering.
New refs support: Schema can define refs to directly call component instance methods (e.g. form validation) within methods and event handlers.
Enhanced custom Actions: Custom interactive Actions support asynchronous execution and transparent return value passing for flexible complex dialogue workflow orchestration.
New lifecycle hooks: onMounted and onUnmounted added to the renderer protocol.

🚀 Cross-Framework Renderer & Full Playground Upgrades

One-click switch between Vue and Angular in Playground; mixed framework cards supported within the same chat session.
A2A v1.0 protocol supported, with automatic fallback to older versions for incompatible external Agents.
One-click conversion of OpenAPI docs into reusable chat tools.
Template mode with Schema editing, version history viewing and built-in version control.
Optional Mini / Standard prompt versions for Vue stacks.
Chinese & English bilingual UI with persistent language preference memory.

🛡️ Experience & Stability Improvements

Bug fixes for notification payload rendering, plain Markdown display, JSON patch logic and more.
Image content types aligned with OpenAI specifications.
Clearer prompt rules for API parameter formatting.

🧪 Early Access Preview

Beta React renderer released for early testing.

Detailed New Feature Breakdown

1. Independent Core Package for Reusable Low-Level Capabilities

In previous versions, all core logic was tightly coupled inside the main SDK bundle, restricting custom development. v1.3.0 fully extracts underlying logic into the standalone @opentiny/genui-sdk-core package, exposing a complete set of core modules:

Standardized protocol type definitions
Intelligent prompt generation logic
Real-time streaming Schema extraction for LLMs
Front-end Delta incremental rendering patches
Automatic JSON repair for AI outputs

Developers can utilize core logic separately on servers, custom Agents and AI pipelines without relying on renderers. For example, generate system prompts by combining core utilities and material metadata:

import { genPrompt } from '@opentiny/genui-sdk-core'
import { materialsMeta } from '@opentiny/genui-sdk-materials-vue-element-plus/meta'

const systemPrompt = genPrompt('Vue', materialsMeta, {
  customActions: [
    {
      name: 'submitForm',
      description: 'Submit form data',
      async: true,
      return: { type: 'boolean' }
    }
  ]
})

Full signature of genPrompt:
genPrompt(framework, materialsMeta, customConfig?, options?)

The framework parameter accepts string literals ('Vue' / 'Angular') or custom framework configurations for extended support.
customConfig supports injection of custom components, code snippets and custom Actions.

Refer to the Core library documentation for full usage details.

2. Pluggable Material Architecture: One-Click Switch Between Component Libraries

v1.3.0 completely decouples renderers from UI materials. GenuiChat and GenuiRenderer no longer ship with built-in fixed components. All material sets are injected uniformly via GenuiConfigProvider, realizing a single rendering engine with interchangeable UI material packages.

Three official material packages are available now:

Sample integration for Element Plus:

import 'element-plus/dist/index.css'
import { GenuiConfigProvider, GenuiChat } from '@opentiny/genui-sdk-vue'
import { materials } from '@opentiny/genui-sdk-materials-vue-element-plus/materials'

<GenuiConfigProvider :materials="materials">
  <GenuiChat />
</GenuiConfigProvider>

Legacy compatible components are provided for incremental migration of existing projects without full refactoring:

import {
  GenuiLegacyRenderer as GenuiConfigProvider,
  GenuiLegacyChat as GenuiChat
} from '@opentiny/genui-sdk-vue'

3. New Chart Components

@opentiny/genui-sdk-materials-vue-opentiny-vue has upgraded its chart suite with multiple new chart types, enabling richer UI layouts. Legacy components also receive matching chart upgrades:

Funnel Chart

Scatter Chart
Waterfall Chart

Topology Graph

Gauge Chart

4. Major Renderer Capability Upgrades

Four key renderer enhancements are delivered to support complex business workflows: default props auto-fill, refs binding, asynchronous custom Actions and lifecycle hooks.

(1) Auto-Fill Default Props for Streaming Render Fallback

Many legacy component libraries were not designed for streaming LLM output. When generating Schema incrementally, required props such as options for Select components may be missing, triggering runtime errors.

v1.3.0 builds a defaultPropsMap from material metadata to automatically inject fallback values without overriding user-defined props. Developers can customize baseline defaults (e.g. all buttons default to primary type). LLMs only need to output differentiated configuration instead of full property sets.

(2) Refs + Asynchronous Actions for Frontend & Backend Form Validation

Two new optional fields are added to custom Action definitions:

return: JSON Schema defining return value format (omitted for void actions)
async: If set to true, the execute function returns a Promise; this.callAction() also returns a Promise, enabling await / .then() workflow orchestration for LLMs.

Sample custom Action for duplicate username backend validation:

const customActions = {
  checkUsernameDuplicate: {
    name: 'checkUsernameDuplicate',
    description: 'Call backend API to verify whether the username exists',
    async: true,
    parameters: {
      type: 'object',
      properties: {
        username: { type: 'string', description: 'Username to validate' }
      },
      required: ['username']
    },
    return: {
      type: 'object',
      properties: {
        valid: { type: 'boolean', description: 'True if username is available' },
        message: { type: 'string', description: Validation feedback text }
      },
      required: ['valid', 'message']
    },
    execute: async (params: { username: string }) => {
      const res = await fetch(`/api/user/check-username?username=${encodeURIComponent(params.username)}`)
      const data = await res.json()
      if (data.exists) {
        return { valid: false, message: 'This username is already taken' }
      }
      return { valid: true, message: 'Username available' }
    }
  }
}

refs can be declared on root Schema nodes and bound to component instances via the ref prop. Instance native APIs such as form validation can be called directly within events and custom JS methods.

Full registration example for a registration form combining frontend form validation and backend duplicate checking:

{
  "componentName": "Page",
  "state": {
    "formData": {
      "username": "",
      "password": ""
    }
  },
  "refs": {
    "formRef": null
  },
  "methods": {
    "validateForm": {
      "type": "JSFunction",
      "value": "function() { return this.refs.formRef.validate(); }"
    },
    "checkUsername": {
      "type": "JSFunction",
      "value": "async function() { return this.callAction('checkUsernameDuplicate', { username: this.state.formData }); }"
    },
    "handleSubmit": {
      "type": "JSFunction",
      "value": "async function() { try { const formValid = await this.methods.validateForm(); if (!formValid) return; const result = await this.methods.checkUsername(); if (!result.valid) { console.log(result.message); return; } this.callAction('continueChat', { message: 'Registration succeeded, username: ' + this.state.formData.username }); } catch (e) {} }"
    }
  },
  "children": [
    {
      "componentName": "TinyForm",
      "props": {
        "model": { "type": "JSExpression", "value": "this.state.formData" },
        "ref": { "type": "JSExpression", "value": "this.refs.formRef" },
        "rules": {
          "username": [
            { "required": true, "message": "Please enter username" },
            { "min": 6, "message": "Username must be longer than 5 characters" }
          ],
          "password": [
            { "required": true, "message": "Please enter password" },
            { "min": 6, "message": "Password must be longer than 5 characters" }
          ]
        }
      },
      "children": [
        {
          "componentName": "TinyFormItem",
          "props": { "label": "Username", "prop": "username" },
          "children": [
            {
              "componentName": "TinyInput",
              "props": {
                "placeholder": "Enter username",
                "modelValue": { "type": "JSExpression", "model": true, "value": "this.state.formData.username" }
              }
            }
          ]
        },
        {
          "componentName": "TinyFormItem",
          "props": { "label": "Password", "prop": "password" },
          "children": [
            {
              "componentName": "TinyInput",
              "props": {
                "type": "password",
                "placeholder": "Enter password",
                "modelValue": { "type": "JSExpression", "model": true, "value": "this.state.formData.password" }
              }
            }
          ]
        },
        {
          "componentName": "TinyFormItem",
          "children": [
            {
              "componentName": "TinyButton",
              "props": {
                "type": "primary",
                "text": "Register",
                "onClick": { "type": "JSFunction", "value": "function() { this.methods.handleSubmit(); }" }
            }
          ]
        }
      ]
    }
  ]
}

(3) Lifecycle Hooks for Business Data Loading

Two new lifecycle hooks onMounted and onUnmounted are added to the renderer protocol to enable AI-generated pages to actively request backend data.
Streamed Schema chunks render incrementally, but lifecycle logic only executes once after the full Schema payload is received.

onMounted: Trigger page initialization logic such as data fetching
onUnmounted: Clean up requests and event listeners to prevent memory leaks

Sample table page loading employee data on mount:

{
  "componentName": "Page",
  "state": { "tableData": [] },
  "methods": {
    "loadTableData": {
      "type": "JSFunction",
      "value": "async function() { const result = await this.callAction('fetchEmployeeList'); this.state.tableData = result.data; }"
    }
  },
  "lifeCycles": {
    "onMounted": {
      "type": "JSFunction",
      "value": "function() { this.methods.loadTableData(); }"
    }
  },
  "children": [
    {
      "componentName": "TinyGrid",
      "props": {
        "data": { "type": "JSExpression", "value": "this.state.tableData" },
        "columns": [
          { "type": "index", "width": 60 },
          { "field": "name", "title": "Name" },
          { "field": "id", "title": "Employee ID" },
          { "field": "department", "title": "Department" }
        ]
      }
    }
  ]
}

5. Comprehensive Playground Upgrades

Following Skill and A2A support in v1.2.0, v1.30 optimizes the overall Playground user experience with multiple major features:

(1) Cross-Framework One-Click Switch & Mixed Sessions

The unified base engine supports both Vue and Angular without forced stack selection.

One-click framework toggle, with prompt generation and rendering engine auto-adaptation. Framework preference persists across sessions.
Mixed framework cards supported within a single chat session for side-by-side comparison of UI and code output.

(2) A2A v1.0 Protocol Support

Playground fully implements the official A2A v1.0 standard, enabling standardized communication between Agents and applications.

External third-party Agents can be registered as reusable tools to assemble multi-AI workflows.
Built-in version fallback logic: Automatically downgrade protocol compatibility if external Agents run older A2A versions without manual conditional logic.

Sample external Agent link for specification Q&A:
https://specification.website/.well-known/agent-card.json

(3) OpenAPI to Tool Conversion

Native OpenAPI parser integrated into Playground. Three import modes supported: input document URL, paste raw content or upload local files.
All defined APIs are auto-converted into callable chat tools with one click. Custom request headers and service base URLs can be configured for authentication, eliminating backend refactoring requirements to integrate business systems into AI chat workflows.

(4) Template Version Control

Template mode supports inline Schema editing and real-time previews. New version history feature:

Auto-save each Schema iteration as a separate version card
Visual diff comparison between revisions
One-click rollback to historical templates Simplifies debugging, cross-team scheme comparison and version traceability.

(5) Optional Vue Prompt Versions

Two prompt suites available for Vue development:

Mini: Lightweight, only includes core form & table components to cut token consumption

Standard: Adds full chart component support for data visualization scenarios

(6) Bilingual Internationalization

Playground UI supports Chinese / English switch via bottom-left control. Language preferences are automatically saved and restored for new sessions.

Beta React Renderer Release

The official alpha React renderer is launched, paired with Ant Design material packages:

Core package: @opentiny/genui-sdk-react@1.3.0-alpha.1
Material package: @opentiny/genui-sdk-materials-react-antd@1.3.0-alpha.1

Prompt Generation Sample

import { genPrompt } from '@opentiny/genui-sdk-core'
import { materialsMeta } from '@opentiny/genui-sdk-materials-react-antd/meta'
const systemPrompt = genPrompt('React', materialsMeta)

Component Usage Sample

import { useState } from 'react'
import { GenuiConfigProvider, GenuiRenderer } from '@opentiny/genui-sdk-react'

function App() {
  const [schema, setSchema] = useState('')
  return (
    <GenuiConfigProvider materials={materials}>
      <GenuiRenderer key={rendererKey} content={schema} />
    </GenuiConfigProvider>
  )
}

Other Stability Fixes & Optimizations

Optimized plain Markdown fallback rendering for pages without UI components
Hardened JSON Patch incremental rendering logic, standardized component ID allocation to avoid layout corruption
Image schema formats fully aligned with OpenAI standards for universal LLM compatibility
Stricter prompt parameter validation rules to reduce invalid model outputs
Fixed runtime errors when refs returns empty objects during streaming rendering

Version Summary

GenUI SDK v1.3.0 is a major architectural overhaul combining decoupling, capability expansion and UX upgrades:

Core independent packages + pluggable material architecture drastically improve SDK extensibility
Renderer layer optimizations resolve critical production pain points for streaming and complex interactive UIs
Playground upgrades lower development barriers, with forward-looking support for React and A2A v1.0 to fully meet enterprise intelligent transformation demands

All developers are welcome to upgrade and test. Submit bugs or feature requests via GitHub Issues, and star the repository to support open-source collaboration!
Full release notes: v1.3.0 Release Page

About OpenTiny NEXT

OpenTiny NEXT is an enterprise intelligent front-end solution built on Generative UI and WebMCP core technologies. It delivers intelligent upgrades for legacy products including the TinyVue component library and TinyEngine low-code engine, while launching Agent-native products such as front-end NEXT-SDKs, AI Extension, TinyRobot AI Assistant and GenUI. It enables AI to interpret user intentions and complete tasks autonomously, accelerating enterprise intelligent transformation.

Join the OpenTiny Open Source Community

WeChat Assistant: opentiny-official

Official Website: https://opentiny.design
GenUI SDK Repository: https://github.com/opentiny/genui-sdk (Star ⭐ appreciated)

To contribute, locate issues tagged good first issue in the repository. Feel free to share questions and feedback in comment sections!

Bloat-Free Extensibility: The Evolution of TinyRobot — From a Simple AI Input Box to a Fully-Featured AI Input Console

OpenTiny — Fri, 31 Jul 2026 07:47:11 +0000

Introduction

At the very beginning of AI chat development, an input box plus a send button was all you needed. But as AI capabilities expanded to support file uploads, voice input, LLM switching, web search, deep reasoning and more, the bottom input area gradually turned into an all-in-one AI console.

This article uses TinyRobot’s Sender component as an example. We break down how the component’s scope expanded alongside evolving business requirements, and discuss architectural improvements that boost component flexibility and adaptability.

I. Sender Component Bloats As Requirements Pile Up

Stage 1: Minimalist Basic AI Input Box

In early project phases, requirements were simple — only core chat functionality was needed:

Type messages and send with one click
Interrupt AI output mid-generation
Clear input content in one tap, with maximum character limit to avoid overly long text

Minimal sample code (size & debug configurations omitted):

<TrSender
  v-model="message"
  placeholder="Send a message to AI..."
  :loading="loading"
  clearable
  show-word-limit
  :max-length="2000"
  @submit="sendMessage"
  @cancel="stopGeneration"
/>

At this stage, the Sender only handled text input, character counting, and content clearing. The send button automatically switches to a stop button when the AI streams responses — nothing more.

Stage 2: Feature Explosion — Input Box Becomes AI Console

As business iteration accelerated, plain text chat was no longer sufficient. A full suite of auxiliary capabilities was added:

File & image upload with preview (TrUploadButton, TrAttachments)
Voice-to-text input (TrVoiceButton)
Dynamic LLM model switching (ModelSelector)
One-click deep reasoning mode (DeepThinking)
Real-time web search for up-to-date information (WebSearch)

All features are embedded via component slots. Key code snippet extracted from live demos:

<!-- Core TinyRobot Sender Component -->
<TrSender
  v-model="message"
  mode="multiple"
  :has-external-content="attachments.length > 0"
>
  <!-- Top Slot: Attachment Display -->
  <template #header v-if="attachments.length">
    <TrAttachments v-model:items="attachments" :actions="[]" variant="card" wrap />
  </template>

  <!-- Bottom Left Slot: Model & Feature Toggles -->
  <template #footer>
    <ModelSelector v-model="model" />
    <DeepThinking />
    <WebSearch />
  </template>

  <!-- Bottom Right Slot: Upload & Voice Buttons -->
  <template #footer-right>
    <TrUploadButton @select="addFiles" />
    <TrVoiceButton />
  </template>
</TrSender>

While features were split into standalone sub-components embedded via slots (to avoid bloated props lists and enable reuse across pages), critical limitations remained:

Fixed slot positions: Upload/voice buttons cannot be rearranged; DOM hierarchy is locked inside the Sender.
Manual state sync: Developers must manually pass the has-external-content flag to notify the Sender of attachments.
Constant API expansion: New features require new slots and props as functionality grows.

In short: Although TinyRobot split discrete sub-components, the overall page layout and element positions remained controlled by the Sender, limiting full customization for business scenarios.

Stage 3: Severe UI Divergence Between PC & Mobile

Desktop screens have ample space to display all buttons in full text, while mobile interfaces demand compact, condensed layouts:

PC: Full text buttons for model selection, reasoning and search; upload/voice buttons fully visible
Mobile: Only icons for core features; attachments hidden inside an expandable menu; tap microphone to switch to full-screen long-press voice input, tap keyboard icon to revert to text typing

This forced heavy conditional logic with repeated isMobile checks:

<TrSender v-model="message" mode="multiple">
  <!-- Replace text input with voice panel on mobile -->
  <template #content v-if="isMobile && voiceMode">
    <VoiceHoldButton />
  </template>

  <!-- Differentiated Footer Toolbar for PC/Mobile -->
  <template #footer>
    <template v-if="isMobile">
      <MoreActions>
        <TrUploadButton @select="addFiles" />
      </MoreActions>
      <ModelSelector v-model="model" compact />
      <DeepThinking icon-only />
      <WebSearch icon-only />
    </template>
    <template v-else>
      <ModelSelector v-model="model" />
      <DeepThinking />
      <WebSearch />
    </template>
  </template>

  <!-- Right-Side Action Bar Split by Device -->
  <template #footer-right>
    <template v-if="isMobile">
      <InputModeToggle :mode="voiceMode ? 'keyboard' : 'voice'" @click="voiceMode = !voiceMode" />
    </template>
    <template v-else>
      <TrUploadButton @select="addFiles" />
      <TrVoiceButton />
    </template>
  </template>
</TrSender>

Summary of Early Pain Points

Stage 2 already introduced rigid UI structures and tedious manual state synchronization. Mobile adaptation in Stage 3 amplified these issues, resulting in bloated, hard-to-maintain conditional code. Three core problems needed a fundamental refactor:

Share unified state & logic across PC/mobile without duplicate input/submit implementations
Auto-detect attachments and external content without manual boolean flags
Avoid continuous additions of props/slots when supporting new features or device types

The following sections detail architectural refactors that resolve these three core limitations.

II. Separate Logic & Layout: Shared Core Capabilities, Independent Terminal UI

The original Sender tightly coupled state, interaction logic and DOM layout. The key improvement decouples them:

SenderRoot: Acts as the core capability container, solely responsible for input, submission, loading and underlying logic
Layout structure, button positioning and visual design are fully controlled by business developers

PC and mobile share identical core functionality (text input, message submission, stream interruption, attachment management, model switching, reasoning/search toggles, text/voice toggle) — the only difference is layout arrangement due to screen size constraints.

Desktop Layout (Sufficient Screen Space, All Buttons Fully Visible)

<SenderRoot v-model="message" @submit="submit">
  <SenderAttachments v-model:items="attachments" />
  <SenderEditor />
  <footer class="desktop-toolbar">
    <ModelSelector v-model="model" />
    <DeepThinking />
    <WebSearch />
    <div class="desktop-actions">
      <SenderUploadButton @select="addFiles" />
      <SenderVoiceButton />
      <SenderSubmit />
    </div>
  </footer>
</SenderRoot>

Mobile Layout (Compact Space, Foldable Low-Frequency Features)

<SenderRoot v-model="message" @submit="submit">
  <SenderAttachments v-model:items />
  <!-- Toggle between text editor and voice long-press panel -->
  <SenderEditor v-if="inputMode === 'text'" />
  <VoiceHoldButton v-else />

  <footer class="mobile-toolbar">
    <MoreActionsTrigger />
    <ModelSelector v-model="model" compact />
    <DeepThinking icon-only />
    <WebSearch icon-only />
    <InputModeToggle />
    <SenderSubmit />
  </footer>

  <!-- Expandable upload menu -->
  <MoreActions v-if="moreActionsOpen">
    <SenderUploadButton @select="addFiles" />
  </MoreActions>
</SenderRoot>

Cross-Device Implementation

For documentation demonstration, both layouts can coexist with device detection logic; in production, render only the matching layout inside SenderRoot:

<SenderRoot v-model="message" :loading="loading" @submit="submit">
  <template v-if="isDesktop">
    <!-- Full desktop layout code above -->
  </template>
  <template v-else>
    <!-- Compact mobile layout code above -->
  </template>
</SenderRoot>

Switching devices only swaps DOM markup — message text, attachments, selected LLM and loading state remain unchanged and will not reset. Temporary UI states (panel expansion) reset when components unmount.

Key advantage: No new props or slots required for multi-terminal support; identical underlying logic with fully customizable layout arrangements.

Intermediate Summary

This composable architecture resolves two original pain points:

Reuse identical state & logic across PC/mobile with fully customizable layouts
No breaking API changes or new slots when adapting to new devices

However, a new issue emerged: If PC/mobile layouts are extracted into standalone components, attachment and model state must be passed down layer by layer, leading to bloated props lists again. Further decoupling via Context is required.

III. Decouple via Layered Context: Eliminate Prop Drilling

While separate desktop/mobile layouts clean up code, extracting them into independent DesktopSenderLayout and MobileSenderLayout introduces heavy prop drilling for attachments, selected models and disabled states:

<SenderRoot v-model="message" :loading="loading" @submit="submit">
  <DesktopSenderLayout
    v-if="isDesktop"
    v-model:attachments="attachments"
    v-model:model="model"
    :disabled="disabled"
  />
  <MobileSenderLayout
    v-else
    v-model:attachments="attachments"
    v-model:model="model"
    :disabled="disabled"
  />
</SenderRoot>

As features expand, the layout components accumulate dozens of props. The solution splits state into two Context layers: universal core capabilities and domain-specific business data, shared across all child components without prop drilling.

Layer 1: Global Sender Context for Universal Core Logic

SenderRoot injects a global context exposing core chat functionality (text binding, loading, submission, clearing, stream cancellation) accessible to all descendant components:

// Inside SenderRoot
provide(senderContextKey, {
  message,
  loading,
  disabled,
  maxLength,
  canSubmit,
  clear,
  submit,
  cancel,
})

The SenderEditor input component no longer requires bound values passed from parents; it directly consumes the context for text binding, keyboard submission and line break logic:

// Inside SenderEditor
const { message, disabled, maxLength, submit } = useSenderContext()

const handleInput = (event: Event) => {
  message.value = (event.target as HTMLTextAreaElement).value
}

const handleKeydown = (event: KeyboardEvent) => {
  if (event.key !== 'Enter' || event.shiftKey || event.isComposing) return
  event.preventDefault()
  submit()
}

SenderEditor can be placed anywhere inside the SenderRoot DOM tree, with no fixed slot constraints. Only presentation-specific props such as placeholder remain. Layout components no longer need to forward core state, eliminating massive prop lists. Model selection and reasoning toggles remain business logic and are not injected into the global context to avoid bloating SenderRoot.

Layer 2: Domain-specific Context, Independent Closed-loop Management of Attachment States

The SenderRoot Context eliminates the transparent transmission of common capabilities such as input, loading, and submission, but attachments still need to be shared between the upload button, the attachment list, and the two Layouts. If external Refs are still used, each Layout would need to receive the same attachment Props and events:

This is because SenderAttachments is the consumer of the attachments, while SenderUploadButton is the producer of the attachments. When they are used as sibling nodes, the business logic needs to connect them using Refs and events.

The attachmentsRef and addFiles in this context actually belong to the attachment domain. Currently, they are held by the business layer solely to connect the producers and consumers of attachments. If each business logic repeatedly writes this layer of wiring, composable components still do not encapsulate a complete collaborative attachment capability.

Therefore, a SenderAttachmentProvider can be introduced. It uniformly holds the attachment state and operation methods and provides them to descendant components through the Context. The Provider is placed on the smallest common ancestor of the producer and consumer, establishing only the data scope without dictating their DOM positions.

<SenderRoot v-model="message" @submit="submit">
  <SenderAttachmentProvider>
    <SenderAttachments />
    <SenderEditor />
    <footer>
      <SenderUploadButton />
      <SenderSubmit />
    </footer>
  </SenderAttachmentProvider>
</SenderRoot>

Attachment context interface:

interface SenderAttachmentContext {
  items: Ref<Attachment[]>
  addFiles: (files: File[]) => void
  remove: (id: string) => void
  clear: () => void
}

Upload buttons call addFiles to append files
Attachment lists read items and trigger remove for deletion
All attachment state logic is encapsulated within the provider, no manual state sync required for business code

Unified Submission Registry Protocol

Early designs required manual has-external-content boolean flags to notify the Sender of attachments. We introduced a content registration protocol where all external data sources self-register to SenderRoot:

interface SenderContentRegistry {
  registerContent<T>(source: string, payload: MaybeRefOrGetter<T>): () => void
}

source: Data type identifier (attachments, knowledge base, etc.)
payload: Complete structured data
Return: Cleanup function auto-unregistered when components unmount

The attachment provider automatically registers attachment data:

const unregister = registerContent('attachments', items)

On submission, the submit event returns all registered external data alongside text content in one payload:

const submit = ({ text, contents }: SenderSubmission) => {
  const attachments = contents.find(({ source }) => source === 'attachments')?.payload
}

This fully resolves the three original core challenges:

Unified state & logic reused across PC/mobile with fully customizable layouts
Attachments auto-included in submission logic without manual boolean flags
New data types only require new source identifiers, no breaking changes to Sender APIs

Final clean layout code after layered context refactor:

<SenderRoot v-model="message" :loading="loading" @submit="submit">
  <SenderAttachmentProvider>
    <DesktopSenderLayout v-if="isDesktop" />
    <MobileSenderLayout v-else />
  </SenderAttachmentProvider>
</SenderRoot>

Model selection and other business modules can still pass props directly when appropriate. General rule: Share data across multiple components via dedicated Provider; independent simple components use direct props. State ownership belongs to the nearest common ancestor of all consuming components.

IV. Two-Tier API: Balance Flexibility & Development Speed

The fully composable atomic architecture delivers maximum layout freedom, but requires assembling dozens of components for simple use cases — similar to headless UI design patterns (e.g. shadcn/ui). TinyRobot implements a dual-layer API system:

Low-Level Composable Atomic Components: SenderRoot, SenderEditor, SenderAttachments etc. For deeply customized, highly differentiated multi-terminal scenarios with full layout control.
High-Level Wrapped Preset Component: The original Sender component with built-in standard layouts for rapid out-of-box development.

Both layers share identical underlying core logic with no separate codebases. Simple projects use the wrapped component for fast integration; complex cross-terminal projects can drop down to atomic building blocks for unlimited customization.

Core principle: Preset components accelerate rapid development, while composable atomic components enable unlimited structural modification.

About OpenTiny NEXT

OpenTiny NEXT is an enterprise-grade intelligent frontend solution built on Generative UI and WebMCP core technologies. It delivers intelligent upgrades for legacy products including the TinyVue component library and TinyEngine low-code engine, while launching Agent-native products such as frontend NEXT-SDKs, AI Extension, TinyRobot AI Assistant and GenUI. The platform enables AI to interpret user intentions and complete tasks autonomously, accelerating enterprise intelligent transformation.

Join the OpenTiny Open Source Community

WeChat Assistant: opentiny-official

TinyRobot Official Website: https://opentiny.design/tiny-robot
TinyRobot GitHub Repository: https://github.com/opentiny/tiny-robot

If you wish to contribute, look for issues tagged good first issue within the repository. Feel free to leave comments with any questions or feedback!

TinyRobot v0.5.0 Released: Brand-New Capabilities Including Agent Skills, Navigation & Custom Layouts Launched Simultaneously

OpenTiny — Tue, 21 Jul 2026 07:48:33 +0000

Preface

TinyRobot is a front-end interaction framework exclusively built for AI applications. It empowers teams to rapidly build enterprise AI assistants, intelligent customer service platforms and multi-turn dialogue systems. Built on the OpenTiny design system, Tiny delivers full capabilities covering dialogue UI, streaming rendering and session management. Developers can build consistent, extensible AI products without developing complex interaction logic from scratch — functional AI applications can be finished within hours from initial prototypes.

We are proud to announce the official release of TinyRobot v0.5.0. This release is far more than just a handful of new components; it drastically simplifies the entire workflow of building AI chat applications.

Open Source Repository: https://github.com/opentiny/tiny-robot (Star ⭐ appreciated!)
Official Website: https://opentiny.design/tiny-robot

Feel free to test this version. If you have suggestions, ideas or issues during usage, submit feedback via GitHub Issues, PRs or discussion threads to help us refine TinyRobot together.

v0.5.0 Feature Overview

[New Feature] Agent Skills support added
[New Component] Anchor: content navigation component for lengthy answers & dialogues
[New Component] Layout: layout component supporting standard & floating modes
[New Tool] CLI scaffolding: spin up a TinyRobot project with one single command
Miscellaneous interaction refinements & bug fixes

In-Depth Breakdown of TinyRobot v0.5.0 New Features

1. New Feature: Agent Skills Support

Agent Skills is a lightweight, open format designed to extend AI Agent capabilities via professional domain knowledge and standardized workflows. Each Skill is a directory containing a SKILL.md file, which records skill name, description and task specifications. The directory may also attach reference documents and template files.

Within TinyRobot Kit, Skills from different sources are normalized into unified SkillDefinition objects. Applications can activate appropriate Skills based on current scenarios, guiding LLMs to follow defined rules when answering questions or executing tasks. Teams can isolate business logic and task requirements as reusable Skills across multiple projects and chat scenarios.

When a Skill is enabled for a conversation, skillPlugin parses the target Skill and generates corresponding instruction prompts and runtime tools. The plugin does not hardcode how instructions are passed to LLMs; developers can inject instructions into system messages, user messages or dedicated request fields based on the LLM provider’s protocol. If a Skill includes reference files, the model can fetch file content on demand via built-in runtime tools.

Example: `vue-best-practices` Skill

After enabling this Skill on the frontend, users can ask Vue development questions, and the LLM will strictly follow standardized Vue specifications. When users need deeper details about reactivity, single-file components or component data flow, the model can retrieve attached reference materials from the Skill directory.

1.1 Load Skills From Multiple Sources

TinyRobot Kit supports loading Skills from browser local files, Node.js file systems and GitHub repositories. Developers can let users select local Skill folders on the page, load preconfigured Skill directories from the server, or directly use centrally maintained repository Skills.
All Skill sources will be normalized into identical definition structures after loading, so the chat workflow logic does not need to distinguish their original origins. This design fits both quick local testing and centralized team version control via code repositories.

1.2 Persist & Reuse Skills

TinyRobot provides multiple storage adapters for different runtime environments:

Memory Storage: for temporary preview and testing
IndexedDB Storage: persist user-imported Skills across browser sessions
File System Storage: for Node.js services and projects with local directory structures

Applications can import and save Skills first, then load them by name for subsequent chat sessions. Skill persistence status is decoupled from UI toggle states — developers can implement custom interaction controls such as checkboxes or dropdowns to activate Skills freely.

1.3 Integrate Skills Into Chat Workflows

In chat scenarios, applications can either activate user-selected Skills directly, or pass candidate Skills to the LLM for automatic matching based on user queries. Once matching Skills are confirmed, skillPlugin generates standardized instructions. If the Skill contains attached documents, runtime tools like list_skill_files and read_skill_file will be exposed, and toolPlugin collects & executes all tool calls returned by the model.

Vue applications can integrate this capability through skillPlugin. Active Skill configurations update with UI state in real time. There is no need to recreate entire chat instances every time users switch Skills.

Skills are not merely a set of low-level APIs — they introduce a standardized organizational paradigm for chat applications. Task logic, reference materials and execution rules can be decoupled from page code and reused across multiple projects.

2. New Component: Anchor — Navigation For Long Content

The new Anchor anchor component generates table-of-contents navigation for lengthy articles, long dialogue threads and content-heavy pages, supporting quick jumps, scroll-based highlighting and directory search to help users locate target information instantly.

2.1 Generate Table of Contents

Integrating Anchor is straightforward: define directory items and map them to corresponding page content blocks, and the component will automatically organize all long content into a navigable sidebar directory.
This component works seamlessly for both article pages and chat interfaces with segmented content.

2.2 Jump & Scroll Highlight

Users can click directory items to scroll directly to matching content blocks. The active directory entry will automatically highlight as users scroll the page.
After jumping to a section, the target content will flash a temporary highlight for better visibility, delivering a smoother reading experience for long-form content.

2.3 Search & Collapse Controls

When directory lists grow lengthy, users can filter entries via built-in search functionality to quickly locate target sections.
The directory panel supports expand/collapse toggles and left/right docking modes. It can function as a lightweight persistent sidebar or a temporary auxiliary navigation panel, compatible with all mainstream page layouts.

Anchor encapsulates directory generation, fast jumping, scroll tracking and keyword search into a unified navigation solution, drastically improving readability for long content pages.

3. New Component: Layout — Standard & Floating Layout Modes

The Layout component provides standardized page structures, collapsible sidebars and floating workspace containers, ideal for chat interfaces, dashboards and complex editing pages. Complex pages with multi-region interaction (navigation, main content, auxiliary info, temporary panels) often suffer fragmented layout logic without unified layout management, which Layout solves thoroughly.

3.1 Build Standard Page Structures

Layout provides standardized area slots: left-aside, header, main, footer, right-aside. Developers can quickly assemble fully structured pages for admin backends, editors and chat platforms with stable, consistent layout logic.

3.2 Unified Sidebar Interactions

Layout supports two sidebar modes:

dock: permanent sidebar integrated into the page layout for persistent navigation & info panels
drawer: overlay floating sidebar for temporary functional panels

Sidebars support collapse states and resizable width via drag-and-drop. All common sidebar interaction patterns are encapsulated to unify page layout and state management.

3.3 Floating Workspace Extension

Layout can switch to floating mode to create draggable, resizable panels outside the normal document flow. Floating panels retain complete layout slot support (header, main, left/right sidebars) for independent task workspaces.

Layout unifies standard page structures, sidebar interactions and floating workspaces under a single component, turning disjoint page blocks into organized, coordinated workspaces for complex business scenarios.

4. New Tool: CLI Scaffolding — One Command To Generate TinyRobot Projects

TinyRobot CLI provides two streamlined workflows:

basic: spin up a complete standalone project from scratch
add chat: incrementally inject chat components into existing Vue projects

4.1 Create Full Project With `create` Command

Run the CLI to generate a complete template project:

# npm
npx @opentiny/tiny-robot-cli create
# pnpm
pnpm dlx @opentiny/tiny-robot-cli create

Follow terminal prompts to install dependencies and launch the development server.

LLM Key Configuration
The basic template comes pre-configured with DeepSeek and Alibaba DashScope integrations. Copy .env.example to .env and fill in your API keys:

# Alibaba DashScope API Key (required for partial MCP plugins)
VITE_ALIYUN_DASHSCOPE_KEY=
# DeepSeek API Key
VITE_DEEPSEEK_API_KEY=

3 built-in MCP plugins are included: 12306 Ticket Query (Alibaba DashScope), Amap Maps, generic MCP demo. DashScope plugins require the corresponding environment variable.
Visit http://localhost:5173 in your browser to preview the full AI chat application.

4.2 Inject Chat Components Into Existing Projects With `add chat`

Execute the command inside your Vue project root directory:

# npm
npx @opentiny/tiny-robot-cli add chat
# pnpm
pnpm dlx @opentiny/tiny-robot-cli add chat

Follow prompts to complete auto-injection. The generated

TinyRobotChat.vue component can be imported anywhere in your project, e.g. App.vue:

<script setup lang="ts">
import HelloWorld from './components/HelloWorld.vue'
import TinyRobotChat from './TinyRobotChat.vue'
</script>

<template>
  <HelloWorld />
  <TinyRobotChat />
</template>

Add your LLM API key to the .env file:

VITE_DEEPSEEK_API_KEY=

Reinstall dependencies and launch dev server:

pnpm install && pnpm dev

Open http://localhost:5173 to view the embedded AI chat module within your existing project.

5. Miscellaneous Optimizations & Bug Fixes

New Capability Additions

Bubble: unified bubble-event event channel + state-change state sync; support injecting box/content attributes at Provider level
Sender: grapheme-based character counting for accurate Emoji & composite character length calculation
Sender: hasExternalContent prop to factor attachments into send state logic
useMessage: refactored core message engine into adapter architecture, reusable for both Vue and vanilla JS
toolPlugin: aggregate runtime tool providers + tool source tracking for dynamic tool injection based on message context

Optimizations

Reasoning: reasoning bubble expanded by default to reduce user clicks
McpServerPicker: unified style variables for consistent visual design
Attachments / Dropdown / Suggestion: complete dark mode variable coverage, optimized hover & interactive styles
Feedback / Welcome: improved dark theme rendering
Docs & Demo: refined shell layout, navigation, code blocks and dark mode styles
Build: lock Tiptap dependency versions; update Playground IDB import maps
Build: add CSS sideEffects field to ensure styles are retained during bundling
Testing: supplement E2E selectors for Sender; add test coverage for Mention, Suggestion & Template scenarios

Bug Fixes

Layout: stabilize type declarations, simplify slot existence judgment logic
Bubble: fix rendering errors when non-standard APIs return empty reasoning_content
Attachments: resolve attachment list normalization defects, add corresponding test cases
Sender: fix tooltip spacing & rendering anomalies for action buttons; stabilize template deletion test cases
Playground / Docs: fix share link path config; remove hardcoded VitePress brand colors
CI & Workflow: optimize preview comment workflows; exclude CLI template packages from workspace bundling

Summary

The core value of v0.5.0 lies in shortening the development cycle from component integration to production-ready AI products:

Skills: standardized organization of AI task logic & reference resources
CLI: one-click project scaffolding for new & existing Vue projects
Anchor: readable navigation for long dialogue & content
Layout: unified complex page construction

All four upgrades streamline development workflows and deliver fully functional AI chat applications faster.

About OpenTiny NEXT

Join the OpenTiny Open Source Community

WeChat Assistant: opentiny-official

TinyRobot Official Website: https://opentiny.design/tiny-robot
TinyRobot GitHub Repository: https://github.com/opentiny/tiny-robot (Star ⭐ appreciated)

If you wish to contribute, look for issues tagged good first issue in the repository. Feel free to leave comments with any questions or feedback!

TinyEngine v2.11 Released: AI Deeply Integrated Into Canvas, Vue Projects One-Click Convertible to DSL

OpenTiny — Thu, 16 Jul 2026 06:26:17 +0000

Preface

TinyEngine is a forward-looking low-code engine foundation that delivers highly customizable technical infrastructure for developers. It supports core capabilities such as visual page building, and enables in-depth secondary development via CLI engineering workflows. Teams can leverage it to rapidly build proprietary low-code platforms.

TinyEngine flexibly adapts to various scenarios including resource orchestration, server-side rendering, model-driven applications, mobile terminals, large-screen dashboards, and complex page composition, serving as a solid foundation for your low-code system.

We are pleased to announce the official release of TinyEngine v2.11. This version focuses on three major upgrade directions: smarter development experience, smoother asset import, and a more complete component material ecosystem.

Open Source Repository: https://github.com/opentiny/tiny-engine (Star ⭐ appreciated!)
Official Website: https://opentiny.design/tiny-engine

We sincerely thank contributor @zjy2414 for participating in the open-source co-construction of TinyEngine, and invite all developers to join our community to help TinyEngine evolve further.

Release Feature Overview

[New Feature] Support importing Vue projects / single-file components into low-code platform
[New Feature] AI assistant entry added to every canvas node for fast modification
[New Feature] Support mockserver files as local database, plus new dsl-generator skill
[New Feature] Auto-format generated code in preview mode
[Enhancement] Robot plugin upgraded to TinyRobot v0.4.0
[Enhancement] Expanded built-in component library
Miscellaneous minor optimizations & bug fixes

In-Depth Feature Breakdown

1. New Feature: Import Vue Projects / SFCs to Low-Code Platform

A major pain point for teams adopting low-code platforms is reusing existing Vue assets. If legacy pages, components and engineering resources cannot be migrated, the low-code system becomes an isolated silo with high internal promotion costs. The new Vue-to-DSL capability solves exactly this problem.

TinyEngine can parse Vue single-file components, project directories or compressed ZIP packages into TinyEngine DSL schemas, then import them as editable pages, blocks, static assets and data sources for further editing and preview inside the designer.

Supported import workflows:

Import single Vue SFC files
Import full Vue project directories
Import compressed ZIP source packages
Canvas rendering after import, with dedicated panels for i18n, data sources & page states
Live project preview post-import

2. New Feature: Node-Level AI Assistant on Canvas

v2.11 embeds AI capabilities deeper into the visual designer canvas. Every canvas node now has a dedicated AI assistant entry, delivering context-aware development support during page construction. Unlike generic global chat AI, this node-tethered assistant integrates tightly with daily editing workflows to boost page composition efficiency.

Key capabilities:

AI assistant button attached to every canvas component node
Shares identical configuration with the global Robot plugin
Interactive chat workflow: send requests, then choose to apply, discard or restart generated changes

3. New Feature: Mockserver File Database + dsl-generator Skill

File Mode for Mockserver

Mockserver adds a new file startup mode (default local database mode). All mock API data is read and persisted to JSON files under the data/**/ directory.
Usage:

Run pnpm dev:file in project root to launch file-mode mockserver
Create pages & applications, auto-generated JSON data files will appear in the data folder

dsl-generator Project Skill

A project-level skill that enables local AI Agents (Claude Code, Cursor, OpenCode, Codex etc.) to generate page/block/application DSL JSON files inside the data directory, fully compatible with file-mode mockserver.
Usage:

Call the skill via local Agent tools:
- .agents/skills (compatible with Cursor / OpenCode / Codex)
- .claude/skills (soft link pointing to the shared skill directory for Claude Code)
Generate complete pages and application structures directly via AI

4. New Feature: Auto Format Generated Code in Preview Mode

Extended shared AST utilities to support Vue & Less formatting
Auto-select Prettier parsers based on file extensions
All generated scripts, templates and config files are auto-formatted on page/app preview for improved readability

5. Capability Enhancements

TinyRobot Plugin Upgrade

The built-in Robot plugin has been migrated to TinyRobot v0.4.0. Stable AI functionality requires robust underlying plugin infrastructure rather than superficial UI wrappers; this upgrade solidifies TinyEngine’s foundation for AI assistant and intelligent interaction features.

Expanded Component Materials

v2.11 adds a full suite of new built-in components and matching icons:
action-menu, alert, link, divider, anchor, drawer, container, file-upload
Plus full support for dropdown and other frequently used UI components.

6. Minor Optimizations & Bug Fixes

Fixed failure to save event names with onUpdate prefix
Serialize page_content to resolve page creation errors in mockserver
Fixed blank rendering for certain chart previews
Added feature toggle for structured CSS output
Optimized styling & icon replacement for model, resource and AI dialog panels
Updated unit test templates for auto-generated code
Added mock data management tools for models
Fixed error prompts when creating identical pages across different apps
Removed workflow-level environment variable blocks that exposed secret keys
Updated data source config to support saving APIs without request parameters
Resolved message rendering & file upload interaction bugs in Robot plugin, with supplementary test cases

Documentation Updates

Added docs for code generation commands
Deployment workflow now supports custom backend URL configuration

Closing Remarks

TinyEngine v2.11 delivers major upgrades across the board: canvas-native AI assistance, bidirectional Vue-to-DSL project migration, expanded component ecosystem and improved local debugging workflows. It makes low-code platform development smarter, more open, and better aligned with real-world engineering pipelines.

This release stands as a milestone built by collective open-source community contributions. Open source thrives not only on shared code, but also idea exchange and collaborative creation — every user’s feedback and commit shapes TinyEngine’s maturity in real business scenarios.

We look forward to continued collaboration. Stay tuned for future updates, join community discussions, and submit feature ideas or code contributions to push the boundaries of low-code development together.

About OpenTiny

Join the OpenTiny open-source community! Add our WeChat assistant opentiny-official to communicate with fellow front-end developers.

Official Website: https://opentiny.design
OpenTiny Monorepo: https://github.com/opentiny
TinyEngine Repository: https://github.com/opentiny/tiny-engine

Feel free to star TinyEngine, TinyVue, GenUI SDK, TinyRobot and NEXT SDK on GitHub.
To contribute, locate issues tagged good first issue in each repository and join our open-source co-construction efforts!

How Do Coding Agents Actually Work, and Why Do They Produce Inaccurate Outputs in Complex Codebases?

OpenTiny — Wed, 15 Jul 2026 06:51:50 +0000

Preface: Demystify the Black Box

Most developers hold two deep-rooted misconceptions about AI coding assistants.

They treat AI tools as opaque black boxes: input requirements and expect flawless code as output.
They believe models with million-token context windows will perform better as long as sufficient background information is provided.

This approach works efficiently for simple, independent small tasks. However, in enterprise-grade projects featuring hundreds of thousands of lines of code, dozens of components, cross-module business logic, and mixed legacy & new code, the "black box mindset" quickly collapses.

You will observe the AI hallucinates false logic, ignores architectural conventions, and even generates code that is syntactically valid yet fatally flawed for business scenarios.

Previous community articles introduced Harness Engineering, summarizing Harness methodologies, pitfalls and practical experience from OpenAI, Anthropic, LangChain and more.

Nevertheless, all publicly available success cases apply to greenfield projects or brand-new Harness implementations. Applying these technologies to decade-old codebases lacking architectural constraints, inconsistent test suites and incomplete documentation poses far greater challenges.

Part 1: Core Principles

This section answers the fundamental questions: How do Coding Agents operate, and why do they degrade in complex repositories?

Chapter 1: Operating Mechanisms of Coding Agents

1.1 The Essence of LLMs: Autoregression + Attention Mechanism

To understand why Coding Agents make mistakes, you first need to grasp how their underlying "brain" functions.

Large Language Models only perform one core task: predict the next token. They possess no separate reasoning process independent of output — reasoning is generation, and generation is reasoning. The model generates one token at a time, appends it to the existing sequence, and continues predicting subsequent tokens. This process is known as autoregression.

The Attention Mechanism governs how the model "reads" preceding content at each step. You can visualize it as a dynamic spotlight: while generating new text, the model scans the entire context window and assigns varying weight ("attention") to every position. In theory, this spotlight can illuminate any section of text.

However, practical deployment reveals several critical inherent limitations:

Characteristic	Technical Definition	Impact on Programming Workloads
Sparse, Biased Attention	The model does not distribute focus evenly; it prioritizes text at the very start and end of context	Critical logic placed in the middle of context may be overlooked
O(N²) Computational Complexity	Doubling context length quadruples compute and VRAM consumption	Files cannot be infinitely appended to the context window
Diluted Attention Weights	Longer context reduces the attention share allocated to each individual token	Key information gets buried when dozens of files are mixed together

Worse yet, autoregression creates a hallucination snowball effect specifically for coding workloads.
Software development involves long workflows with rigid constraints. Once the model guesses an incorrect function name early (due to diluted attention obscuring the correct API), it will consistently build coherent yet invalid logic atop this error for every subsequent token until compilation fails.

Two critical takeaways from autoregression and Attention:

Model "reasoning" is probabilistic token continuation, not formal logical deduction.
Context quality vastly outweighs context quantity. Feeding 50 unrelated files into the window dilutes critical signal rather than improving model performance.

1.2 Reinforcement Learning (RL): From Text Generation to Action Execution

Pre-training only teaches models what source code looks like via massive GitHub datasets. It is analogous to someone who has read every cookbook yet never set foot in a kitchen — they know recipe formatting but cannot cook.

Reinforcement Learning (RL) equips Coding Agents with actionable capabilities. Instead of explicitly instructing the model how to complete tasks, RL only defines success criteria — an ideology perfectly aligned with software development: any implementation that passes tests is acceptable.

Modern coding models undergo RL training with the following workflow:

Execute programming tasks inside simulated environments
Use test pass rates and code quality scores as reward signals
Learn when to read additional files, when to perform edits, and how to extract actionable clues from error logs

Practical Prompt Guidance from RL Principles

Understanding RL reveals how to craft effective instructions for Agents:

❌ Poor instruction: Fix the login bug.
✅ High-quality instruction: Resolve unsaved login session state; all tests must pass after running npm test.

These two prompts appear similar to humans, but the latter provides verifiable success metrics that align directly with the reward signals the model learned during RL training. Clear, testable objectives drastically boost Agent performance.

1.3 The Agent Loop: Core Execution Cycle

LLMs can answer standalone questions, while Agents can complete multi-step tasks. The core distinction lies in the repeating loop:
Call LLM → Determine next action → Execute tool → Write tool output back to context → Re-invoke LLM

This repeating sequence is the Agent Loop.

Take a concrete example task: Fix the bug where user sessions fail to persist after login.

Iteration	Agent Behavior
Round 1	Call `list_directory` to inspect project root folders
Round 2	Identify the `src/auth` directory, invoke `read_file` to load `login.js`
Round 3	Detect calls to `sessionManager.save()`, read `session/manager.js` for implementation details
Round 4	Discover missing `await` for asynchronous logic inside `save()`, execute `edit_file` to patch the code
Round 5	Launch shell tool to run automated test suites
Round 6	Confirm all tests pass and generate a summary of the resolved issue

One vital detail: output from every single tool call is appended to the shared context window. This continuously inflates context size with file contents, shell outputs and error logs — the root cause of failures for lengthy tasks due to context pollution.

Chapter 2: Longer Context Does Not Equal Better Performance

After grasping LLMs, RL and Agent Loops, a natural question emerges: what defines the functional limits of Coding Agents?

Many developers assume the bottleneck is insufficient context window capacity. This statement is only half correct. The true challenge is not whether data can fit into context, but whether the model can reliably and accurately utilize the data once loaded.

We split Coding Agent context challenges into two distinct layers:

Capacity Limits: Hard technical caps on input size enforced by models and tooling
Utilization Limits: Even with data loaded, the model may fail to extract critical information

The second layer almost always determines real-world performance.

2.1 Physical Capacity vs Effective Context Window

Every LLM has a hard maximum context window size, dictated by underlying compute and memory costs. Traditional Attention algorithms scale quadratically with input length, slowing inference and increasing VRAM consumption as text grows longer.

"Extended context support" purely means the model can technically accept larger input payloads — it does not guarantee stable, accurate comprehension at maximum window size.

Long context windows solve storage constraints alone; they cannot resolve comprehension degradation.

2.2 Context Rot

Research published by Chroma titled Context Rot demonstrates that model performance consistently declines as input length increases. Degradation becomes far more severe when relevant information is semantically distant from the core task query.

Within Agent workflows, every grep result and loaded file that proves irrelevant acts as attention noise, degrading the model’s accuracy in subsequent iterations.

In practical development scenarios, the core pain point is not the model lacking access to information, but its inability to reliably isolate critical signals amid noise.

This is the most widely misunderstood property of long context windows:
Developers often dump requirement docs, architecture diagrams, API specs and historical discussions into context simultaneously under the assumption "more information = better results." This frequently backfires:

Extended text dilutes attention weights
Irrelevant content buries critical clues
When questions and relevant code are separated by large blocks of text, the model prioritizes superficially matching irrelevant snippets

The core challenge introduced by long context is not data storage, but noise mitigation.

2.3 Lost in the Middle: U-Shaped Attention Distribution

The "Lost in the Middle" phenomenon predates Context Rot research. A 2024 Stanford study published in TACL proved LLM attention follows a U-shaped curve: the highest focus is allocated to text at the absolute start and end of context, while content in the middle receives minimal weight.

In multi-document testing with 20 input files, accuracy dropped over 30% when the document containing the correct answer was placed in positions 5–15 (the middle zone), versus placement at the first or last position.

For Coding Agents, this creates tangible failures: if the Agent loads 8 source files while the critical business logic resides in the 4th file, the model will overlook the key implementation due to the attention blind spot in the middle of context.

Key Conclusion: Context management is a rigorous engineering discipline, not just loading all available text. Precise, concise context outperforms bloated, noisy context. As Anthropic outlined in its Context Engineering blog: context is a finite resource with diminishing marginal returns.

2.4 Three Fundamental Limitations of Current Coding Agents

Irreversible Bias Accumulation
Once the model misinterprets logic in an early iteration, all subsequent reasoning and code generation builds upon this flawed premise. In coding tasks, this manifests as locally consistent yet globally incorrect code: individual lines, function calls and naming standards appear valid, yet core assumptions about function responsibilities or API semantics are fundamentally wrong. Many AI-generated bugs are logically sound in isolation but broken end-to-end.
Limited Multi-Constraint Handling
Real-world development enforces simultaneous rules: syntax validity, semantic logic, directory structure, legacy compatibility, test coverage, performance budgets, security boundaries and team style guides. Agents struggle to maintain compliance with all constraints over long task chains. Fixing one bug often breaks compatibility or violates coding standards.
Natural Serial Exploration Bias
Senior human developers maintain multiple parallel hypotheses and eliminate them iteratively when debugging. Most Agents default to serial exploration: they pursue one line of investigation fully before testing alternatives, frequently wasting resources on dead-end paths.

Now that we understand why Agents degrade in complex codebases, we examine how tooling compensates for these inherent flaws.

Part 2: Tooling Analysis

This section avoids head-to-head comparisons between Coding Agent products. Instead, it breaks down the core mechanisms different tools use to offset unstable comprehension of large repositories.

Chapter 3: Four Paradigms for Code-Aware AI Tooling

3.1 Evaluate Context Systems, Not Just Underlying Models

Comparing model parameter counts cannot explain real-world performance gaps. In production projects, the decisive factor is not the model’s raw code generation ability, but how the tool interfaces with the repository, ingests project constraints, forms closed action loops, integrates external extensions, and preserves reusable team knowledge.

We analyze tools across five core evaluation dimensions:

Context Ingestion: Does the tool rely primarily on semantic retrieval/file scanning, or explicit knowledge files (specs, rules, SKILL.md, AGENTS.md)?
Persistent Constraints: Are project standards stored as one-off temporary prompts per session, or version-controlled repository assets reusable long-term?
Action Loops: Does the tool only output static suggestions, or autonomously read/edit files, run shell commands and iterate based on feedback?
External Extensibility: Does it support MCP, hooks, subagents, plugins and skill packages to inject custom workflows?
Team Governance: Are optimization practices individual developer tricks, or standardized project/team engineering assets?

All modern tools including Cursor, Claude Code, Codex CLI and Kiro implement full Agent Loop functionality (file read/write, command execution, iterative fixes) alongside MCP, subagent and skill extensions. Standardized knowledge files such as SKILL.md and AGENTS.md are cross-compatible across platforms.

Our comparison focuses on each tool’s unique prioritized optimization direction, rather than feature checklists.

3.2 Cursor: Native IDE Agent with Optimized Retrieval & Context Recall

Cursor is one of the most mature AI-first IDEs built atop VS Code, featuring full multi-step task planning, multi-file editing, terminal automation and iterative refinement until tests pass.

Version 2.4 (Jan 2026) introduced subagents (isolated parallel child agents with independent context windows) and SKILL.md skill packages. Version 2.5 (Feb 2026) expanded the plugin ecosystem, packaging skills, subagents, MCP servers and hooks into installable marketplace modules. Additional offerings include Cloud Agents (isolated cloud VMs triggered via webhooks/Slack/GitHub) and scheduled Automations workflows.

Cursor’s defining competitive advantage lies in repository indexing and context retrieval deeply integrated within the IDE workflow.

Most AI coding errors stem from misidentifying relevant source files rather than flawed generation logic: the Agent may load semantically similar modules with unrelated business logic, or overlook critical rule/config files governing system behavior. Cursor mitigates this via heavy investment in repository indexing infrastructure:

Full semantic vector indexing of the entire codebase runs in the background on first project open, building a structural repository map before any Agent session starts.
Four-tier rule system: project-level .cursor/rules, user-level, team-level and session-level AGENTS.md to consistently inject constraints into every interaction.
Dynamic skill loading prevents dumping all project knowledge into the context window simultaneously.

Vector RAG Workflow

Scan full repository files
↓
Split code by semantic blocks (functions/classes, not arbitrary line breaks)
↓
Generate embedding vectors for each logical code block
↓ Store embeddings in Turbopuffer vector database
↓ On user query: vectorize requirements, perform nearest-neighbor semantic search
↓ Inject matching code blocks + user prompt into LLM context

Even functions with no "auth" keyword in their names will be retrieved if their embedding semantically matches user authentication requirements. Code is split along syntactic boundaries rather than arbitrary line cuts for superior retrieval quality.
Limitations: Embedding vectors are stored on Cursor’s cloud servers (raw source remains local); initial indexing consumes high CPU/RAM for repositories exceeding 100,000 files.

Differentiator: Pioneered deep repository semantic retrieval natively embedded within the end-to-end IDE workflow.

3.3 Claude Code: Orchestratable, Governable Agent Exploration Pipelines

Where Cursor prioritizes in-IDE retrieval UX, Claude Code’s core focus is building composable, manageable exploration loops. It recognizes full repository comprehension rarely occurs in a single pass — understanding evolves through cycles of exploration, execution, feedback and revision that require structured orchestration, task division and centralized governance.

Live Grepping Workflow

Claude Code does not rely on pre-built RAG indexes, per engineering statements shared on Hacker News. Instead, it equips the Agent with raw filesystem tools to actively discover code on demand:

User query: Locate authentication logic
↓ Agent executes grep -r "auth" . → 87 matching results
↓ Agent executes grep -r "guard" . → 23 matching results
↓ Glob pattern search for **/*.interceptor.ts
↓ Read auth.interceptor.ts and trace call chains recursively
↓ Final identification of core authentication implementation

This multi-round tool workflow consumes 3–4x more tokens than indexed retrieval. The tradeoff is offset by a 1M-token ultra-large context window capable of loading entire modules in one payload, bypassing semantic retrieval weaknesses. Teams can also maintain a root CLAUDE.md manual repository map to skip redundant exploration steps.

Differentiator: Structured orchestration of multi-step discovery workflows for unindexed, complex codebases.

3.4 Codex: Low-Friction Execution & Validation Loops

Codex’s unique optimization streamlines code modification, execution and validation into tight, low-overhead cycles. Its core design assumption: many development tasks do not require full repository comprehension upfront. Fast local feedback accelerates convergence for well-scoped work such as lint fixes, test generation, bulk refactoring and isolated bug patches.

Codex excels at batch test generation, parallel independent task execution and background asynchronous workflows developers can resume later after meetings. Users describe it as a reliable long-running task executor rather than an interactive paired coding assistant.

Differentiator: Minimize convergence latency via lightweight local test/execution pipelines.

3.5 Kiro: Spec-First Structured Task & Long-Term Knowledge Management

Kiro is an AWS VS Code-based AI IDE with a distinct design philosophy focused on task formalization before writing any code. Many hallucinations originate from ambiguous requirements and missing persistent project context, which Kiro resolves through structured pre-coding documentation.

Core Three-Tier Mechanism

Spec-Driven Development After users input natural language requirements, Kiro auto-generates version-controlled Markdown specs stored under .kiro/specs:
requirements.md: Formal user stories + acceptance criteria
design.md: Database schemas, API endpoints, TypeScript interfaces, Mermaid data flow diagrams
tasks.md: Ordered implementation subtasks with dependencies

Example e-commerce review feature workflow:

Step 1: Generate Requirements Document
Define user submission windows, star ratings, merchant reply functionality and sorting rules.

Step 2: Generate Design Document
Database Review table schema, REST API routes, frontend component interfaces.

Step 3: Generate Task Breakdown
Ordered actionable subtasks linked to corresponding requirements.

Step 4: Execute Individual Tasks
Launch coding workstreams for each subtask with built unit test coverage requirements.

All spec files are tracked via Git for diff tracking, code review and historical audit trails. Developers report cutting two weeks of trial-and-error work via two hours of spec drafting, with automated high test coverage as a secondary benefit.

Steering Persistent Knowledge Files Running Kiro: Setup Steering auto-generates version-controlled project knowledge docs under .kiro/steering:
product.md: Product positioning and target user base
structure.md: Repository directory architecture rules
tech.md: Standard tech stack and tooling constraints Custom architecture/security rules can be manually added, and the tool automatically references these standards for every Agent session. Fully compatible with the open AGENTS.md standard.

Best For: Large collaborative teams, regulated audit-heavy industries, AWS cloud-native projects.
Less Ideal: Tiny one-line hotfixes with excessive spec setup overhead.

Interoperable SKILL.md Skill Packages Identical skill file format as Cursor and Claude Code for reusable domain workflow modules.

Differentiator: Eliminate pre-task ambiguity by formalizing requirements, architecture and team standards into persistent, reusable repository assets.

3.6 Summary: Tool Feature Convergence, Knowledge Engineering Is The Real Divide

All four tools share overlapping core functionality, with differentiation rooted in their prioritized context compensation strategy:

Platform	Unique Differentiator
Cursor	Indexed semantic retrieval + explicit @ reference context injection, parallel cloud subagent processing
Claude Code	Dynamic on-demand exploration, shared multi-agent context merging with explosion guardrails
Codex	Short-lived session pipelines, sequential agent chaining centered on shell execution feedback
Kiro	Pre-structured spec requirements + persistent version-controlled knowledge base

As feature parity and cross-compatible knowledge file standards expand, the decisive competitive advantage shifts to internal project knowledge infrastructure:

Raw Code Repository
↓ Reverse-engineer standardized rule docs (.cursorrules / CLAUDE.md / Kiro Steering)
↓ Inject structured knowledge into AI Agents
↓ Generate compliant new source code
↓ Synchronize updated standards back to repository (closed loop)

Tooling and LLMs will continuously update, but structured project knowledge assets compound team value over time — this is the core competitive edge for AI-native engineering workflows.

Last updated: March 2026. All analysis based on public documentation and hands-on testing; platform functionality subject to frequent official updates.

Appendix: Reference Materials

Research & Context Theory

Chroma, Context Rot: How Increasing Input Tokens Impacts LLM Performance (July 2025) — https://research.trychroma.com/context-rot

About OpenTiny NEXT

OpenTiny NEXT is an enterprise-grade intelligent frontend development solution built on Generative UI and WebMCP core technologies. It delivers intelligent upgrades for legacy products including TinyVue component library and TinyEngine low-code engine, while launching Agent-native products such as frontend NEXT-SDKs, AI Extension, TinyRobot AI Assistant and GenUI. The suite empowers AI to interpret user intentions and complete tasks autonomously, accelerating intelligent transformation for enterprise applications.

Join the OpenTiny Open Source Community

WeChat Assistant: opentiny-official
Official Website: https://opentiny.design
GenUI SDK Repo: https://github.com/opentiny/genui-sdk (Star ⭐ appreciated)
TinyRobot Repo: https://github.com/opentiny/tiny-robot (Star ⭐ appreciated)
NEXT WebMCP SDK Repo: https://github.com/opentiny/webmcp-sdk (Star ⭐ appreciated)

If you wish to contribute, look for issues tagged good first issue within each repository. Feel free to leave comments with any questions or feedback!

Developing an AI chat page from scratch takes two weeks? Try this Vue3 AI conversation component library, TinyRobot, and get started out of the box!

OpenTiny — Thu, 02 Jul 2026 09:19:16 +0000

Anyone who has built an AI chat UI knows that even a basic usable dialogue interface requires at least two weeks of development work. This includes message bubble styling, real-time streaming rendering, and full message state management. TinyRobot is here to eliminate repetitive boilerplate work for you.

1. Focus Exclusively on AI Chat Scenarios, Not Generic UI

Many developers may wonder: Is this another UI library competing with TinyVue? The answer is absolutely no — they are complementary tools.

TinyVue covers general page UI: back-end dashboards, forms, modals, and standard enterprise components.
TinyRobot is built solely for AI chat interaction scenarios.

With TinyRobot, you only need to focus on your core business logic: what data the AI returns and what workflows you need to implement. All UI rendering logic, interactive behaviors, and message state maintenance are fully handled by the library.

Current version: v0.4.1, released under MIT License, with 22 iterative releases.
Code composition: 58.1% TypeScript + 35.4% Vue, delivering robust full type safety.

2. Architecture Breakdown: Monorepo Three-Package Division

TinyRobot adopts a pnpm workspace monorepo structure, split into three independent packages with clear responsibilities:

Package Name	Core Function	Installation Requirement
`@opentiny/tiny-robot`	Core UI components (bubble, sender, container, etc.)	Mandatory
`@opentiny/tiny-robot-kit`	AI data layer utilities (Provider integration, composables, storage, plugins)	Optional; install only if connecting LLMs
`@opentiny/tiny-robot-svgs`	Built-in SVG icon library	Optional; install only if using official icons

The design philosophy behind this three-layer separation is Separation of Concerns:

Component Layer: Only responsible for rendering and user interactions, independent of LLM requests or data persistence logic.
Tool Layer: Handles heavy logic including model provider access, message state machines, plugins, conversation lifecycle, and storage strategies.
Resource Layer: Icons are packaged separately without tight coupling to core UI components.

You only need the core package for basic chat UI capabilities; add the kit package on demand for AI integration. Minimal dependencies, maximum flexibility.

3. The Soul of the Kit Package: Composable Architecture

Building chat pages is often plagued by messy state management — either cumbersome prop drilling or bloated global state stores. TinyRobot solves this elegantly with two Vue composable hooks, usable anywhere within component trees to access full conversation capabilities.

Directory structure of composables:

packages/kit/src/vue/
├── message/       # useMessage composable
└── conversation/ # useConversation composable

useMessage — Message Management Hook

Create, update, delete, and stream-append chat messages with simple APIs
Message states wrapped in Vue reactive objects, auto-reactive with components (no manual state sync)
Built-in role classification (user / ai / system), eliminating repetitive if (role === 'ai') conditional logic

useConversation — Conversation Session Hook

Manage full conversation context: chat rounds, history records, and session switching
Natively integrated with storage strategies for automatic chat persistence
Full lifecycle control: session creation, loading, switching, and destruction

In short: Call useXxx() inside any Vue component to access complete chat management logic — no prop passing, no heavy global stores, clean and lightweight.

4. ResponseProvider Pattern: Plug-and-Play AI Data Sources

Many teams face painful refactoring work when switching LLM vendors: migrating from OpenAI to DeepSeek, private local models, or internal enterprise AI gateways often requires rewriting massive front-end chat logic.

TinyRobot Kit decouples traditional fixed AI client implementations via the ResponseProvider pattern. The component and message engine remain agnostic to your underlying LLM service; they only require data formatted to match the OpenAI Chat Completions standard.

Swap LLM services freely: OpenAI, DeepSeek, local private models, internal enterprise gateways are all supported
Flexible access modes: Frontend direct requests, backend proxy forwarding, unified model gateways — no changes required to UI components
Stable response structure: Standardized formats for plain text, streaming chunks, and tool call payloads

All vendor-specific differences are isolated to the data access layer, leaving the UI layer relying on a unified stable schema. This makes integration with existing backends, permission systems, and model routing logic far simpler.

5. Built-In Persistence Strategies: 3 Storage Options + Custom Extensions

No need to implement local storage logic from scratch. The framework ships with three mature built-in storage adapters, plus support for fully custom implementations.

Storage module directory:

packages/kit/src/storage/

Storage Strategy	Best For	Key Features
LocalStorage	Lightweight short-term chat history	Synchronous read/write, simple implementation, limited capacity
IndexedDB	Large volumes of long-term conversation records	Asynchronous operation, large storage capacity, structured query support
Custom Adapter	Enterprise backend database integration	Fully self-defined logic, ideal for production business systems

Simply implement the unified StorageAdapter interface to connect any database (MongoDB, MySQL, Redis, etc.) with consistent APIs.

6. Deep Dive into Core Components

Full Project Structure

tiny-robot/
├── packages/
│   ├── components/       # Core UI component library
│   │   ├── src/
│   │   │   ├── bubble/        # Chat message bubbles
│   │   │   ├── sender/        # Message input box
│   │   │   ├── container/     # Chat layout container
│   │   │   ├── history/       # Conversation history sidebar
│   │   │   ├── attachments/    # File upload attachments
│   │   │   └── ...            # Other auxiliary components
│   ├── kit/               # AI data tool package
│   ├── svgs/              # SVG icon library
│   ├── playground/        # Local development playground
│   └── test/              # Test suites
├── docs/                   # Official documentation site
├── scripts/                # Build scripts
└── package.json

Bubble & BubbleList (Message Bubble + Message List)

The Bubble component is the fundamental visual unit for single chat messages:

role prop: Auto-styled differentiation for ai / user / system identities
placement prop: Left (start) / Right (end) alignment fully configurable
Native streaming rendering: Incrementally render token-by-token AI output without waiting for full responses
Built-in Markdown parser: Auto-format code blocks, lists, hyperlinks with zero extra code

BubbleList renders full multi-turn chat streams:

Accept a complete messages array for batch rendering of all chat records
roleConfigs: Global unified configuration for avatar, position, and visibility rules for all roles (no repeated props per message)
Customizable grouping strategies: Merge consecutive same-role messages or split by user messages; fully custom grouping functions supported
Intelligent autoScroll: Only auto-follow streaming content when users are scrolled to the bottom, avoiding disruption while browsing history

Sender (Message Input Box)

The user message entry component:

Multi-line text input, configurable send shortcuts (Enter / Ctrl+Enter)
Native file upload integration linked with the attachments component
Built-in send status management: loading / success / error states out of the box
Prefix & suffix slots for custom widgets (emoji pickers, voice buttons, etc.)

History (Conversation History Sidebar)

Navigation component for multi-session chat applications:

Supports flat list and grouped list data structures for history records
Native UI for selection, renaming, deletion, pinning, and context menu operations
Customizable slots for item icons, tags, and custom title content
Seamless integration with useConversation to build complete "history list + active chat page" workflows quickly

7. Full Theme System: One-Click Dark Mode & Brand Customization

Tokenized CSS variable design: All colors, spacing, font sizes, and border radians controlled via CSS variables — no source code edits required for rebranding
One-click dark mode toggle with complete built-in dark theme styles
Zero-intrusion brand customization: Override CSS variables only to match corporate design guidelines

8. Native Tree-Shaking Support, Controllable Bundle Size

// Import only the components you need
import { TrBubble } from '@opentiny/tiny-robot'

Every component exports independently; unused components are fully tree-shaken by modern bundlers
Kit and SVG packages are optional peer dependencies — they won’t increase bundle size if unused
No bloated "full library" overhead; keep production builds lightweight

9. Position in the OpenTiny Ecosystem

Ecosystem Partner	Relationship
TinyVue	Shared OpenTiny Design system; TinyVue for general UI, TinyRobot exclusive to AI chat scenarios
GenUI SDK	GenUI’s Vue renderer reuses TinyRobot’s base chat UI components
NEXT SDK	`@opentiny/next-remoter` builds AI chat interfaces directly on top of TinyRobot
TinyEngine	TinyEngine low-code platform integrates TinyRobot for built-in LLM dialogue modules

TinyRobot serves as the foundational UI layer of OpenTiny’s AI ecosystem, supplying standardized chat interaction components for all upper-layer intelligent applications.

10. Summary: Is TinyRobot Worth Adopting?

Advantages 👍

Precise vertical positioning: Specialized for AI chat instead of generic UI, no feature overlap with TinyVue
Clean Composable architecture: Decouples chat business logic from UI rendering
Plug-and-play ResponseProvider: Swap LLM vendors without rewriting front-end chat code
Modular three-package design: Install only what you need, avoid full-library bloat
Native streaming rendering built-in — a mandatory feature for AI chat that otherwise requires custom implementation

Areas for Improvement 🤔

Additional best practice documentation needed: SSE parsing, error recovery, model gateway integration, auth & tool call workflow examples
Early-stage community ecosystem with limited real-world production case studies
Component coverage to expand: Native rendering for reasoning chains, complex tool call outputs, and AI-specific interactive widgets

Ideal Use Cases 🎯

Enterprise AI assistants & intelligent customer service dialogue interfaces
AI code assistant chat panels
Low-code platform embedded AI dialogue modules
Any Vue3 application requiring AI conversation interaction

Project Resources

Resource Type	Link
GitHub Source Code	https://github.com/opentiny/tiny-robot
Official Documentation	https://docs.opentiny.design/tiny-robot
Quick Start Guide	https://docs.opentiny.design/tiny-robot/quick-start
Theme Configuration Docs	https://docs.opentiny.design/tiny-robot/theme
Official Website	https://opentiny.design/tiny-robot
NPM Core Package	https://www.npmjs.com/package/@opentiny/tiny-robot

If this article is helpful, give it a like and star the repository! Feel free to leave comments with questions or feedback.

TinyVue 3.30 Officially Released: Multi-End Adaptation & Enhanced AI-Assisted Programming

OpenTiny — Wed, 24 Jun 2026 08:40:01 +0000

In the era of ubiquitous connectivity, the boundaries of frontend component libraries keep expanding. Developers demand both rigorous efficiency on PC and flexibility & smoothness on mobile devices.

OpenTiny Community is thrilled to announce the official launch of TinyVue v3.30.0! This release is more than a routine feature iteration — it marks a milestone leap for TinyVue in cross-screen responsive capabilities.

📌 Release Feature Overview

Before diving into details, here are the major highlights of v3.30.0:

📱 Responsive Adaptation: Mobile layout support added for over 20 core components including Button and DialogBox
🛠️ Component Enhancements: Custom color support for CalendarView, upgraded internationalization for RichText
🤖 AI-Assisted Programming: New AGENTS.md file to improve accuracy of AI coding assistants
🧩 Stability Improvements: Bug fixes and dedicated compatibility patches for Safari & Firefox

🌈 New Community Contributors

The growth of TinyVue relies on every contributor. We’d like to extend special gratitude to two new contributors who submitted their first code in this release:

@ga163
@zhengshui

We also thank our 9 long-term regular contributors:

discreted66
gimmyhehe
James-9696
kagol
ourcx
shenjunjian
wuyiping0628
Yujing613
zzcr

OpenTiny keeps evolving thanks to all your hard work and dedication 👏

🚀 Core Highlight Breakdown

1. Responsive Layout: Seamless Integration Between PC & Mobile

TinyVue v3.30 carries out in-depth cross-end refactoring for 20+ core components:

Component Upgrades: Link, Cascader, Search, Breadcrumb, Steps, DialogBox, Form, Modal, Button and more can now automatically detect viewport sizes and switch to optimized interaction modes.
Consistent User Experience: Whether users operate on large desktop screens or tap mobile touchscreens, TinyVue delivers unified, polished visual experiences tailored for each device.

2. Polished Interaction Details

Great component libraries stand out through refined edge cases, and this version upgrades multiple complex components:

CalendarView: Supports custom theme colors to satisfy personalized schedule display requirements

RichText: Full i18n internationalization support; optimized editor border rendering and hyperlink redirect interception for professional content creation
Rate: Fixed color switching bug for half-star selection to deliver smoother visual feedback
Drawer: New appendToBody prop completely resolves occlusion and z-index issues in complex layouts

3. AI as Your New Development Teammate

OpenTiny keeps pace with AI development trends, with major AI tooling improvements in v3.30:

AGENTS.md: A dedicated structured context file for AI coding assistants (GitHub Copilot and similar tools), helping AI better understand TinyVue project architecture. Doc Link: https://github.com/opentiny/tiny-vue/blob/dev/AGENTS.md
Build with AI: Updated documentation exploring unlimited combinations between component libraries and AI tools. Doc Link: https://github.com/opentiny/tiny-vue/blob/dev/README.zh-CN.md

🐛 Stability: Bug Fixes & Optimizations

While rolling out new features, we prioritize long-term stability. This release contains numerous fixes covering:

Cross-browser Compatibility: Resolved massive blank space and multi-line rendering defects for read-only Input on Safari; fixed horizontal scrollbar anomalies for tables on Firefox
Engineering Optimizations: Improved style isolation under SaaS mode; refined E2E test cases to strengthen stability in complex production environments

Full Changelog: https://github.com/opentiny/tiny-vue/releases/tag/v3.30.0

🔗 Upgrade Guide

Install @opentiny/vue@3.30.0 to experience the latest version:

# npm
npm install @opentiny/vue@3.30.0

# yarn
yarn add @opentiny/vue@3.30.0

Closing Remarks

TinyVue 3.30 represents a critical milestone toward full-scenario, multi-terminal coverage. Whether building complex enterprise backends or lightweight mobile applications, TinyVue aims to be your most reliable UI partner.

About OpenTiny NEXT

OpenTiny NEXT is an enterprise intelligent frontend solution built on Generative UI and WebMCP. It intelligently upgrades legacy products including TinyVue component library and TinyEngine low-code engine, and launches new Agent-oriented products such as NEXT-SDKs for frontend, AI Extension, TinyRobot AI Assistant and GenUI. It empowers AI to comprehend user intentions and execute tasks autonomously, accelerating enterprise intelligent transformation.

Join the OpenTiny Open Source Community

WeChat Assistant: opentiny-official
Official Website: https://opentiny.design
TinyVue Repository: https://github.com/opentiny/tiny-vue (Star ⭐ appreciated)
About Us: https://opentiny.design/opentiny-design/about

If you want to contribute, look for good first issue labels in the repo. Feel free to leave comments with any questions or feedback!

Diving Into GenUI SDK Source Code: How AI Enables Both Chat & Dynamic Page Rendering

OpenTiny — Wed, 24 Jun 2026 06:20:18 +0000

When AI responses evolve beyond plain Markdown text and directly render interactive forms, charts and cards — this marks the next frontier of AI interaction. Enter GenUI SDK.

1. What Is This Project All About?

GenUI SDK is a full-stack development toolkit built by the OpenTiny team around Generative UI.

The core concept is straightforward, as shown in the comparison table below:

Dimension	Traditional Conversational AI	Generative UI
AI Output	Plain text / Markdown	Interactive components (forms, charts, cards)
User Operations	Only send follow-up messages	Directly interact with UI generated by AI
Information Density	Low (text-based order descriptions)	High (visual order cards with actionable buttons)

Example Scenario

If a user asks to check their order status:

Traditional AI replies with paragraphs of text describing order details.
Generative UI renders a complete order card with status tags and clickable "Cancel Order" buttons.

GenUI SDK’s core mission: Upgrade AI output from natural language to component description language.

Current version: @opentiny/genui-sdk-vue@1.2.1, released under the MIT License.
Code composition: 66.2% TypeScript + 31.2% Vue.

2. Core Mechanism: Schema-Driven Rendering

The "magic" of GenUI SDK relies on a fixed processing pipeline:

AI Output → UI Schema → Renderer Parsing → Vue/Angular Components → User Interaction → New Message → AI

A UI Schema is descriptive component definitions, not hardcoded HTML or Vue templates, which specify:

Component type (Form, Card, Chart, etc.)
Component properties (form fields, card content, chart datasets)
Interactive behaviors (button clicks, form submission callbacks)

Key Insight

AI outputs component descriptive language instead of raw natural language. The front-end renderer translates these descriptions into real UI elements.
AI developers do not need to write Vue syntax — they only need to define requirements such as "a table with three columns and the following data".

3. Architecture Breakdown: Integrated Frontend & Backend Multi-Package Design

genui-sdk/
├── packages/
│   ├── server/                # Backend service package
│   ├── frameworks/
│   │   ├── vue/               # Vue renderer
│   │   └── angular/           # Angular renderer
│   ├── core/                  # Shared core logic
│   ├── materials/             # Component material definitions
│   ├── chat-completions/      # Chat completion utilities
│   ├── benchmarks/            # Performance benchmark scripts
│   └── ...
├── projects/                   # Demo projects
├── sites/                      # Playground website
├── docs/                       # Official documentation
└── pnpm-workspace.yaml

Package Name	Core Responsibility	Key Capabilities
`@opentiny/genui-sdk-server`	Backend brain	LLM integration, message orchestration, tool calling, access control
`@opentiny/genui-sdk-vue`	Vue front-end renderer	Schema parsing, dynamic component rendering, theme customization
`@opentiny/genui-sdk-angular`	Angular front-end renderer	Schema parsing, dynamic Angular component rendering

Full-Stack Integration

GenUI is not merely a front-end wrapper. The Server package acts as the central brain, converting plain LLM text responses into structured payloads carrying renderable UI Schema.

4. Server Package: More Than a Simple LLM Proxy

The core value of the Server package lies in response orchestration and enhancement:

LLM Integration: Compliant with OpenAI API specs, compatible with OpenAI, DeepSeek, Anthropic and other mainstream large models
Message Orchestration: Assemble user prompts, AI replies and tool return values into complete conversation streams
MCP Tool Extensions: Connect external/enterprise systems via Model Context Protocol to expand AI tooling capabilities
Access Control: Assign distinct tool permissions for different users, a critical requirement for enterprise scenarios
Custom Actions: Configure custom commands such as page navigation and dynamic form generation

In short: The Server layer does not simply forward raw API responses — it translates plain AI text into renderable instructions for the front end.

5. Vue Renderer: Translator Between Schema & Real Components

Vue Renderer Workflow

Receive UI Schema returned by the LLM
Parse schema into standardized component definitions (type, props, interactions)
Dynamically mount components via Vue’s built-in <component :is="xxx">
Wrap user interactive events into standardized messages and send them back to the AI

Customization Capabilities

Custom Component Registration: Register business-specific components so the AI can generate them alongside standard UI elements
Custom Interaction Flows: Configure multi-turn dialogue logic and custom command handlers
Tokenized Theming System: Full support for brand styling and dark mode

6. Materials System: The AI’s UI Vocabulary Library

packages/materials/

The Materials package serves as GenUI’s dictionary of available UI building blocks:

Each material defines a component’s specifications: name, props, default values and interactive rules
The AI can only render components registered in the Materials library, eliminating unrenderable UI output
Developers can extend the library with new materials to expand the AI’s UI generation vocabulary

Material Extension Process

Register component Schema definitions in Materials
Register corresponding component implementations in Vue/Angular renderers
Configure the Server layer to enable AI generation of this component
The LLM can now output this component type in its responses

AI generation capabilities always align with front-end rendering support — eliminating mismatches where the AI outputs UI elements the client cannot display.

7. MCP Tool Integration: AI Beyond Visual Display

GenUI SDK fully supports Model Context Protocol (MCP) extensions:

AI can invoke tools mid-conversation: query databases, call external APIs, read file data
Raw tool return data can be automatically converted into Generative UI components such as data tables
MCP transforms GenUI from a pure presentation layer into a complete business operation layer

Real-World Example

When a user asks to pull monthly sales data, the AI will not only describe metrics in text — it renders an interactive chart with built-in dimension switching and filtering functions, enabling true hands-on AI operations.

8. Angular Renderer: True Cross-Framework Compatibility

The Angular renderer mirrors all functionality of the Vue renderer, leveraging Angular’s dynamic component APIs to render Schema-defined UI elements.

Cross-Framework Design Philosophy

Schemas are universal, while renderers are interchangeable. Developers can select either Vue or Angular without being locked into a single framework.

9. Playground: Self-Demonstrating Demo Environment

GenUI provides an official online Playground:
https://opentiny.github.io/genui-sdk/playground/

The standout feature: the Playground itself is built entirely with GenUI SDK. All interactive UI elements generated during your chat sessions are real production-grade GenUI outputs — a live demo more persuasive than static documentation screenshots.

10. GenUI’s Position Within the OpenTiny Ecosystem

Ecosystem Partner	Relationship
TinyRobot	GenUI’s Vue renderer may reuse TinyRobot’s base chat UI components
NEXT SDK	NEXT SDK’s WebMCP module provides browser-side transport for GenUI tool calls
TinyVue	GenUI’s built-in materials include native TinyVue components — AI can generate standard TinyVue UI out of the box
TinyEngine	Shares core schema-driven rendering logic with low-code engines

GenUI SDK sits in the top AI application layer of the OpenTiny stack. It leverages underlying UI components (TinyVue / TinyRobot) and protocol layers (NEXT SDK / WebMCP) to build end-user-facing Generative AI applications.

11. Summary: The Next Era of AI Interaction

Core Innovations

Generative UI Paradigm: Shift from text-only dialogue to fully interactive AI-generated interfaces
End-to-End Frontend & Backend Integration: Complete Server + Vue/Angular stack instead of isolated front-end shells
Schema-Driven Architecture: Framework-agnostic descriptive layer connecting LLM outputs and client rendering
Extensible Material Library: Controlled expansion of the AI’s UI generation vocabulary

Core Advantages

Compliant with OpenAI API standards, low barrier for LLM access
Dual official renderers for Vue and Angular, no framework lock-in
Native MCP integration enabling AI to perform actionable business operations
Self-contained Playground for live, tangible product demonstrations

Current Limitations

Small GitHub star count; the project is still in early adoption and requires more real-world case validation
Generative UI relies on well-engineered LLM prompts to produce valid Schema outputs
The upper limit of AI UI complexity is determined by the richness of registered materials

Ideal Application Scenarios

AI customer service panels with one-click business operations
Dynamic AI-powered data visualization dashboards
Context-aware conversational form filling
Enterprise internal AI assistant interaction upgrades

GenUI SDK pioneers the next generation of AI front-end interaction, moving beyond plain text dialogue to fully interactive generative UI. While the project is in its early stages, its architecture delivers a clear long-term vision and solid engineering foundations.

Project Resources

Resource Type	Link
GitHub Source Code	https://github.com/opentiny/genui-sdk
Official Documentation	https://docs.opentiny.design/genui-sdk/guide/quick-start.html
Online Playground	https://opentiny.github.io/genui-sdk/playground/
Server Usage Docs	https://docs.opentiny.design/genui-sdk/guide/server-usage.html
Official Website	https://opentiny.design/genui-sdk
NPM Vue Package	https://www.npmjs.com/package/@opentiny/genui-sdk-vue

If this project interests you, give it a like and star the repo to share it with more developers! Generative UI represents the next major wave of AI interaction — get ahead of the curve by learning it early.

About OpenTiny NEXT

OpenTiny NEXT is an enterprise-grade intelligent front-end development solution built on Generative UI and WebMCP core technologies. It delivers intelligent upgrades for legacy products including the TinyVue component library and TinyEngine low-code engine, while launching new Agent-native products such as front-end NEXT-SDKs, AI Extension, TinyRobot AI Assistant and GenUI. The stack enables AI to interpret user intentions and complete tasks autonomously, accelerating intelligent transformation for enterprise applications.

Join the OpenTiny Open Source Community

WeChat Assistant: opentiny-official
Official Website: https://opentiny.design
GenUI SDK Repository: https://github.com/opentiny/genui-sdk (Star ⭐ appreciated)

If you wish to contribute, look for issues tagged good first issue within the repository. Feel free to leave comments with any questions or feedback!

TinyRobot Bubble: A Vue 3 Message Bubble Component Built Exclusively for AI Conversations

OpenTiny — Mon, 22 Jun 2026 12:17:08 +0000

Introduction

Message bubbles may seem like a trivial UI element in AI applications, yet they grow highly complex once put into production. Typical requirements include token-by-token streaming output, Markdown rendering, image display, multi-modal content, reasoning process unfolding, tool call visualization, message grouping, collapsible states, role-specific styles, auto-scrolling, and more. Implementing all of these features from scratch bloats business code with tedious presentation logic.

The Bubble component of TinyRobot is purpose-built to solve this pain point. Rather than a simple text bubble, it delivers a complete message rendering system for AI chat interfaces, consisting of three core primitives: Bubble, BubbleList and BubbleProvider. Developers can seamlessly scale from rendering single messages to full conversation streams.

Render One AI Message with Minimal Code

Basic usage is straightforward:

<template>
  <tr-bubble
    role="assistant"
    content="Hello, I'm TinyRobot, here to help you quickly build AI chat interfaces."
    placement="start"
  />
</template>

<script setup lang="ts">
import { TrBubble } from "@opentiny/tiny-robot";
</script>

The placement prop controls left/right alignment, while the avatar slot accepts custom avatar components. Visual styles such as background color, font size, border radius and width can be customized via CSS variables. This allows teams to rapidly build functional UIs and refine styling to match product designs later.

Reactive Content Optimized for Streaming Output

AI responses are returned incrementally token by token instead of in one full payload. The content property of Bubble is fully reactive — simply update its value continuously to achieve native streaming effects.

<script setup lang="ts">
import { TrBubble } from "@opentiny/tiny-robot";
import { IconAi } from "@opentiny/tiny-robot-svgs";
import { h, ref } from "vue";

const aiAvatar = h(IconAi, { style: { fontSize: "32px" } });
const streamContent = ref("");

async function startStream() {
  const fullText = "This is an AI response being generated token by token.";
  streamContent.value = "";
  for (const char of fullText) {
    streamContent.value += char;
    await new Promise((resolve) => setTimeout(resolve, 80));
  }
}
</script>

This architecture works perfectly with SSE, Fetch Stream, or the message management utilities from TinyRobot Kit. The presentation layer only reacts to changes in message data without embedding streaming logic inside the component itself.

Support for More Than Text: Images, Markdown, Reasoning & Tool Calls

The Bubble content model aligns with standard LLM message structures. The content prop accepts either plain strings or structured arrays for multi-modal content, such as images:

<tr-bubble
  content-render-mode="split"
  :content="[
    { type: 'text', text: 'Here is the generated result:' },
    { type: 'image_url', image_url: { url: imageUrl } }
  ]"
/>

When items carry the image_url type, the built-in image renderer activates automatically. Use contentRenderMode to render all media within a single bubble box or split them into separate blocks.

Pre-built renderers are included for all common AI output types:

Text: Plain text rendering
Image: Image asset rendering
Markdown: Full Markdown syntax support
Loading: Placeholder loading state
Reasoning: Collapsible model thinking process
Tools / Tool: Single or batch function call visualization
ToolRole: Dedicated styling for tool response messages

Render reasoning content by passing the dedicated reasoning_content prop:

<tr-bubble
  :content="answer"
  :reasoning_content="reasoningContent"
  :state="{ thinking: false, open: true }"
/>

Tool calls follow the standard OpenAI schema format:

const message = {
  role: "assistant",
  content: "I will look up the weather for you.",
  tool_calls: [
    {
      id: "call_0",
      type: "function",
      function: {
        name: "get_weather",
        arguments: '{"city":"Shenzhen"}'
      }
    }
  ],
  state: {
    toolCall: {
      call_0: { status: "running", open: true }
    }
  }
};

This design makes Bubble ideal for building Agents, Copilots, enterprise knowledge base assistants, and other products that need transparent visibility into model execution steps.

BubbleList: Scale from Single Bubbles to Full Conversation Flows

Real-world chat interfaces render sequences of messages. The BubbleList component accepts a messages array and unifies avatar, alignment and visibility rules across roles via roleConfigs.

<template>
  <tr-bubble-list
    auto-scroll
    :messages="messages"
    :role-configs="roleConfigs"
  />
</template>

<script setup lang="ts">
import type { BubbleListProps, BubbleRoleConfig } from "@opentiny/tiny-robot";
import { TrBubbleList } from "@opentiny/tiny-robot";

const messages: BubbleListProps["messages"] = [
  { role: "user", content: "Summarize this document for me" },
  { role: "assistant", content: "Sure, please upload your document." }
];

const roleConfigs: Record<string, BubbleRoleConfig> = {
  user: { placement: "end" },
  assistant: { placement: "start" }
};
</script>

The default grouping strategy uses user messages as dividers: every user message starts a new group, and all subsequent non-user messages are merged into the same reply block. Two alternative grouping modes are available: consecutive role grouping, or fully custom grouping functions.

This grouping logic fits standard AI chat workflows naturally:

User Message
└─ Assistant Reply Group
   ├─ Assistant: Initiate data lookup via tool calls
   ├─ Tool: Return ticket details
   ├─ Tool: Return SLA policy rules
   └─ Assistant: Risk analysis based on tool outputs

User Message
└─ Assistant Reply Group
   ├─ Assistant: Fetch assignee and approval status
   ├─ Tool: Return handler information
   └─ Assistant: Recommended resolution steps

The autoScroll feature is optimized for chat UX:

Scrolls smoothly to the bottom when users send new messages
Only follows streaming updates if the user is already viewing the bottom, avoiding disruption while browsing history.

Renderer Architecture: Extend Content Types Without Rewriting Components

One of Bubble’s core advantages is its pluggable renderer system. Render logic is split into two independent layers:

Box Renderer: Controls the outer bubble container layout and styling
Content Renderer: Handles internal rendering of text, media, tool outputs, and custom widgets

<tr-bubble-provider :content-renderer-matches="contentRendererMatches">
  <tr-bubble-list :messages="messages" />
</tr-bubble-provider>

import { BubbleRendererMatchPriority, type BubbleContentRendererMatch } from "@opentiny/tiny-robot";
import { markRaw } from "vue";
import SchemaCardRenderer from "./SchemaCardRenderer.vue";

const contentRendererMatches: BubbleContentRendererMatch[] = [
  {
    find: (_, content) => content.type === "schema_card",
    renderer: markRaw(SchemaCardRenderer),
    priority: BubbleRendererMatchPriority.CONTENT
  }
];

This pattern lets teams inject custom structured widgets — order cards, approval panels, knowledge base citations, charts — without forking component source or writing massive conditional rendering logic inside message lists.

State Isolation Optimized for Enterprise AI Systems

All transient UI states (expanded reasoning panels, unfolded tool call details, like/dislike feedback) are stored separately in the state field of each message. State change events are emitted via state-change to parent components.

This separation keeps raw LLM message payloads clean and serializable for API transmission or database persistence, without polluting core business data with temporary UI flags.

Summary

TinyRobot Bubble is far more than a set of aesthetic chat bubbles. It encapsulates all repetitive, complex presentation logic common to AI chat interfaces into a composable system:

Single message rendering: Bubble
Full conversation stream rendering: BubbleList
Global custom content extension: BubbleProvider
Native built-in support for text, images, Markdown, reasoning chains and tool calls
Full coverage of role styling, message grouping, auto-scrolling, slots and complete TypeScript typing

If you build AI Chat, Agent consoles, enterprise knowledge assistants or Copilot products with Vue 3, TinyRobot Bubble frees you from low-level UI implementation work to focus on core AI user value.

About OpenTiny NEXT

OpenTiny NEXT is an enterprise intelligent front-end solution built on two core technologies: Generative UI and WebMCP. It intelligently upgrades legacy products including the TinyVue component library and TinyEngine low-code engine, while launching new Agent-oriented products: NEXT-SDKs for frontend, AI Extension, TinyRobot AI Assistant and GenUI. The suite empowers AI to interpret user intentions and execute tasks autonomously, accelerating intelligent transformation for enterprise applications.

Join the OpenTiny Open Source Community

WeChat Assistant: opentiny-official
Official Website: https://opentiny.design
TinyRobot Repository: https://github.com/opentiny/tiny-robot (Star ⭐ appreciated)

To contribute, look for issues tagged good first issue in the repository. Feel free to leave comments with any questions or feedback!

Add AI Chat Entry with One Single Command! TinyRobot Makes It Super Easy

OpenTiny — Wed, 17 Jun 2026 09:08:16 +0000

Introduction

In the AI era, AI capabilities are advancing rapidly. Many teams want to add an AI chat entry to their projects. It sounds simple, yet implementation brings lots of work: chat UI, streaming response rendering, conversation state management, Markdown rendering, responsive layout, and more. These features are trivial separately, but combined together, they take massive development effort.

Is there a simpler, low-effort way to quickly build an AI chat application or embed an AI dialogue entry into existing projects?

Absolutely! That’s exactly what TinyRobot is built for.
Besides providing basic AI components like chat bubbles and input boxes as a component library, TinyRobot now ships with the TinyRobot CLI. Two simple commands cover two core scenarios:

Create a full project: Run the create command to generate a fully functional runnable TinyRobot demo project.
Integrate into existing projects: Run the add command to inject AI chat components into your existing Vue project.

To put it simply:

If you don’t have a project yet or want to preview the complete experience, use create.
If you own an existing project and only need an extra chat entry, use add.

What Is TinyRobot?

TinyRobot is a Vue 3 interactive component library and dialogue framework built for enterprise AI applications.
Built on the OpenTiny design system, it solves common front-end challenges for AI applications, including:

Organizing chat messages and dialogue UI
Rendering real-time streaming messages
Managing conversation states
Rapidly building AI assistants, intelligent customer service, and multi-turn dialogue pages
Responsive UI layout
Unified component styling and easy extension

You can write a simple chat box from scratch for small demos. But real production projects introduce extra complexity: message statuses, loading states, error prompts, multi-turn context, multi-model vendor configuration, and business component integration. All of these require heavy front-end encapsulation.

TinyRobot pre-packages repetitive interaction logic and engineering infrastructure for AI dialogue applications, allowing teams to move straight to business validation faster.

Why We Built the CLI Tool

From questionnaires, Q&A sessions and live stream feedback, we repeatedly received these requests:

I want to build an AI Q&A interface quickly without writing every component manually.
Is there a complete dialogue UI component I can import directly?
I already have an existing business project — can TinyRobot be integrated quickly?

These demands reflect the universal pursuit of higher development efficiency in the AI age. The CLI enables fast project initialization and code injection to cut development time. It also works seamlessly with AI Agents: you can pass this article to an AI and let it execute CLI commands automatically to finish integration, saving manual work. Meanwhile, the CLI lays groundwork for future AI-native features.

We identified two distinct usage scenarios:

Start from scratch for validation: Teams without an existing integration solution want to preview the full TinyRobot experience with minimal commands.
Incremental integration into live projects: Systems such as admin dashboards, workbenches and portals are already online or under development. The priority is to add an AI dialogue entry with minimal code changes.

Thus, TinyRobot CLI provides two core commands to cover both scenarios:

Scenario	Recommended Command	Use Cases
No existing project, or want to preview full features	`create` to generate a complete project	Demos, prototypes, PoCs, solution validation
Existing Vue project ready	`add` to inject chat components	AI entry for admin systems, workbenches, portals

Summary:

Run create if you need a fully functional standalone demo.
Run add if you only want to add chat capabilities to an existing project.

Path 1: Create a Full Project with `create` Command

The create command is ideal for rapid preview. It generates a complete project for first-time users to experience the full feature set of TinyRobot.

Step 1: Execute creation command

Run via npm or pnpm:

# npm
npx @opentiny/tiny-robot-cli create

# pnpm
pnpm dlx @opentiny/tiny-robot-cli create

After generation, enter the project directory:

cd <project-name>

Step 2: Configure environment variables

The generated project comes with sample configs for two LLM providers: DeepSeek and Alibaba DashScope.
Copy the sample env file and fill in your API keys:

cd <your-project-path>
cp .env.example .env
# Edit .env afterwards

Sample env config:

# Alibaba DashScope API Key (required for some MCP plugins)
VITE_ALIYUN_DASHSCOPE_KEY=

# DeepSeek API Key
VITE_DEEPSEEK_API_KEY=

The template includes 3 built-in MCP plugin examples:

12306 ticket query powered by Alibaba DashScope
Amap Maps
Generic Model Context Protocol demo

The DashScope MCP plugins require VITE_ALIYUN_DASHSCOPE_KEY.

Note: Variables prefixed with VITE_ are injected into the build output and exposed to the browser. They are only suitable for local testing and quick validation. For production, route model API calls through backend services or gateways to avoid exposing sensitive keys on the client side.

Step 3: Install dependencies and launch the project

pnpm install && pnpm dev
# Or npm install && npm run dev

Open the local address in browser:

http://localhost:5173/

You can now test the full TinyRobot demo application.

Suitable Scenarios for `create`

First-time users who want to preview complete features
Fast demo, prototype or PoC development
Internal team validation of AI dialogue solutions before production integration
Building a runnable base project for further customization

Advantage: Clear workflow without worrying about compatibility with legacy systems. Teams can verify interactions, LLM vendors, MCP plugins and business logic before formal integration.

Path 2: Inject Chat Components into Existing Projects with `add` Command

If you already maintain an admin system, enterprise workbench or internal portal, rebuilding a separate application just for AI chat is unnecessary — the add command fits perfectly here.

Step 1: Run the command in your project root

Execute the TinyRobot CLI add command inside your Vue project root:

npx @opentiny/tiny-robot-cli add chat

If your project uses a monorepo workspace, the CLI will auto-detect and prompt you to select the target package. For standard single-package projects, injection runs directly in the current directory.

Step 2: File modifications handled automatically by CLI

Based on your selected options, the CLI auto-completes repetitive integration work:

Modified File	Purpose
`src/TinyRobotChat.vue`	Generate a ready-to-use TinyRobot chat component
`main.ts` / `main.js`	Auto-import TinyRobot global styles
`.env`	Inject required environment variables
`package.json`	Install or upgrade `@opentiny/tiny-robot` dependency

The add command automates tedious repetitive work: component generation, dependency installation, style importing and environment variable setup.

This minimizes changes to existing business code. You can mount the chat component on a dedicated page to verify API calls and interactions before deeper integration with business data, permissions and layouts.

Step 3: Use the component in business pages

After generation, place TinyRobotChat.vue wherever you want the chat entry to appear.

Example usage in src/App.vue:

<script setup>
import HelloWorld from './components/HelloWorld.vue'
import TinyRobotChat from './TinyRobotChat.vue'
</script>

<template>
  <HelloWorld />
  <TinyRobotChat />
</template>

The CLI automatically injects global style imports into main.ts / main.js:

import '@opentiny/tiny-robot/dist/style.css'

You can move the generated component to drawers, modals, sidebars or specific business pages later, following your project’s component organization standards.

Step 4: Fill in environment variables

You can preview component styling without API keys, but actual LLM requests require valid keys in .env:

VITE_DEEPSEEK_API_KEY=

If a .env file already exists, the CLI merges new variables; if not, it creates one automatically.

Important reminder: Client-side environment variables are unsafe for production API keys. Always use backend proxy, authentication and rate limiting for formal deployments.

Step 5: Reinstall dependencies and start dev server

If package.json has been updated, reinstall dependencies:

pnpm install && pnpm dev
# Or npm install && npm run dev

Visit http://localhost:5173/ to view the embedded AI chat capability within your existing project.

Suitable Scenarios for `add`

Existing admin dashboards, workbenches and portal websites
Need a lightweight AI chat entry without rebuilding the entire project
Low-cost pilot validation before deep business integration
Minimal modification to preserve original project structure
Verify interaction and API flow before implementing permission, data and knowledge base features

Compared to generating a full standalone project, add acts as a lightweight plug-in entry. It does not build a complete business workflow, but lets you preview AI dialogue components running inside your real production project quickly.

Summary

TinyRobot now provides two simple CLI commands to accelerate AI dialogue integration:

Use create to generate a complete standalone project for end-to-end preview of TinyRobot interactions, model configuration and MCP plugin examples.
Use add to incrementally inject chat components into existing Vue projects with minimal disruption to your codebase, enabling fast AI capability validation.

For teams evaluating AI assistants, intelligent customer service and multi-turn dialogue systems, these two approaches cover two core stages:

Validate whether TinyRobot meets your requirements
Integrate dialogue capabilities into formal business projects

Future Roadmap & Community Contribution

TinyRobot will keep expanding AI component sets and interactive capabilities, including layout components, chain-of-thought rendering, full dialogue application components, Skill management & loading, and more.

If you are building AI assistants, intelligent workbench chat entries, or Vue3-based AI interaction components, feel free to follow and contribute to TinyRobot. Star the repository if you find it useful!

TinyRobot Repository: https://github.com/opentiny/tiny-robot
TinyRobot Documentation: https://docs.opentiny.design/tiny-robot/
OpenTiny Official Website: https://opentiny.design/

You are welcome to submit feedback via GitHub Issues, including usage confusion, bugs, and feature requests for future iterations. Your input directly shapes our product roadmap.

GenUI SDK v1.2.0 Released: Smaller Package Size, More Stable Streaming, and a Fully Upgraded Playground!

OpenTiny — Wed, 17 Jun 2026 08:27:02 +0000

Preface

GenUI SDK is a solution developed by the OpenTiny team based on Generative UI concepts. It is designed to enhance the display and interactive capabilities of large language models (LLMs). The SDK delivers full front-end and back-end integrated capabilities and complies with OpenAI specifications.

It comes with built-in renderers for both Vue and Angular frameworks, and supports custom components, interactive behaviors and theme styles. You can either build an AI chat application from scratch rapidly, or embed Generative UI capabilities into existing business systems.

We are thrilled to announce the official release of GenUI SDK v1.2.0. This update focuses on four major optimization directions: SDK lightweighting & on-demand importing, improved streaming rendering stability, comprehensive Playground upgrades, and enhanced GenUI Template experience. The SDK now runs lighter, performs more stably and is easier to configure in production environments.

Open Source Repository: github.com/opentiny/genui-sdk (Star ⭐ appreciated!)
Official Website: opentiny.design/genui-sdk

Version Feature Overview

SDK Build Optimization

On-demand importing: @opentiny/genui-sdk-vue is split into multiple entry points for separate component exports, enabling on-demand importing.

More Stable Streaming Rendering

A new isJsonComplete flag is added to the renderer component to optimize buffering for object-type content.
Enhanced SSE compatibility to support more streaming response formats.

Fully Upgraded Playground

Skill Packages: Support importing SKILL folders with progressive disclosure capability.
Added A2A (Agent-to-Agent) collaborative capabilities for agents.
Split thinking modes: Models like DeepSeek v4 now support thinking and non-thinking modes.
Import & export for chat and template history records.
Streaming update support for template JSON Patch.
Mobile UI optimization and dark mode adaptation for templates.

Other Updates

Enforced strict JSON output specifications to reduce parsing failures at the prompt level.
Fixed scope issues for loop child nodes and optimized rendering error capture & recovery.

Detailed New Features

1. On-demand Import & SDK Package Size Reduction

Previously, @opentiny/genui-sdk-vue was released as a single full package. Even if your project only used the renderer module, modules such as Chat and ConfigProvider would be bundled into the final product under poor tree-shaking configurations, resulting in redundant package bloat.

v1.2.0 supports subpath package exports, allowing you to import entries based on actual scenarios:

Subpath	Applicable Scenario
`@opentiny/genui-sdk-vue`	Default entry for combined use of Chat, Renderer and ConfigProvider
`@opentiny/genui-sdk-vue/chat`	For chat components only
`@opentiny/genui-sdk-vue/renderer`	For renderer only (custom-built chat UI)
`@opentiny/genui-sdk-vue/config-provider`	For theme and internationalization configuration
`@opentiny/genui-sdk-vue/transform-jsx`	For JSX transformation capabilities

If you only use GenuiRenderer to build a custom chat UI, simply import the dedicated renderer subpackage:

import { GenuiRenderer } from '@opentiny/genui-sdk-vue/renderer'

Besides SDK subpackaging, built-in OpenTiny components are now imported at the subpackage level.

Only components used by GenUI will be packaged, instead of importing the full @opentiny/vue library.

Components like @opentiny/vue-button, @opentiny/vue-grid and @opentiny/vue-chart-* are imported on demand to eliminate unnecessary dependencies.

Package Size Comparison

Test environment: Only GenuiRenderer (@opentiny/genui-sdk-vue/renderer) imported, built via Vite + Rollup in production mode.

Metric	Before Optimization	After Optimization
Total Bundle Size	14.67 MB	8.02 MB
`@opentiny/genui-sdk-vue` Occupied Size	~3.04 MB (20.72%)	~506 KB (6.64%)
SDK Package Reduction (Renderer Scenario)	—	~83%

Before optimization:

After optimization:

2. Import & Export of Chat History

Both chat history and template history in Playground support import and export in JSON format, facilitating context backup, debugging and cross-environment issue reproduction. Multiple records can be selected for batch export or deletion.

Export file naming rule: genui-history-YYYY-MM-DD-HH-mm-ss.json (The same naming rule applies to template history with distinguishable prefixes)
File structure: An array of conversation objects, each containing fields such as id and messages.

Import Validation & Conflict Resolution

Clear error prompts for invalid JSON files or files missing the messages array.
Automatic new ID assignment via reconcileImportedConversationIds for conflicting conversation IDs to avoid overwriting local records.

GenuiTemplateList reuses the same history toolbar, delivering a consistent import & export experience for chats and templates.

Conversation Exporting

Session Importing

3. Playground Skill Package Support

Skill Package is a major upgrade for Agent capabilities in Playground:

Single-file Skill: For quick testing, write Skill content directly in a single file.
Folder Import: Import complete SKILL directories containing SKILL.md and affiliated modules. You can view and edit all files via the tree panel after import.
Progressive Disclosure: Only skill names and descriptions are injected into system prompts. When the model needs a specific skill, it calls the get_skill_content tool to fetch full content or sub-documents on demand, preventing excessive consumption of context window space.

Demo reference: Vue Best Practices Skill → https://github.com/antfu/skills/tree/main/skills/vue-best-practices

4. Playground A2A Agent Collaboration

v1.2.0 implements A2A (Agent-to-Agent) capabilities on the Playground server. External AI agents can be registered as tools, working alongside MCP Tools and Skill Tools within a single conversation.

Playground has evolved from a single-model mode to a multi-agent architecture: the main Agent orchestrates tasks, while domain-specific Agents execute them. You can integrate existing vertical agents (customer service, data analysis, code review, etc.) without rebuilding the chat UI layer.

The current implementation is based on A2A Protocol v0.3.0, supporting the full workflow: Main Agent Orchestration → Domain Agent Execution → Result Writeback via Schema.

The official stable A2A Protocol v1.0.0 has been released. We are working on adaptation (Agent Card parsing, calling conventions, error handling, etc.) and plan to complete the upgrade in the next version for better interoperability with the A2A ecosystem.

5. Thinking & Non-Thinking Modes for Models

The system automatically detects models supporting the enable_thinking parameter (e.g. DeepSeek-V4-Flash/Pro) and splits them into two options:

{modelName}: No-Thinking Mode (thinking: { type: 'disabled' }) for faster responses.
{modelName}-thinking: Thinking Mode (thinking: { type: 'enabled' }) for in-depth reasoning.

You can select modes based on scenarios: use No-Thinking for simple UI generation to pursue speed, and Thinking Mode for complex interactive logic to guarantee quality.

6. Template Experience Optimization

Mobile & Dark Mode Adaptation

Comprehensive style optimization for GenUI Template on mobile devices, plus full adaptation for dark mode.

Optimized Prompt & JSON Patch

Built a complete JSON Patch Zod Schema based on RFC 6902, making diff results returned by LLMs more accurate and stable.

Other Notable Fixes & Improvements

New `isJsonComplete` Field for Renderer

Previously, incomplete object data (e.g. unfinished function bodies or style properties) would trigger rendering truncation errors. The newly added isJsonComplete flag allows developers to explicitly mark whether the JSON schema is complete. Combined with requiredCompleteFieldSelectors (buffer fields), you can specify mandatory fields that must be fully loaded before rendering.

Strict JSON Output Rules

Prompts now enforce standard JSON format requirements: double quotes only, no trailing commas, no comments and no single quotes. This effectively reduces parsing failures caused by non-standard JSON outputs from LLMs.

Loop Child Node Scope Fix

Resolved the issue where loop child nodes could not access scope variables such as item and index. Variables now work normally in loop rendering scenarios.

Enhanced SSE Compatibility

Added support for non-standard SSE streams where no space follows the data: prefix (e.g. data:{"content":"..."}). More third-party streaming interfaces can now be connected smoothly.

Summary

GenUI SDK v1.2.0 delivers a lighter package size, more reliable streaming rendering, more powerful Playground functions and a polished template experience.

Feel free to upgrade and experience the new version. If you encounter edge cases or have optimization suggestions, submit feedback via GitHub Issues. Star and contributions are always welcome!

Full changelog: github.com/opentiny/genui-sdk/releases

About OpenTiny NEXT

OpenTiny NEXT is an enterprise-grade intelligent front-end development solution built around Generative UI and WebMCP. It intelligently upgrades traditional products including TinyVue component library and TinyEngine low-code engine, and launches new products for Agent applications such as NEXT-SDKs for front-end, AI Extension, TinyRobot AI assistant and GenUI.

Our goal is to enable AI to understand user intentions and complete tasks autonomously, accelerating the intelligent transformation of enterprise applications.

Join the OpenTiny Community

WeChat Assistant: opentiny-official
Official Website: opentiny.design
Open Source Repository: github.com/opentiny/genui-sdk

If you want to contribute to open source, look for issues tagged with good first issue in the repository to get started!

DEV Community: OpenTiny

TinyVue v3.31 Released: New Components & Optimized Documentation With Multiple Practical Feature Upgrades

Release Overview

New Contributors

Feature Breakdown

1. New Component: SliderButtonGroup

2. Flowchart Component Docs & Examples Completed

3. Existing Component Enhancements

Key Bug Fixes

About OpenTiny NEXT

Join the OpenTiny Open Source Community

GenUI SDK v1.3.0 Released: Cross-Framework Compatibility, One-Click Component Library Switch, Fully Enhanced Renderer & Playground

Preface

Version Feature Overview

📦 Independent Core Packages & Pluggable Material System

⚡ Renderer Capability Enhancements

🚀 Cross-Framework Renderer & Full Playground Upgrades

🛡️ Experience & Stability Improvements

🧪 Early Access Preview

Detailed New Feature Breakdown

1. Independent Core Package for Reusable Low-Level Capabilities

2. Pluggable Material Architecture: One-Click Switch Between Component Libraries

3. New Chart Components

4. Major Renderer Capability Upgrades

(1) Auto-Fill Default Props for Streaming Render Fallback

(2) Refs + Asynchronous Actions for Frontend & Backend Form Validation

(3) Lifecycle Hooks for Business Data Loading

5. Comprehensive Playground Upgrades

(1) Cross-Framework One-Click Switch & Mixed Sessions

(2) A2A v1.0 Protocol Support

(3) OpenAPI to Tool Conversion

(4) Template Version Control

(5) Optional Vue Prompt Versions

(6) Bilingual Internationalization

Beta React Renderer Release

Prompt Generation Sample

Component Usage Sample

Other Stability Fixes & Optimizations

Version Summary

About OpenTiny NEXT

Join the OpenTiny Open Source Community

Bloat-Free Extensibility: The Evolution of TinyRobot — From a Simple AI Input Box to a Fully-Featured AI Input Console

Introduction

I. Sender Component Bloats As Requirements Pile Up

Stage 1: Minimalist Basic AI Input Box

Stage 2: Feature Explosion — Input Box Becomes AI Console

Stage 3: Severe UI Divergence Between PC & Mobile

Summary of Early Pain Points

II. Separate Logic & Layout: Shared Core Capabilities, Independent Terminal UI

Desktop Layout (Sufficient Screen Space, All Buttons Fully Visible)

Mobile Layout (Compact Space, Foldable Low-Frequency Features)

Cross-Device Implementation

Intermediate Summary

III. Decouple via Layered Context: Eliminate Prop Drilling

Layer 1: Global Sender Context for Universal Core Logic

Layer 2: Domain-specific Context, Independent Closed-loop Management of Attachment States

Unified Submission Registry Protocol

IV. Two-Tier API: Balance Flexibility & Development Speed

About OpenTiny NEXT

Join the OpenTiny Open Source Community

TinyRobot v0.5.0 Released: Brand-New Capabilities Including Agent Skills, Navigation & Custom Layouts Launched Simultaneously

Preface

v0.5.0 Feature Overview

In-Depth Breakdown of TinyRobot v0.5.0 New Features

1. New Feature: Agent Skills Support

Example: vue-best-practices Skill

1.1 Load Skills From Multiple Sources

1.2 Persist & Reuse Skills

1.3 Integrate Skills Into Chat Workflows

2. New Component: Anchor — Navigation For Long Content

2.1 Generate Table of Contents

2.2 Jump & Scroll Highlight

2.3 Search & Collapse Controls

3. New Component: Layout — Standard & Floating Layout Modes

3.1 Build Standard Page Structures

3.2 Unified Sidebar Interactions

3.3 Floating Workspace Extension

4. New Tool: CLI Scaffolding — One Command To Generate TinyRobot Projects

4.1 Create Full Project With create Command

4.2 Inject Chat Components Into Existing Projects With add chat

Example: `vue-best-practices` Skill

4.1 Create Full Project With `create` Command

4.2 Inject Chat Components Into Existing Projects With `add chat`