Frequently Asked Questions

Verdent is a standalone application with features designed for parallel development:

Both share:

• Same credit pool
• Same account
• Same AI capabilities
• Same rule systems (VERDENT.md, AGENTS.md)

Yes. They're independent applications that share your credit pool and account. Use whichever fits your workflow:

• Desktop for parallel development, multi-project work
• VS Code extension for integration with existing VS Code workflow

Don't work on the same files simultaneously in both tools.

No. Verdent requires an active internet connection. All AI processing happens in the cloud through Verdent's API.

Note: 32-bit operating systems are not supported. Windows 7/8.x are not supported. Linux is not currently supported.

Minimum requirements:

• Active Verdent subscription
• Internet connection
• Git 2.20+ (2.35+ recommended)

Platform support: macOS (full), Windows (beta)

Yes. Verdent and the VS Code extension are independent applications. You can use both, and they share the same credit pool and account.

Verdent checks for updates automatically on launch. When an update is available:

1. A notification appears
2. Click Update to download and install
3. Restart the application

You can also check manually: Help → Check for Updates

macOS: Drag Verdent from Applications to Trash

Windows: Use Settings → Apps → Verdent → Uninstall or Control Panel → Programs and Features

Git is a free, open-source version control system that tracks changes to your code. It allows you to save snapshots of your project, collaborate with others, and manage different versions of your work. Verdent uses Git's worktree feature to create isolated workspaces for parallel agent execution.

Git worktree functionality has improved significantly in recent versions:

• Git 2.20+: Basic worktree support stability
• Git 2.30+: Improved worktree management commands
• Git 2.35+: Better worktree repair and move operations

Older versions may work but could have issues with worktree management.

No. Git worktrees are fundamental to Verdent's parallel execution architecture. Without Git, the application cannot:

• Create isolated workspaces
• Run parallel agents
• Manage branches for tasks
• Rebase completed work

Verdent handles this automatically. If your project doesn't have Git initialized, Verdent creates its own Git repository for tracking changes and enabling workspace isolation.

Run git --version in your terminal. You should see a version number 2.20 or higher. If not installed, see the Git Installation guide.

Drag the borders between panels to resize. Your layout preferences are saved automatically.

Currently, all panels remain within the main window. This helps maintain context between chat, editor, and terminal.

A workspace is an isolated git worktree for parallel work. A task is a conversation thread within a workspace. Multiple tasks can run in the same workspace and share the workspace file state.

Click All Workspaces in the top bar to see and switch between active workspaces.

Click Task Changes in the middle panel to view all files changed within the current task. This shows modifications for the current workspace only, not across different workspaces.

Context Remaining shows how much model context is left for the current conversation. When context runs low, consider starting a new task.

Use Source Control (Ctrl+Shift+G / Cmd+Shift+G) to discard or revert specific file changes.

Hover over any message in the chat and click Rollback to this point to revert the conversation to that point in time.

Yes. Click Open in VS Code (Ctrl+E / Cmd+E) in the workspace bar to open the current workspace in VS Code.

No. Each project can only be open once. Use workspaces within the project for different branches or tasks.

Git state (commits, branches) is preserved as normal. Task history persists between sessions.

No. Verdent creates a git repository automatically if your project doesn't have one.

They continue running. All workspace states, task conversations, and agent progress are preserved.

Click Current Project in the Top Bar to see and switch to recent projects.

No. Verdent does not support opening a project that is inside another open project. Each project must be a separate, non-nested directory.

Base Workspace:

• Your main working directory (usually master branch)
• Reference point for creating worktrees
• Where rebased work ends up
• Should stay clean and stable

Worktrees:

• Isolated directories for specific tasks
• Each has its own branch
• Complete copy of working files
• Can be deleted after rebasing

Alternatively, use standard git commands:

# From feature branch
git rebase master

No. Each worktree is a complete copy of working files. You need to install dependencies in each worktree:

# After creating worktree
npm install  # or pip install, etc.

