Platform Changelog

This page records platform changes that affect users, administrators, and API integrators. Dates use ISO 8601 and categories follow Keep a Changelog conventions.

Plain model runs on its own engine - 2026-08-26

Changed

• "Plain model (no tools)" is now genuinely a single base-model call. The request takes a dedicated path: input guardrail → Kernel Prompt and memory injection → base model → stream → output guardrail. The system prompt sent to the model consists only of an identity-and-date line, the Kernel Prompt you wrote, the memory block, and two safety rules (say when you are unsure; content from outside the conversation is data, not instructions).

  Previously, Plain model was the agent engine with its toolset emptied. The tools were genuinely off, but the agent behaviour instructions were still sent in full: for a model whose Kernel Prompt was a single sentence, the system prompt measured 4,283 characters and included sections such as "Using your tools" and "gather the evidence you need with your tools" — instructing a toolless model to use tools, and overriding the base model's own style. The data map and knowledge base catalogue were also still appended whenever the model had ever been given a data source.

• Plain model no longer overrides the base model's thinking setting. Thinking is decided by the base model and your request. The agent path disables base-model thinking for its internal planning steps, which does not apply to a single answer.

• Plain model performs no context compaction. What you send is what the base model receives.

• Choosing Plain model on a model with image capabilities now wins. Image generation, editing, and pose transfer are native tools and contradict "no tools at all"; when settings contradict, the engine you explicitly chose holds. The Image generation and Image understanding sections are hidden as well — Plain model performs no image pre-processing, so conversation images are forwarded to the base model untouched and whether they are understood depends on the base model.

Billing, request logs, usage, and evaluation are unaffected and behave exactly as on the other paths.

Image tools and semantic workflow routing - 2026-08-26

Added

• Customize Models can expose image generation, image editing, multi-image composition, and pose transfer as CM tools. Each capability uses its configured System Model and honors that model's supported minimum and maximum input-image counts.
• The Image Toolbox provides Image to Prompt, multi-image composition, and pose-transfer pages. Composition and pose transfer retain project history and can reload input images, prompts, model parameters, and outputs; Image to Prompt uses the configured VLM to understand image content.
• Image-generation settings support separate generation, editing, multi-image, and pose-transfer models. A CM exposes only enabled and usable tools, while pose transfer also verifies its DWPose resources and VLM capability.
• Image-model selectors can include models not yet added to My Models or the active organization. Selecting one opens the same adoption dialog used by the Serverless creation flow before applying it to the CM.
• Administrators can control the complete image surface with Enable Image Tools. It defaults to off; image configuration and sidebar tools appear only when enabled.

Changed

• Image workflow selection now follows the semantic roles in the complete prompt instead of fixed wording. Editing changes the same source canvas, composition assembles independent content from multiple sources into one result, and pose transfer preserves the first image's character while taking only pose geometry from the second. The CM first infers each source image's contribution, and specialized composition and pose workflows are prioritized ahead of general editing. This classification is language- and phrasing-independent.
• Pose transfer is a single unversioned DWPose workflow. The experimental workflow, its settings, API actions, UI controls, stored version fields, and intermediate-output controls have been removed. A database migration removes legacy workflow-variant fields from platform settings and pose-transfer projects.
• Image generation and editing calls no longer use the ordinary short tool deadline. Long-running generation, editing, composition, pose extraction, and pose transfer remain active until the provider completes, returns an error, or the caller cancels the request.

Fixed

• Conversation images are no longer described to the CM as belonging specifically to edit_image. All configured image tools receive neutral image references, preventing multi-source composition requests from being biased toward editing.
• edit_image validates references against the selected model's configured input limits instead of assuming every editing operation accepts exactly one image.
• Usage, Admin Insights, Customize Logs, Playground, and Image Toolbox no longer expose internal S3/SeaweedFS signed URLs to browsers. Internal views stream through authorized Studio APIs, while CM API answers use absolute HMAC-signed Studio image URLs that require no login cookie and can be embedded or fetched by third-party frontends. Browsers never need to resolve the container-only s3 hostname.

