Windows AI workspace · Development candidate

Give your goal a team.
Keep control in your hands.

A clear, bounded place for AI work. Review the goal and budget, let configured executors develop in steps, then check the result with verification and independent review.

Uses your existing clients and accounts · Final acceptance is in progress

PERU / WORKFLOW
A place for every step.Start with a concrete goal
GOAL · DEMO DATA“Turn these project notes into a clear introduction page.”
PLANDefine the steps
BUILDCreate the files
REVIEWCheck independently
Record results and evidence separatelywith care.
Readable plans · Real artifactsIllustration, no task runs

One workspace. Distinct roles. Plan / Build / Verify / Review

See current capabilities and limits →

01 / PRODUCT

Less handoff.
More clarity.

Organize work around the project: know who owns each step, where changes are allowed, and which evidence supports the result.

Review before starting

Make the goal, roles, references, write scope and budget explicit in preflight.

Implemented · Scoped checks

Keep results in the project

Inspect real files, plans, changes and logs. Keep execution, checks and review separate.

Implemented · Candidate

Stop when you need to

Pause future work and wait for native stop evidence. Reconcile unknown results without blind replay.

Implemented · Scoped fault checks

02 / WORKFLOW

One goal.
Step by step.

Select a step to see how a goal moves through the workflow. This fixed-data demo does not connect to a local service, read files or start an AI.

WORKFLOW DEMO · FIXED DATA

Describe a concrete goal

Choose a project folder and tell Peru what the result should be. Name any reference sources and keep the output in your workspace.

Goal and project recorded
01 / 05
Read the complete workflow as text
  1. Describe — Choose a workspace
  2. Plan — Roles, scope and budget
  3. Execute — Original conversation
  4. Verify — Actual checks
  5. Review — Current evidence

03 / CONTROL & EVIDENCE

Keep moving.
Keep the boundaries.

Important approvals, real stop receipts and unresolved problems should remain visible. Peru keeps those facts separate from a simple “done” label.

  • Scope is agreed before work

    Reference sources are read-only; outputs stay in the selected workspace. Extra actions need approval. A worktree is not a certified OS sandbox.

  • A pause is not a stop receipt

    A pause stops future dispatch. The native receipt determines whether the current turn has stopped.

  • Keep failures and unknowns visible

    Retain failures, frozen budgets and original conversations. Rework is bounded; unknown results are never blindly replayed.

Peru offline layout example with conversation, goal, plan and run details
Actual client rendering · Offline demo dataA layout example, not a native task recording or final live acceptance

04 / COMPATIBILITY

Use your existing clients.
Check each role.

Clients, models and permissions have distinct limits. A software configuration does not prove native acceptance of every combination.

Codex

Native task evidence

Scoped native planning, implementation and fresh review evidence exists. Available models depend on the current account catalog.

Qoder

SDK activated

The native SDK plugin is activated. Current project binding and full mixed-task acceptance remain in progress.

ZCode

Live entry check pending

The new source handoff entry is implemented and software-tested. The complete current client path still needs live acceptance.

START WITH AN ISOLATED TEST PROJECT

Bring your next goal
to the workspace.

Review installation, role setup and validation limits before using the candidate.

Windows x64 · Unsigned personal candidate · No public binary distribution

05 / FAQ

A few answers.
Before you start.

Is Peru a local model?

No. Peru organizes workspaces and execution records locally. Models come from your configured clients or services; approved context is sent to the relevant service when using a cloud model.

Has the full mixed-client workflow been accepted?

Not yet. Role configuration and serial routing are implemented, and scoped native evidence exists. Current dual-client contributions, paired five-task tests and final live gates are unfinished.

Can it guarantee savings or automatic success?

No. Unobserved tokens, provider-internal calls and costs remain unknown. There is no measured savings claim; failures or missing permissions can leave work safely waiting.

Is the candidate ready for important production work?

It is an unsigned personal development candidate with unfinished final acceptance. Start with an isolated test project, keep backups and review scope, permissions and compatibility.