Some package managers support shared caches to speed up installation.

Worktrees persist on disk as git worktrees. When you reopen the project:

• Verdent detects existing worktrees
• Restores their state in the interface
• You can continue where you left off

Each workspace is a git worktree that shares git objects with the base. Storage is approximately the size of your working files (excluding .git), plus any workspace-specific dependencies.

Yes. Right-click the workspace and select Delete Workspace, or use Workspace → Delete. Committed changes remain in git history; uncommitted changes are lost.

Uncommitted changes are permanently lost. Always commit or stash important changes before deleting a workspace.

Yes. Tasks share the workspace file state, and context is preserved when switching between tasks.

No. Each task has its own conversation context. They share file state if in the same workspace, but not conversation memory.

Task history persists between sessions. You can resume tasks where you left off when you reopen Verdent.

Tasks don't automatically know about other tasks. Reference files that were modified, summarize previous decisions, or use @-mentions to include specific files.

Yes. Each task has its own agent configuration including model selection.

Hover over the task in the task list and click the Delete button.

No. Tasks in different workspaces are fully isolated with no shared files or context.

There's no hard limit. Practically, keep active tasks focused; archive completed tasks to maintain organization.

Verdent doesn't impose a hard limit. Practical limits depend on:

• System resources: Memory and CPU
• Credits: Each agent consumes credits
• Git worktrees: Git handles many efficiently

Recommendation: 2-4 parallel agents work well for most users and machines.

Yes. All agents draw from your shared credit pool. Running multiple agents simultaneously consumes credits faster.

Tip: Use Claude Haiku 4.5 for routine parallel tasks to conserve credits.

No. Each agent works in its own worktree with isolated files. Agents cannot:

• Read other agents' uncommitted changes
• Modify files in other worktrees
• Interfere with each other's operations

This isolation prevents conflicts during parallel work.

Since each agent works in a separate worktree:

• No conflicts during development
• Conflicts only appear during rebase
• Standard git rebase conflict resolution applies

Best practice: Assign independent tasks to parallel agents to minimize rebase conflicts.

No. Each agent has completely isolated context. Results from one agent don't automatically transfer to another.

Each workspace has its own copy. Conflicts are resolved during rebase, not during development. Use standard git conflict resolution.

Plan Mode is a read-only execution mode where Verdent analyzes code, conducts research, and creates detailed implementation plans without modifying files or executing commands. After generating a plan, Verdent presents options to edit the plan or start building. The agent can ask clarifying questions to remove uncertainty before execution. This mode is ideal for complex tasks where you want to review the approach before committing to changes.

No. Plan Mode is strictly read-only:

• Verdent can read files, search code, and analyze your codebase
• No file writes, edits, or deletions occur during Plan Mode
• Plans are displayed in the Chat View only
• Code execution begins only after you explicitly approve and switch to Agent Mode

Safety guarantee: Plan Mode cannot accidentally modify your code. It's designed for safe exploration and strategy development.

Yes. Press Shift+Tab or Ctrl+. to switch. Switching to Plan Mode stops execution and enters read-only analysis. Switching to Agent Mode enables execution.

Press Shift+Tab or Ctrl+. to toggle between Plan Mode and Agent Mode. You can also click the Switch Mode button in the input box.

Use Plan Mode for:

• Large refactorings or architectural changes
• Multi-file modifications where you want to review scope before execution
• Complex tasks where you're uncertain about requirements
• When you want Verdent to interview you with clarifying questions before implementation

Skip Plan Mode for:

• Simple, well-defined tasks
• Quick bug fixes
• Routine operations

Yes. Each agent in each workspace has independent mode settings. One workspace can use Plan Mode while another uses Agent Mode simultaneously.

Yes. Plan Mode operations consume credits based on the model used and tokens processed, similar to Agent Mode, though typically less since no execution occurs.

Yes. After creating a plan in Plan Mode, switch to Agent Mode to execute it. The plan guides the execution.

Yes. Use the Skip Clarifications option to proceed with Verdent's best judgment when requirements are clear enough.