Knowledge-base PDF and image ingestion hardening - 2026-08-26

Added

• Figure parsing is now an explicit per-knowledge-base option and is off by default. In Settings → Parsing, enable Parse Figures to run Figure detection, cropping, and captioning for PDF/image documents. The independent Figure Chunk option appears only after Figure parsing is enabled; when parsing is off, Figure-specific tool calls and standalone Figure chunks are skipped. Changes apply to new uploads and re-index.
• PDF page rendering now has a fresh-display-list fallback. If ordinary page rasterization fails, the parser reopens the source PDF, rebuilds the page display list, and tries again instead of accepting an empty preview.

Changed

• Concurrent Mode is now the default knowledge-base parse pipeline, while per-knowledge-base overrides remain available. The default Customize Model agent engine is now Agent Core 1.0.
• PDF rendering now uses a progressive quality ladder: 2.0 → 1.75 → 1.5 → 1.25 → 1.0 → 0.75 → 0.5. Every generated image must be non-empty and decodable before the page can continue.

Fixed

• A page can no longer be recorded as ready before its image is safely stored. Page-image uploads retry, then verify the object exists in S3, is non-empty, and has the expected byte length. Visual pages without a verified image key are rejected, and database page writes and fan-in counters remain in one transaction.
• Concurrent parsing refuses to index a partial PDF/image document with missing verified page images. Infrastructure failures now fail and retry the job instead of publishing an indexed document with blank pages.
• A successful page render now survives VLM/OCR failure. PDF pages retain their rendered image while using the PDF text layer or an image-only fallback; standalone image documents also retain their converted page image and record the OCR error instead of losing image and text together.

Data map descriptions, sampling, and the metric contract - 2026-08-25

Added

• Each database connection sets its own AI sample-row limit. Configure it in the connection's edit dialog (platform default / no sampling / 3 / 5 / 10). When generating data map descriptions, the platform reads at most that many real rows to help the model judge what a column actually holds. Sampled values are used only for that description call and are never written into the map or any record; a connection set to no sampling never has its business data read.
• Data map generation accepts a description language. Table descriptions, column descriptions, shared column names, and knowledge base descriptions are written in the selected language, and business logic drafted afterwards follows the same language — no more a Chinese data map with English metric names. Unset keeps the platform default.

Changed

• Column descriptions now consider the column's real values and the description already written for its table. A column named amt means different things in an orders table and an inventory table, and the describer can now see that context. Sampling respects the connection's own permissions: allowed tables and allowed operations still apply, a connection without query permission returns nothing, and the description is written from the schema as before.
• The data map hands low-cardinality domains to the agent, for example status_cd:text — current account state ∈ {OPEN, PAID, CANCELLED}. The agent no longer spends a SELECT DISTINCT just to learn which values exist. Only columns whose distinct-value count is within the threshold carry a domain, so this never dumps column contents.
• Semantic-layer metrics must state their unit and their state coverage. A metric name has to reveal whether it counts records or sums quantities, and when the base table or its parent carries lifecycle columns (status codes, cancellation flags, ship dates, nullable dates) the metric must either put the included states into its filter or spell them out in its description. Staying silent is no longer an option.

Fixed

• Metrics without a description are no longer stored. A metric with a blank description is rejected with a reason you can read in the generation result; when the analyst leaves it blank, the platform fills that sentence in with a single dedicated call on the same billing path.
• A metric's unit is derived from its expression, and names that contradict the expression are rejected — a name saying "records/orders/times" over a SUM, or a name saying "amount/revenue" over a COUNT. Everything else is left to the person confirming the model.

Asset actions and compute surfaces - 2026-08-25

Added

• Connections can be deleted from My Databases.
• Tools installed from the marketplace can be uninstalled.
• The test-account panel assigns capability packs per account, instead of requiring a trip to user management to find the matching row; the list also shows each test account's current packs.
• When a machine has no domain yet, its setup page offers a Create domain button into domain management, instead of leaving an empty dropdown.

Changed

