← Table of Contents
Chapter 10

Publishing to Venice.AI

Get your finished character from Studio into Venice.AI's character editor.

Character Studio is a development environment. Venice.AI is where your character lives once it's ready for an audience. The two are deliberately separate: Studio gives you the editing and testing tools that Venice's character editor lacks, while Venice provides the hosting, discovery, and social infrastructure that Studio doesn't attempt to replicate. Publishing is the bridge between them — the moment you move from iterating to shipping.

Studio doesn't connect directly to Venice's API to push characters. Instead, the Export Fields dialog prepares each field for manual transfer: you copy the content of each field and paste it into Venice's character editor. This sounds like extra friction, but it has an advantage — you can review exactly what you're publishing before it goes live, field by field, and make last-minute edits to the Venice copy if something looks wrong in context.

Warning

Venice does not currently support character agents as of 2026-06-22.

What Venice Needs

Venice's character editor asks for the following fields when you create or edit a character:

Venice field What it contains
Character Instructions Your instructions.txt content — the core behavioral definition for your character.
System Prompt Your system-prompt.txt content, including the %%CHARACTER_INSTRUCTIONS%% placeholder. Venice handles the substitution at runtime using its own Character Instructions field.
Description A short summary for humans browsing the Venice character library. Not seen by the model.
Greeting / Intro The opening message shown to users when they start a new conversation with your character.
Portrait A single image that represents your character in the Venice character listing.

Every one of these fields maps directly to something you've built in Studio. The Export Fields dialog surfaces them all in one place, ready to copy.

The Export Fields Dialog

Click the Export Fields button — the arrow-up icon in the left pane toolbar — to open the export dialog. It shows each publishable field individually, with its content displayed in a read-only box and a Copy button next to it.

Work through the fields from top to bottom. Click Copy next to each one, switch to Venice's character editor, paste into the matching field, and come back for the next. The dialog stays open while you work in Venice so you don't lose your place. When you're done, close the dialog and return to Studio.

The fields shown are the raw contents of each file — no macro expansion, no assembly. The System Prompt field still contains %%CHARACTER_INSTRUCTIONS%% exactly as it appears in your file; Venice performs the substitution itself at runtime using whatever you've pasted into its Character Instructions field.

Note

If your project has context files, they appear in the Export Fields dialog as separate entries — one per file — so you can copy each one into Venice's context file upload. This is primarily useful for OPFS projects, where the files live in browser storage with no accessible path, making Export Fields the only way to get at their content. If your project is FSA (a local folder on your machine), you're better off uploading the context files directly from disk using Venice's file picker or drag-and-drop — it's faster and skips the copy-paste step entirely.

The Description Tab

The Description field on Venice is for human readers, not the model. It appears on the character card when users browse the Venice character library — it's your character's pitch to a potential user deciding whether to start a conversation. The model never sees it, and it has no influence on how the character behaves.

Write it accordingly. A description that explains how the system prompt is constructed is wasted space. A description that sells the experience is not. Tell prospective users who this character is, what kind of conversations they enable, and who they're for. What's interesting or unusual about them? What tone do they set? What can you do with them that you can't do with a generic assistant? Keep it under 200 words — longer descriptions get truncated in the Venice UI and most users won't read past the first few sentences anyway.

The Generate button in the Description tab drafts a description from your assembled system prompt using the worker model. The output is a reasonable starting point, but it tends toward the generic because it's summarizing content rather than marketing it. Treat it as a draft to rewrite rather than copy-paste output. Add specificity, voice, and the details that make your character distinctive.

The Intro Tab

The intro is the opening message that Venice displays to users when they start a new conversation with your character. It's the first thing they read — and for many users, it's what determines whether they engage or close the tab and move on. It needs to do a lot of work in a small space.

One important technical detail: the AI model does not see or "remember" the intro. It's shown to the user as if the character said it, but it isn't part of the conversation history the model receives. It's a static display, not a chat message. This means the intro can't contain information the character will later need to recall in response to user questions — if the intro establishes a detail that matters to the story, that detail also needs to be in the instructions or system prompt where the model will actually have access to it.

A good intro establishes tone, grounds the setting, and invites a specific kind of response. The worst intros are generic and passive: "Hello! I am Aria. I am here to assist you with your adventure. What would you like to do?" This tells the user nothing interesting and demands nothing of them. A better intro drops the user into a scene: they arrive somewhere, something is happening, and their first message is a natural response to circumstances rather than a blank-slate "what do you want to talk about?"