Ask Verdent to save the plan as a markdown file for future reference.

You can ask Verdent to revise the plan in Plan Mode. Once satisfied, switch to Agent Mode to execute.

The unit of measurement for context windows. Tokens represent pieces of text (words, parts of words, or characters) that the AI model processes. Context limits are measured in tokens rather than characters or words, with typical conversations consuming thousands of tokens.

Standard models have 200K token context windows sufficient for most tasks. Extended context (1M tokens, 5x larger) is available for large codebases with 1000+ files, complex multi-file refactoring, or long development sessions.

Strategies:

1. Strategic file reading: Use line ranges for large files
2. Delegate to subagents: For background research
3. Search before reading: Use grep to identify relevant files
4. Break operations: Use todo lists to track multi-step tasks

Rule of thumb: Files over 500 lines should use line ranges.

You must manually start a new session to reset context. Verdent does not automatically clear context. Best practice: reset after completing an atomic unit of work, testing, and committing to version control.

Yes. Extended context models process more tokens, which increases credit consumption. Use standard context for routine tasks.

Start a new task. Each task begins with fresh context.

Task conversation history persists, but the active context window is rebuilt when you resume a task.

Use subagents for quick, focused tasks like validation or code review. Use the main agent for complex investigations requiring full context.

No. Subagents have isolated context windows. Only the final results are returned to the main agent.

Yes, when customizing subagents, you can configure which model to use.

• Provide clear, specific requirements
• Include relevant code context with @-mentions
• Use Plan Mode for complex features
• Review and iterate on generated code

Yes. Ask Verdent to write tests for specific functions or modules. It can generate unit tests, integration tests, and test fixtures.

Use Plan Mode to preview changes, ensure test coverage before refactoring, and commit frequently. If issues occur, use git to revert to a working state.

Automated code review adds minimal time while catching issues early. Enable Auto Generate Code Review in Settings → Chat for automatic reviews.

Yes. Code review generation uses credits based on the model and code size analyzed.

All common programming languages are supported. Review quality is highest for popular languages with extensive training data.

Supported: All text-based file formats including:

• Source code (JavaScript, Python, TypeScript, Java, Go, etc.)
• Configuration files (JSON, YAML, TOML, XML, ENV)
• Documentation (Markdown, HTML, LaTeX)
• Build files (package.json, Makefile, requirements.txt)

Not supported: Binary files (images, videos, PDFs, compiled binaries, Office documents)

Workaround: Reference binary files in code but modifications require external tools.

Maximum timeout: 120 seconds (2 minutes)

Commands exceeding 2 minutes will be automatically terminated.

Alternatives for long operations:

• Break into smaller commands
• Run in background and check results separately
• Execute manually in your terminal

MCP server operations consume credits based on the model processing the results. The MCP server itself doesn't use credits directly.

No. MCP servers are configured at the user level and available across all your projects.

Credentials in MCP configuration are stored locally on your machine and never sent to Verdent servers. Use environment variables for sensitive values.

MCP servers start when needed and run during your session. They don't consume resources when Verdent is closed.

MCP servers have the permissions you configure. Use read-only access where possible and restrict destructive operations.

Ask Verdent to use a tool from the MCP server. Successful responses indicate the connection is working. Check Settings → MCP for server status.

1. Open Settings (Cmd+, / Ctrl+,)
2. Go to General
3. Click Reset All Settings
4. Confirm the reset

This resets application settings but doesn't affect:

• User rules (VERDENT.md)
• Custom subagents
• Session history

Verdent stores configuration in multiple locations:

Access settings via Cmd+, (macOS) or Ctrl+, (Windows).

Copy the ~/.verdent/ directory to sync settings.

Options:

• Manual copy between machines
• Cloud sync (Dropbox, OneDrive, etc.) for the .verdent folder
• Git repository for rule and subagent files

Note: Project rules (AGENTS.md) sync via version control automatically.

Most settings apply immediately:

• Theme, models: Instant
• Rules: Apply to new conversations after save
• Subagents: Available immediately after creation

Exception: Some MCP settings may require session restart.

Rebase creates a cleaner, linear history that's easier to understand and bisect. Each feature branch is rebased onto the main branch before integration.

Verdent may assist with conflict resolution. For manual resolution:

1. Open conflicting files in the editor
2. Choose which changes to keep
3. Mark conflicts as resolved
4. Continue the rebase

Uncommitted changes remain in the workspace you're leaving. Each workspace maintains its own working state independently.

See Credits & Plans for shared pricing tiers, the shared credit pool, top-ups, and usage basics across Verdent products.

See Credits & Plans for the shared factors that affect credit consumption across Verdent products.

See What Happens If You Run Out of Credits for the shared account policy and recovery options.

See Billing Cycle and Rollover for the shared rollover rules across Verdent products.

Yes. Verdent Desktop and Verdent for VS Code share the same credit pool on the same account. See Credits & Plans for the shared policy.

Open User Menu from the top bar to view:

• Current credit balance
• Usage history
• Subscription details
• Top-up options

If using git (recommended):

# Check deleted files
git status

# Restore deleted files
git checkout HEAD -- path/to/file

If not in git:

• Check system trash/recycle bin
• Use file recovery tools
• Restore from backup

Prevention: Always use git repositories with Verdent.

1. Use Help → Report Issue in the app
2. Join Discord for community support
3. Email support@verdent.ai

Include in your report:

• Exact error message
• Steps to reproduce
• App version (Help → About)
• Operating system

• Use Stop to halt immediately
• Review changes in Source Control
• Use git to revert if needed
• Provide clearer instructions and retry

Ensure these domains are accessible:

• api.verdent.ai - API endpoint
• app.verdent.ai - Application updates

Check proxy settings in Settings → General if behind a corporate firewall.

Maximum file size: 5MB (automatically compressed if exceeded; error if still >5MB after compression)

Maximum resolution: 2000×2000 pixels

Supported formats: PNG, JPG, JPEG, GIF, BMP, WebP

Best practice: Use images under 3MB with resolutions up to 2000×2000 for optimal performance and accurate analysis.

Yes. You can paste multiple images sequentially or reference multiple file paths in one prompt. Verdent maintains context across all images for comparison and analysis. Example: "Compare these three mockups and identify the differences."

Verdent generates functional starter code that implements the visual structure, layout, and styling from your mockup. You'll typically need to refine by adding business logic, data integration, accessibility features, error handling, and production optimizations.

An iterative verification process where code is generated, tested, and repaired until it passes comprehensive testing. Verdent automatically runs tests, analyzes failures, fixes issues, and retests in multiple passes until the code works correctly. This delivers production-ready code, not just suggestions. Each result includes detailed summaries and code diffs showing exactly what changed.

Use Plan Mode to review and adjust the breakdown before execution. In Plan Mode, you can provide feedback like "Split the frontend work into separate components" or "Combine those two steps." Verdent will revise the plan based on your input before any code is written.

Not necessarily. Use Plan Mode for complex features affecting many files, large refactorings, or when you want to review the approach first. For familiar, straightforward tasks, Verdent can execute directly with real-time todo list visibility. Plan Mode adds a review step for higher-risk changes.

You can provide corrective guidance as Verdent works. Say "Actually, use a different approach for the API integration" and Verdent will adjust remaining steps. For major plan changes, it's better to stop, commit what's done, and start a new session with the revised approach.

Yes, when used properly. Always use Plan Mode to review the complete scope first, ensure you have comprehensive test coverage, and commit frequently between phases. This allows you to verify changes incrementally and rollback easily if needed.

Use Claude Sonnet 4.5 1M for complex multi-file operations and refactoring. Its extended context window handles large codebases. Use Claude Haiku 4.5 for simple searches and discovery tasks. Sonnet 1M provides more reasoning capability for coordinated changes, while Haiku is faster and more cost-effective for exploration.