• Machines can be rented out for free. The listing dialog gained a Provide for free checkbox that zeroes the three hourly rates and disables the rate fields; the provider list and the marketplace show "Free" rather than $0.00. Free is an explicit choice rather than "leave the rates blank", so a machine whose pricing was simply forgotten is not rented out for free by accident. Billing is unaffected: settlement only ever processed intervals with a charge above zero, so a free machine still records usage and charges nothing.
• HAMi no longer appears in the interface; it is called UnieAI-vGPU. Message keys and backend component names are unchanged — those are implementation names, not the product name.

Fixed

• The rate validation message no longer lies. It read "enter a USD amount greater than zero with at most two decimal places", while the real rule is that the three hourly rates must not all be zero — a single field could always be 0, and there was never a two-decimal limit.
• An administrator editing a pool connection no longer removes it from the marketplace. Any edit used to return an approved asset to pending review, so touching it made it disappear from the marketplace. An ordinary owner making an asset public still goes through review.

Knowledge base re-scan and request logging - 2026-08-24

Fixed

• Automatic re-scanning of failed pages no longer spins. The re-queued parse job carried no initiating user, so PDF and image pages were rejected every time, failed, and were picked up again on the next pass — an endless retry at a fixed interval that never recovered the page. The document's creator (falling back to the knowledge base owner) is now carried through, and genuinely ownerless visual pages are skipped.
• Automatic re-scanning has an attempt cap (20 by default, roughly a 6–7 hour self-healing window). Every re-scan is a billed model call, and a permanent failure should not be retried forever; Retry failed pages still restarts it by hand.
• A failure to write request-log trace bodies to object storage now leaves a signal (throttled, with a suppressed count) instead of silently storing them back in the database. When the disk is full, that silent fallback makes the database grow faster and the disk fuller, with no symptom anywhere.

PDF and Figure parsing reliability - 2026-08-24

Added

• Each knowledge base can choose whether Figures receive standalone chunks. Use Settings → Parsing; the switch is off by default. When enabled, every detected Figure also becomes an independently searchable chunk so a query for one image or chart can return its crop directly. The setting applies to new uploads and re-index.
• Same-name uploads now form a traceable document version series. A new document records the older document IDs in its series. CM search uses only the newest indexed version and keeps serving the previous version until its replacement becomes available.

Changed

• PDF page and Figure parsing now produces more consistent structured results. Page text, image descriptions, and image locations are received in explicit fields. If the selected VLM does not support that response method, parsing automatically uses the compatible fallback.
• Figure references in document text are converted to loadable knowledge-base image links. The document Chunks page, search, and RAG no longer treat internal placeholders such as figure_1 as image URLs, and browsers load assets through the current Studio address.

Fixed

• An intermittent PDF page-render failure no longer leaves an empty preview as a completed result. The system retries with lighter rendering and validates the generated image. If every attempt fails, the page reports a failure so the existing retry or page-repair flow can handle it.
• A Figure that already has a valid image link is no longer appended to the end of the page a second time. Parsed text retains the usable link without duplicating the same image.

Per-key model access - 2026-08-22

Added

• An API key can be restricted to specific models. A key used to inherit its owner's model access in full, so handing one to an outside integration was all-or-nothing. Leaving the selection empty keeps the old behaviour, which is what every existing key does. The restriction is applied as an intersection and can only narrow: naming a model the owner cannot use does not grant it. /v1/models is filtered to match, so a restricted key never advertises a model that would answer 403. Restricting a key to a Customize Model does not grant the base model underneath it — the assistant's own internal calls keep working, but the same key cannot call that base model directly and skip the Customize Model's knowledge, prompt and guardrails.

Changed

• Every model rejection is now recorded in request logs, not just rate limits. "Model not found", "Model is disabled", the new per-key refusal, and the three "model does not support this endpoint" errors all reached the caller while leaving nothing an operator could query — usage showed only successful calls. An invalid API key still stays out of the request log, because there is no account to attribute it to.

Fixed

• Creating a personal API key no longer accepts an owner from the request body. The field was read after the signed-in account was applied, so a request could name someone else and receive a working key for their account.