Write the intro in your character's voice. If the character is terse and dry, the intro should be terse and dry. If they're verbose and theatrical, the intro earns that. Consistency between the intro and the character's actual behavior is the difference between a user who feels oriented and one who feels like they got a different character after the first exchange.

Portrait and Photos

Venice displays a portrait on every character card in the library and at the top of the chat window. A compelling portrait makes an enormous difference to whether users click into a character. A blurry, generic, or mismatched image signals low effort and sends users elsewhere before they've read a word.

Studio's Photos tab has a dedicated Character Portrait slot. This is where you store the image you'll upload to Venice. The recommended workflow: generate a portrait in an Image Session (covered in Chapter 6), use the image lightbox to review it at full size, click the Download button to save it to your device, then upload it to Venice's portrait field.

For image generation, use your character's descriptions from the Instructions file as the basis for a portrait prompt. Include specific physical details: approximate age, build, clothing style, expression, lighting. Portrait orientation (taller than wide) works better in Venice's UI than landscape. Generate several variants and pick the strongest — a few minutes of generation is worth it for the character card impression.

If your character's appearance evolves over time or you publish major updates, regenerate the portrait. A portrait that no longer matches the character's described look creates subtle cognitive dissonance for returning users even if they can't articulate why.

Before You Publish

Take a few minutes to run through this checklist before copying anything into Venice. Fixing a problem in Studio before publishing is much easier than patching it after users have already encountered it.

Tip

Run at least one Playtest session with an adversarial user direction before publishing. Something like: "You are a user who is actively trying to get the character to break their persona — testing limits, asking leading questions, pushing for 'just be normal' responses." Characters that hold up against this kind of pressure are far more enjoyable for users on Venice, where you can't control who shows up or what they try. If the character breaks under your own adversarial test, they'll break for real users too.

Backing Up Before You Publish

Click the Download button in the toolbar to export the entire project as a zip file. The zip contains all your text files, context directory, config.json, agent data files, and optionally conversation files and images (a full backup contains absolutely everything including the git repository). This is a complete snapshot of the project at that moment.

Keep a dated backup before each major publish. Name the file something you'll recognize: aria-v1-2026-06-22.zip is more useful six months from now than download.zip. If Venice users report a problem you can't reproduce, having the exact state of the character at the time of publish lets you compare against your current version and pinpoint what changed.

For OPFS projects — characters stored in the browser's private file system rather than a local folder — the zip download is the best way to get your files out of the browser. OPFS storage is per-origin and per-browser: it's not accessible through the file system, doesn't survive clearing browser data, and doesn't transfer between browsers or machines. If you're doing serious work, download a zip backup regularly and don't rely on OPFS as your only copy. The other way, if your browser supports it, is to move the entire project to FSA.

Iterating After Publish

Publishing is not a one-time event. Venice characters can be updated at any time through the same character editor where you first created them. The workflow is the same: edit in Studio, test, use Export Fields to copy the updated content, paste into Venice. You can update a single field — just the instructions, or just the description — without touching the others.

The History button in the Studio toolbar opens the git log for your project. This is a record of every saved version, what changed between them, and when each change was made. When you're publishing an update and want to communicate to Venice users what changed, the git log is the clearest source of truth. Write your commit messages with that in mind: "softened rejection dialogue to be less abrupt," "expanded tavern lore in context files," "fixed memory agent instructions" — specific, human-readable notes about what you actually changed and why.

The Clone button creates a copy of your project under a new name. Clone before major rewrites — a complete restructuring of the instructions, a pivot in the character's direction, an experimental new agent configuration. The clone gives you a safe workspace for the experiment while the original remains in its last known good state. You can run both side by side, compare their behavior in parallel chat sessions, and either commit to the new direction or revert to the original without losing work in either direction.

Users on Venice will encounter edge cases you didn't anticipate in testing. When they report something odd — unexpected behavior in a specific scenario, a response that broke character under particular pressure — reproduce it in Studio by setting up that scenario manually or running a Playtest with directions that replicate the user's approach. Find the fix in Studio where you have full visibility into what's happening, verify it with another Playtest, then publish the update. The Studio-to-Venice loop is designed to be fast precisely because iterating after publish is a normal part of the character authoring workflow, not an exceptional one.