The Chat Interface
The chat is the heart of Vulcan. Everything — building, changing, fixing — happens through conversation. Here's how to get the most out of it.
How the AI thinks
Before responding to anything, the AI reads your entire current codebase. It knows what your app already does before you type a single word. This means you don't need to re-explain your app every message — just focus on what you want changed.
In long sessions, old messages fade out. The AI can only hold so much in its memory at once. After many turns, the earliest messages in the conversation are quietly dropped to make room for recent ones. The AI always has your full codebase and recent context — but if you mentioned something very early in a session and reference it 30+ turns later, it may not remember. If that happens, just restate it.
Message length limit. Individual messages are capped at 50,000 characters (roughly 35–40 pages of text). If you need to share a very long document, ask the AI to help you break it into sections, or paste only the relevant part.
Stopping the AI mid-turn
While the AI is working, the Send button turns into a Stop button (square icon). Clicking it cancels the current turn immediately — no file changes are saved, no deploy is triggered.
This is useful when you realize you sent the wrong message or the AI is heading in the wrong direction. Just stop it and send a more specific request.
Retrying a response
After every completed response, a small ↺ Retry button appears at the bottom of the message. Click it to re-send the same prompt if the response wasn't quite right. Vulcan will run the request again and you'll get a fresh response. The button disappears when you send a new message.
Attaching files
Click the paperclip (📎) icon next to the chat input to attach a file to the project. Supported formats: PDF, plain text (.txt), HTML, Markdown, CSV, and images (JPEG, PNG, WebP, GIF). Max 10 MB per file; up to 10 files per project.
Attached files appear as chips above the input and are included in Claude's context on every turn — useful for specs, schemas, wireframes, reference data, or screenshots. They persist across sessions until you explicitly remove them (click the × on a chip).
Tip: If you have a Word doc or Excel spreadsheet, use "Export as PDF" or "Save as CSV" first — those formats are supported directly.
The preview panel
The panel on the right side of the App Builder has three tabs:
Build Logs (default) Shows the output from the last build attempt — esbuild errors, missing imports, type errors. If a deploy fails, the reason is here. Includes a "Send to Chat" button to pipe the error directly to the AI. Clears automatically when the next successful deploy completes.
Console Logs Captures console.log, console.warn, and console.error calls from your app's frontend as you interact with the live preview. Useful for debugging JavaScript errors that don't show up in the backend logs.
Server Logs Streams live logs from the deployed Worker — backend console.log calls, errors, and request traces. Each cron job invocation also appears here. This is the first place to look when something goes wrong on the backend.
Logs are not stored. They stream in real time while the tab is open. If you close the tab, switch projects, or reload the page, they're gone. If you see something important, copy it before navigating away.
What to say
Describing new features
Be direct about what you want the user experience to be, not the technical implementation:
Focus on what you want the experience to be, not how to build it:
- "I need to track employees with their name, department, and start date"
- "I want to be able to add new items from a form at the top"
- "The table gets too long — show 20 rows at a time with next/prev buttons"
- "The filters I set should be remembered if I refresh the page"
- "The page should show something while data is loading so it doesn't look broken"
Prompts by scenario
Adding a new field or column:
"Add a 'priority' field to each task — high, medium, or low. Show it as a colored badge in the table."
Changing how something looks:
"The status column labels are hard to read — make 'Complete' green, 'Pending' yellow, and 'Blocked' red."
"The page feels cluttered. Can we simplify the header and make the main table take up more of the screen?"
Adding filtering or search:
"Add a dropdown above the table so I can filter by department. Default to showing all."
"Add a search bar that filters the list as I type — it should match on name and email."
Adding data actions:
"Let me edit existing records, not just add new ones. Clicking a row should open an edit form."
"Add a confirmation dialog before deleting anything. Something like 'Are you sure you want to delete this?'"
Connecting to another system:
"I want to pull in driver data from our internal API at [URL] — show their name and current status."
"When a new exception is logged, send an email to the dispatch team."
Restricting access:
"Only users with the role 'manager' should be able to approve requests. Everyone else should see a disabled button."
"Add a 'My items only' toggle — when on, only show rows assigned to the currently logged-in user."
Requesting changes
Be specific about what's wrong:
- "The button at the top right is hard to see — make it more prominent"
- "The search doesn't work when I type partial words — fix that"
- "Move the filters above the table, not below"
- "The form resets when I save — it should stay open so I can add more"
Asking questions
You can ask the AI anything about your app:
- "What does the delete button actually do to the data?"
- "How would I add an export to CSV feature?"
- "Can this app support multiple users editing at the same time?"
- "What happens to the data if I roll back to an earlier version?"
When things go wrong
The AI makes mistakes. Here's how to handle the most common ones.
The app shows an error or blank page
First, check the Server Logs tab (in the workspace panel). It shows any errors coming from the backend. Copy the error and paste it into the chat:
"I'm getting this error in the server logs: [paste error]. Can you fix it?"
If there are no server logs, the problem is probably in the frontend. Describe what you see:
"The page is completely blank after the last change. The browser console shows 'Uncaught TypeError: Cannot read properties of undefined'. Can you fix it?"
A feature doesn't work right
Describe what you expected vs what actually happened:
"When I click 'Save', the form should close and the new item should appear in the table. Instead, the form closes but the table doesn't update until I refresh the page."
"The filter dropdown doesn't seem to work — when I pick 'Pending', it still shows all items including completed ones."
Concrete details matter. "It doesn't work" is hard to fix. "It does X but I expected Y" is easy.
The AI misunderstood your request
This happens. If the change is completely wrong, just say so and be more specific:
"That's not quite what I meant. I wanted the filter to be a dropdown above the table, not a sidebar. Can we redo that?"
"I asked for a delete button but you added an archive button. I actually want the record permanently removed."
The AI made a big mess
Sometimes a request for a "small" change turns into the AI rewriting half the app — and breaking things in the process. A few options:
Roll back to the last good version:
"Let's undo that last change and go back to how it was before. I'll describe what I want differently."
The AI can revert the code to how it was before its last change. For bigger rollbacks, use Versions & Rollback.
Narrow the scope:
"You changed a lot of things I didn't ask for. Can we focus only on [the specific thing] and leave the rest of the app alone?"
Ask for a plan before it writes code:
"Before you make any changes, explain what you're planning to do and why. I want to make sure we're on the same page."
The styling looks broken or inconsistent
"The new section doesn't match the rest of the app — the font is different and the spacing is off. Make it consistent with the existing style."
"On mobile the table is getting cut off. Can you make it scrollable horizontally instead?"
The AI keeps making the same mistake
If you've corrected something multiple times and it keeps regressing:
"You keep reverting the button back to gray. It needs to stay blue. Please check the current code before making changes."
"Every time you update the form, you remove the validation I added. Can you make sure the validation stays in place?"
Tips for better results
Build incrementally — don't try to describe the whole app upfront
This is the single most important thing to understand about working with Vulcan.
The AI is good at building one thing well. It is not good at building an entire app in one shot. If your first message is "build me a complete ops dashboard with driver tracking, exception logging, route management, reporting, and a settings page" — you'll get something that technically runs but is likely shallow, inconsistent, or broken in places you won't notice until later.
The pattern that works:
- Start with the core — the one thing the app absolutely needs to do
- Check the preview. Does it work? Does it look right?
- Add the next feature
- Repeat
First message: "A table of delivery exceptions with a form to add new ones — driver name, route, issue type." Second message: "Add a way to mark exceptions as resolved." Third message: "Add a filter to show only open exceptions."
Each step is small enough that if something goes wrong, it's easy to spot and fix. Stack five broken features on top of each other and you're debugging a mess.
The AI will make mistakes. That's expected, not a failure. The workflow is designed around it — preview after every turn, undo if something goes wrong, iterate. The goal isn't a perfect first attempt; it's a working app at the end of a session.
Start with the what, not the how
Describe the outcome you want, not how to build it. The AI figures out the how.
"I want drivers to be able to mark stops as complete from their phone" is great. "Use localStorage to persist stop status" — skip this unless you have a strong reason.
One thing at a time
Big requests ("rebuild the whole UI and add 5 new features") can lead to messy results. It's faster and cleaner to do one meaningful thing per message, then check the preview before moving on.
Use the preview
After every change, click around in the preview panel before requesting more changes. Catching a problem early saves a lot of back-and-forth.
Undo the last change
If a turn went wrong, you can ask the AI to undo it:
"Undo that last change" "Revert to how it was before"
The AI will restore the files it just edited back to their previous state. This is the fastest way to recover from a single bad turn. For bigger rollbacks — multiple turns, or restoring to a point from earlier in a session — use Versions & Rollback instead.
Save a version before big changes
If you're about to ask for a major redesign or a significant feature addition, save a named version first. That way, if the AI goes sideways, you have a clean checkpoint to roll back to.
→ How to save and restore versions
When the AI asks questions
If the AI asks clarifying questions before writing code, answer them. It's not stalling — it's trying to avoid building the wrong thing.
Why each turn takes longer than other AI tools
If you've used AI coding tools like Claude Code, Cursor, or GitHub Copilot, Vulcan will feel slower per message. That's intentional — and the reason is what's happening in the background.
When you send a message in another AI tool, the AI writes some code and stops. You still have to run it, test it, debug it, and figure out how to deploy it yourself.
When you send a message in Vulcan, the AI writes the code and then ships it live. After every turn, Vulcan automatically:
- Compiles your app and checks for errors
- Deploys the updated app to your preview URL
- Runs a quick health check to make sure it actually started
That whole process takes 15–30 seconds after the AI finishes responding. So a turn that feels "slow" is one where your app just got built and deployed — not just described.
The tradeoff: you end up with a live, working app at the end of each message instead of a pile of code files you'd have to figure out on your own.
Bringing your own Anthropic API key
By default, Vulcan uses a shared platform API key for all AI chat sessions. If you want to use your own Anthropic account instead — to use your own quota, or a specific model tier — you can add your own key in Vulcan Settings.
Your key is encrypted at rest and never appears in your code or chat history. When set, it takes precedence over the platform key for your sessions. You can remove it at any time to revert to the shared key.
The AI's limitations
- It can't browse the internet or fetch live data on its own (unless your app explicitly calls an external API).
- It doesn't remember previous projects. Each project's context is self-contained.
- It can make mistakes. If something looks wrong, just point it out and it'll fix it. If the AI says it fixed something, always verify in the preview — it can confirm the code is valid but only you can confirm the behavior is right.
- Complex apps take multiple turns. If you're building something substantial, expect to go back and forth 5–10 times to get it right. That's normal.
- It works best on focused requests. The more you ask for in one message, the more chances there are for something to go wrong.
Concurrent sessions
You can have up to 3 chat sessions running at the same time across different projects. If you hit that limit, wait for one to finish before starting another.