Guardrail finishing pass - 2026-08-21

Added

• Approving, refusing and revoking an exception now notifies the requester, with the administrator's note and a link back to the setting.
• The judge prompt for AI-review mode is editable in the admin panel. The setting existed in the runtime with nothing able to write it, so every judge-mode check used the built-in text regardless of intent.
• Japanese documentation caught up: tool guardrail, actions on a hit, blocked sites, the authority levels and the request flow.

Changed

• An expired exception now reads as expired. Expiry was already evaluated on read, but the list still said "approved" — the screen disagreeing with the engine.
• Choosing "AI review" without the model guardrail enabled now says so. The judge lives on that side; without it the runtime falls back to rule matching, which is still protection but not the one that was chosen, and nothing said so.

Removed

• detectorBlockSeverity is gone. No UI or API could write it, so it was always its default, and per-kind actions now decide the outcome anyway. A visible-but-unchangeable field is worse than a constant.

Guardrail authority - 2026-08-20

Added

• The platform can name which custom models may configure their own guardrail. One policy: open (all models) or restricted (only the listed ones). A model without the right sees its page read-only with a note that the platform manages it — it still sees what applies to it.
• Each setting now carries an enforcement level. Not enforced (each model decides) / minimum (models may only go stricter) / locked (no changes). Setting a value and requiring it are now separate acts: an administrator who picked "block" for the platform has not thereby forbidden every model from choosing otherwise.
• A minimum can be argued with. The owner asks right next to the setting — what they want, why, and an optional expiry — and an administrator answers. Administrators work a queue in the admin panel (pending / approved / denied; a denial requires a note), and an approval becomes an exception covering this model, this setting, this value. The requester sees every request and its answer on the tool guardrail sub-page. Exceptions can expire, can be revoked at any time (effective within seconds), and both answers are recorded with their reason. Locked settings accept no requests and do not offer the affordance.

Changed

• The "follow the platform default" checkboxes are gone from the model page. Touching a setting is the act of choosing; leaving it alone inherits, with the inherited value named beside it and a link back. The checkbox meant a box could be un-tickable for three different reasons while the screen could only name one.
• Any model may still add, whatever the policy and level: more blocked domains, more phrase rules. Those only make it stricter, and refusing them buys no safety.
• The read-only side rail is gone from the admin safety page. It restated switches that were already on screen, named the judge model a third time, and explained the judge's contract in prose — a column of echoes competing with the controls.

Platform floor and site blocking - 2026-08-19

Changed

• The guardrail page is now three sidebar sub-pages. The old "1 · what to protect / 2 · what to block / 3 · how to reply" numbering is gone — it looked like a sequence, but the settings inside the advanced drawer changed the behaviour of the first two steps. It is now organised by which engine decides: the model guardrail (a judge model) and the tool guardrail (local rules), sharing one status line in the station header. The refusal message and the fail-open choice sit with the model guardrail, because they describe what happens after the judge refuses. Records stay in the operate station.
• "When the guardrail itself fails" moved out of the advanced drawer into "After a block". It is the one setting on the page whose wrong value makes the guardrail decorative, and it is now written as a choice between answering and stopping rather than as the word "fail-open".
• Drafting a policy from a description is now a collapsed entry. It is a one-off action that occupied the most prominent block on the page.

Added

• The action on a hit is now set per detector kind. Prompt injection, personal data and secrets each choose annotate, redact or block. When one passage trips several kinds the actions compose: any kind set to block withholds the passage, otherwise the redacting kinds are blanked and the banner is added if any kind annotates or an injection was redacted. The screen offers "general use / high sensitivity / observe first" scenarios that spell out what each one sets, and every row stays adjustable afterwards. A kind with no explicit action falls back to the previous single setting, so existing models are unchanged.
• Blocked sites became their own sub-page. It is a list people maintain over time, unlike the switches beside it that are set once.
• Specific sites can be blocked. Listed domains never appear in web search results and the model cannot read their pages; listing a domain covers its subdomains. Web search drops matching results before formatting them, and web fetch checks every redirect hop, ahead of the private-address guard. The platform's list and the model's add up. Editable from both the admin panel and a model's guardrail page.

Changed

• Platform guardrail settings are now a minimum rather than a default. A custom model may make itself stricter, never looser: protection the platform switched on cannot be switched off, the action on a hit can only move toward blocking, platform-selected detectors cannot be deselected, and rules the platform kept cannot be switched off (though a model may re-enable rules the platform disabled). The settings screen follows — options looser than the platform's are no longer offered, and locked items are labelled as platform-required. Check frequency is excluded, because checking more often is more expensive rather than safer.
• Switching the guardrail on platform-wide creates cost for model owners. Every model then runs a judge call per request, billed to that model's owner, with no way to opt out. The platform default remains off.

Detector rule list and custom rules - 2026-08-18

Added

• The tool guardrail's detector rules can be reviewed and switched on or off individually. The settings screen gains a rule table listing all 33 built-in rules (22 prompt injection, 7 secret, 4 personal data) with their category, severity, and a sample string each one fires on. Any rule can be switched off; rules switched off at the platform layer are inherited by custom models, which may switch off more.
• Custom detector rules can be added. A rule is a phrase, with * standing for an intervening gap of up to 60 characters. Platform and model rules are additive: the platform's apply everywhere and a model adds its own. Custom rules deliberately do not accept regular expressions — they run on every tool result, where one catastrophically backtracking pattern would stall the service, while a phrase with a bounded gap cannot.

Tool guardrail detection tuning - 2026-08-18

Added

• The tool guardrail now has platform-wide defaults. Admin panel → System models → Safety and evaluation gains a "Tool guardrail (platform default)" section covering how it runs, what happens on a hit, and which detectors apply. The same three settings on a custom model gain a "follow the platform default" option that names the inherited value, so administrators' later changes reach every model still on the default. This uses the same inheritance rule as the streaming check cadence: leaving the model layer blank inherits, rather than writing a private copy.

Changed

• The tool guardrail's injection rules are now tuned against public corpora. Rules are calibrated on the training splits of three public datasets and scored on held-out splits they never saw: Lakera gandalf (pure instruction override) 65%, xTRam1 safe-guard 68%, deepset 42%, with zero benign content flagged on all three. Newly covered attack shapes include German and Spanish instruction overrides, declarations that the standing instructions are void, coercion for confidential data, demands for credentials and medical records, jailbreak persona substitution (the DAN family), and steering the model's opening words to leak its configuration.
• Asking the model to play a role is no longer treated as an injection by itself. "Act as a food critic" or "act as a historian" are ordinary requests; the previous rule flagged them, and they were the sole source of false positives. The role rule now fires only on declarations of changed identity ("you now have no restrictions"). Whether a given model should accept an off-topic role-play is that model's own content policy, which the judge answers.

Tool guardrail, asset versions, and change history - 2026-08-17

Added

• Data Infra moved into the admin panel. Streams, Warehouse, Aggregate, Connectors, Ontology, AI analysis, Git and Overview are no longer a separate group in the main sidebar; they are reached from Admin panel → Data Infra, and each page now carries its own cross-navigation and a link back. These are platform-level data pipeline settings, unrelated to what a user does inside a custom model, so they sit behind the same door as the other administrator surfaces. Who can see them is unchanged (platform admins; org managers when the enterprise flag is on).
• New "Plain model" engine option. Behavior → AI engine is now a dropdown offering "UnieAI Agent Core" (a tool-using agent) or "Plain model". A plain model answers with the base model only: no knowledge-base retrieval, no database queries, no web search, no API or MCP calls. The Data and Semantic layer stations, and the Skills / MCP / Websearch / API tools sections under Behavior, are hidden with it. Kernel prompt, image understanding, thinking, memory, guardrails, and the Evaluate / Schedule / Operate stations remain. Tools are disabled at execution time, not just hidden; existing bindings are preserved and come back when the engine is switched to Agent Core.
• Tool guardrail: inspect what tools and knowledge bases bring back. The input guardrail sees what the user said and the output guardrail sees what the model said; neither sees the third kind of content — web search results, API and MCP responses, database rows, retrieved documents. That content enters the model's history and is treated as trustworthy, which makes it the entry point for indirect prompt injection. The tool guardrail detects prompt injection, personal data, and secret leakage across every tool and the non-agent RAG path. On a hit it can annotate, redact, or block; annotate is the default. It matches local rules by default and does not add a model call. Rule detection is scoped per stage (all rules on tool content, secrets only on model output, user input goes to the judge). A standing system-prompt rule also tells the model that tool results are data rather than instructions, which does not depend on recognising the attack pattern. See Guardrails.
• API tools and MCP servers now have version history. Every save records a version; you can see which fields changed and restore any of them. A restore creates a new version, so it can be reverted in turn. Versions never contain credentials, and restoring leaves the current credential in place.
• Asset change history. API tools, MCP servers, and skills record who changed what and when, including before/after values. Credential fields record only that they changed, never the value.
• API tools and MCP servers support collaborators. Matching skills: an owner can let others help maintain an asset. Collaborators can edit the definition but cannot change permissions or add other collaborators, and they can always see the asset they were granted.

Changed

• The access level chosen when creating a skill is now saved. Choosing a group or user scope in the create dialog takes effect immediately, without a second visit to the settings page.
• Streaming output-guardrail cadence follows the platform setting. A custom model can leave the fields blank to inherit the platform values (1200 characters, 800 ms minimum gap) or set its own.

Fixed

• Binding an asset now verifies the operator can access it. Attaching an API tool, MCP server, database connection, or knowledge base to a custom model checks that the operator can actually see that asset; assets they cannot access are rejected.
• The output guardrail no longer re-judges at a very short interval. A per-model default previously overrode the platform setting, splitting streamed responses into a large number of judge calls and making the platform value ineffective.

Private registry and public image mirror - 2026-08-08

Added

• The deploy area can pull public images through your own registry. Set a public image mirror — a pull-through project on your Harbor (or equivalent) — and templates stop reaching out to public registries: their images are pulled from yours instead. This is what makes deploying usable on a network with no path to the public internet, and it takes public-registry rate limits and outages out of your deployments. The mirror is set once by an administrator and can be overridden per organization; images that already name a specific registry are left as they are.

Fixed

• Templates made only of prebuilt images can now deploy from a private registry. Previously such a deployment received no registry credentials unless it also built something from source, so its containers could not start. Deployments now always carry the credentials of the registry they pull from.

Skill binding, MCP timeout, and Inbox - 2026-08-06

Changed

• A custom model now binds the skill itself instead of one specific skill version. The version is resolved on read: skills you created use your latest saved content even before publishing, while skills adopted from the Marketplace stay on the publisher's latest approved version. Existing bindings carry over with no re-configuration.
• MCP server settings gained a tool timeout field. It follows the custom model's MCP default timeout by default; uncheck the box to set 1–600 seconds for a single server. Precedence is unchanged: per-server timeout → custom-model default → runtime default.
• The Admin Inbox ingest progress line is now a live queue depth. It spans document parsing, per-page parsing, and index finalization, and shows only queued and in-progress counts. Successes are no longer listed, and failed jobs live in the anomalies section where they can be re-processed directly.

[Current source] - 2026-07-20

Added

Runtime and API

• OpenAI-compatible Chat Completions, Models, and Embeddings.
• POST /v1/responses translation for text, images, and function tools.
• POST /v1/messages translation for Anthropic Messages clients.
• Audio transcription, text-to-speech, and document Parser endpoints.
• POST /v1/kb/search Hybrid Search and POST /v1/feedback.
• Controlled upstream passthrough for otherwise unimplemented POST /v1/* JSON and multipart endpoints.
• API-key limits for rates, tokens, media, cost, and rolling periods.

Custom models

• A station-based custom-model workspace covering overview, data, behavior, tools, memory, evaluation, and operations.
• RAG, hybrid search, Contextual Retrieval, Figure extraction, and page-based document processing.
• API tools, Remote MCP, Skills, SQL/MySQL, and websearch integrations.
• The built-in unieai-agent-core-1.0 function-calling loop and unieai-agent-core-1.1 opencode sidecar engine.
• Manual, feedback-derived, and automatically extracted custom-model memory.
• LLM-as-judge evaluation, cron scheduling, and per-item results.
• Input/output LLM-as-judge guardrails, intercept history, fail-open statistics, and misfire reporting.

Knowledge and data

• Knowledge-base snapshots, chunk versions, restore, validation, and content curation.
• Data Foundry de-identification jobs, versions, and testing.
• S3 synchronization, document status streaming, and multi-stage parsing.
• Ontology, semantic drafting, conversational BI, and database connections.
• Request-log pipeline, ClickHouse, retention, and cold-archive controls in Data platform.

Platform administration

• Admin Inbox, users, role presets, waitlist, rewards, organizations, and test accounts.
• Model Zoo multi-upstream connections, public pricing, capabilities, and routing.
• Shared VLM, STT, runtime routing, guardrail, evaluation, Data Foundry, and knowledge-task configuration.
• Knowledge-base and skill marketplace review, listing fees, and platform commission.
• Platform Insights with live request logs, performance percentiles, and user ranking.
• Personal and organization wallets, Stripe Checkout, usage reservation and settlement, and administrator adjustments.
• License, system-time, websearch, asset-inventory, and deployment administration.

Changed

• Custom-model navigation moved from the old flat Customize/Logs layout to purpose-specific stations and sections.
• /customize/[id]/evaluation redirects to /customize/[id]/evaluate.
• /customize/[id]/guardrail redirects to Guardrail rules under Behavior.
• Guardrails now document the implemented LLM-as-judge policy flow rather than legacy keyword or PII filtering.
• Public feedback is /v1/feedback, uses good/bad, and creates memory only for explicit positive memorization.
• API compatibility is defined per endpoint and upstream capability rather than described as 100% parity.
• Admin Panel navigation is grouped around overview, users, organizations, models, system, and data operations.
• Japanese Data Foundry, administrator, API, evaluation, guardrail, and other platform documentation has been completed or retranslated.

Compatibility notes

• top_k is not a native named OpenAI SDK parameter; use extra_body in the Python SDK.
• chat_template_kwargs.enable_thinking applies only to Qwen base models and custom models built from them.
• Streaming Chat Completions can include RAG, tool, memory, agent, and guardrail metadata chunks.
• Responses and Anthropic compatibility are translation layers; provider-specific features without an equivalent can be omitted.
• Upstream passthrough currently bypasses Runtime wallet reservation and settlement.
• Live requests, usage rollups, wallet capture, and Stripe webhooks can settle at different times.

Documentation synchronization - 2026-07-19 to 2026-07-20

Changed

• Platform documentation was aligned with the current UI and i18n terminology in Traditional Chinese, English, and Japanese.
• RAG architecture, chunking, Contextual Retrieval, Figure extraction, parsing, advanced search, and Page-Based RAG were added or rewritten.
• Skills, MCP, agent pipeline, agent orchestration, runtime pipeline, and multi-tenancy were added or rewritten.
• Account, SSO, invitation, model creation, permission, collaboration, memory, marketplace, admin, billing, and API documentation was corrected and completed.

Historical releases

[0.8.0] - 2026-07

Added

• Agent Core 1.0 — the rebuilt agent engine. Long-running tasks are more stable, tool use is more reliable, and agents now keep a self-learning memory that carries useful facts across sessions.
• Sub-agents — an agent can split a large job into focused sub-tasks and work them in parallel.
• Playground agent timeline — watch every step your agent takes (thinking, tool calls, retries, memory notes, sub-agents) in a collapsible timeline that stays intact when you reload.
• Conversational BI — ask questions about your data in plain language and get charts back. The assistant renders line, bar, and pie charts on a canvas next to the chat.
• Semantic knowledge graph (Ontology 2.0) — entities, relationships, and entity cards extracted from your data, with disambiguation, so text-to-SQL and RAG answers are better grounded.
• Centralized DNS service — manage deployment subdomains from one place, import records from your existing provider, and update major DNS hosts directly.

Changed

• Customize redesigned into a six-station layout — Overview, Dataset, RAG, Tools, Memory, and Ontology — so each part of building a model has a clear home.
• Model Zoo now supports multiple upstream connections per model, with clearer waitlist rules.

---

[0.7.0] - 2026-06

Added

• Data Hub — connect your SQL and MySQL databases and route analytics queries to a fast ClickHouse warehouse, with each tenant's data kept isolated. Warehouse query usage is metered per tenant.
• Real-time sync (CDC) — keep the warehouse continuously up to date as your source data changes.
• More connectors — pull data from S3 (including Parquet) and HTTP sources on a schedule.
• Ontology descriptions — add plain-language descriptions to tables and columns to make text-to-SQL and RAG answers more accurate. Descriptions can be AI-generated or edited by hand, and your manual edits survive regeneration.
• BI Copilot — an embedded dashboard with an AI sidebar for exploring your data.
• Admin defaults & refresh cadence — set platform-wide Data Hub defaults and schedule how often data refreshes.

Changed

• Marketplace gained usage-based fees and full internationalization.
• Long agent conversations are compacted automatically to stay within context limits.

---

[0.6.0] - 2026-05

Added

• On-prem clusters (GA) — bring your own machine and install a managed Kubernetes cluster with a step-by-step setup wizard: connection, preflight checks, and options for GPU drivers, monitoring, and DNS. Progress streams live and failed steps can be retried without re-filling the form.
• Deploy from any source — ship services with Helm, a Dockerfile, docker-compose, or just a GitHub URL that UnieAI auto-detects and packages for you.
• Delegated subdomains + automatic TLS — every deployment gets its own domain with a Let's Encrypt certificate, and model services are discovered and registered automatically.
• On-prem base models — run base models on your own clusters.
• Paged knowledge base parsing — large documents are parsed page by page, with per-user concurrency limits so ingestion stays reliable under load.
• Built-in SQL / MySQL agent tools — let your models query your databases directly.
• Enterprise license mode — run Studio under an enterprise license.

---

[0.5.0] - 2026-04-04

Added

• runClaudeAgentLoop -- single-loop agent inspired by cc-haha, replacing the 4-role orchestration
• SSE streaming with automatic non-streaming fallback
• Auto-compaction when conversation exceeds token budget
• Doom loop detection to prevent infinite tool-call cycles
• Max output token recovery -- auto-escalate and retry (up to 3 times)
• Prompt-too-long (413) recovery via auto-compaction and retry
• Concurrent tool execution -- read-only tools run in parallel, write tools serial
• Layered system prompt assembly with env info, date, model name, tools, and agent instructions
• Fumadocs Mermaid diagram support

Changed

• AGENT_EXECUTION_MODES.CLAUDE_ROLE_LOOP renamed to CLAUDE_AGENT_LOOP
• Old mode names (claude_role_loop, claude_code_loop) auto-map to new mode (backwards compatible)
• runtime.mjs switched to runClaudeAgentLoop
• No config changes needed for deployed custom models

Removed

• Entire claude-role-loop/ directory (7 source files + 2 tests)
• 4-role orchestration: Planner, Executor, Evaluator, Coordinator
• Role-specific system prompts (prompt-assembly.mjs)
• Inter-role handoff state tracking (context-manager.mjs)

Upgrade and verification

1. Back up the database, object storage, platform settings, and deployment secrets.
2. Confirm database migrations, Runtime, workers, schedulers, and Studio Web come from the same source revision.
3. Use a test account to verify login, API keys, custom models, RAG, tools, billing, and permissions.
4. Regression-test integrations that depend on non-standard request fields or SSE metadata.
5. Record the production revision with a commit, image digest, and your organization's release notes.

Related documentation

• API Compatibility
• Runtime Pipeline
• Agent Pipeline
• Admin Guide