What dev3d is, and is not
Is it a real 3D application, does it need a GPU, does it work offline, and what the thirteen employees are.
These are the questions people ask after seeing a screenshot and before installing anything: is the office real, will it run on this machine, does it need the network, and what exactly is an employee. Several of the honest answers are "it is smaller than it looks", and those are the ones worth reading first.
Is dev3d a real 3D application, or a visualisation over something else?
Is the office a genuine 3D application, or a dashboard with an office drawn on top? The office is the application: the WebGL canvas fills the viewport unconditionally and every other surface — the info popout, the inspector, the brief dock, the settings sheets — floats over it. It is rendered with three.js and React, and the floor plan, the seats and the employee bodies are all built from real data rather than being a looping animation.
Why
The distinction is not cosmetic, and it is checkable in the source rather than something you have to take on trust. There is exactly one WebGLRenderer, created in a mount effect whose only dependency is the store, and the top-level layout renders the office canvas as a sibling of everything else rather than inside a tab switch. Selecting the Projects page or the Settings page mounts a sheet over the office; it never unmounts it. That is why a run streaming for ten minutes does not churn WebGL contexts while you read a transcript, and why "go to the Projects page" does not mean "leave the office".
The scene is data, not a video. The building is a GLB whose named empty nodes are the entire interface between the asset and the org chart: an avatar is placed by looking its seatId up in the loaded scene and taking that node's world position, and the desk an avatar faces is found by swapping the Seat_ prefix for Desk_. Employees are built procedurally in the browser from three fields on Role.appearance — bodyColor, accentColor, and a height clamped to 0.8–1.3. Status is carried three ways at once: a floor ring under the selected employee, an emissive tint (a chest lamp plus a wash over the body), and body language such as typing or a hand to the chin.
So the office is not a render of the state; it is the state, drawn. What it is not is a simulation: there is no physics loop deciding anything, no walk cycle, and no pathfinding. Avatars are repositioned directly, and the only two things in the server that ever emit a movement event are hiring someone and moving their seat. A debate appears as attributed speeches in the transcript, not as people crossing a room. The office describes exactly what the furniture encodes and what it does not.
Do I need a GPU?
Does dev3d need a dedicated GPU? No — nothing on the server side touches 3D at all, and the client only needs a browser that can render WebGL. A laptop with integrated graphics runs the office, though a large floor with dozens of generated modules will look and feel better on a real GPU.
Why
Split the question in two, because the two halves have different answers. The orchestrator — the process that runs the pipelines, calls the models, writes files and owns the database — is plain Node and has no 3D dependency of any kind. It will run on a headless box, in a container, or over SSH with no display, and you can drive the whole thing from the HTTP API without ever opening a browser.
All of the 3D lives in the web console. That is a React application rendered with three.js, and it needs the browser to give it a WebGL context. Recent Chrome, Edge, Firefox and Safari all do. Integrated graphics are enough for the default floor; the cost grows with the number of room modules the building has grown, because every module adds meshes to the same scene.
The one failure mode worth knowing is a context loss, which is a GPU or driver problem rather than a dev3d problem. The viewport reports it as a lost WebGL context, and reloading the page restores the office — the client reconnects and the server re-sends the entire state, because on connect the server always sends the whole office rather than a delta. You lose nothing but the camera position.
Where the GPU question actually bites. Two places, both about the building rather than the models. A floor that has grown a ring of modules is framed from a distance that grows with it, so past a certain size an individual desk is small on screen and the only way to inspect it is to orbit and zoom by hand — there is no per-room camera preset. And a machine whose driver drops the context will show you an error instead of a scene until you reload. Neither is a rendering requirement; both are limits of the interface, and Known gaps lists them.
Does it work without an internet connection?
Can dev3d run with no network at all? Yes, and a fresh keyless install does exactly that: it boots in mock mode, runs real pipelines with scripted employees, and makes no outbound call. What stops working offline is everything that needs a vendor — model discovery, the benchmark and endpoint-health indices — and each of those degrades to a cached copy or to nothing at all.
Why
Start with what the software does by itself. There is no account, no sign-in and no telemetry: the orchestrator has no address for this website and no code that would contact it. The plugin install path is off by default and only ever fetches from a marketplace you registered by hand, and nothing polls a marketplace on its own — the operator asks, on demand. A source that cannot be reached is recorded with its last error and skipped.
Model discovery is the one outbound call a normal boot makes, and it only asks providers that are already configured. Its results are cached to a JSON file under the data directory with a six-hour freshness window, so a restart inside that window does not re-ask. If the cache is missing or stale and the provider is unreachable, the provider's models fall back to the curated table — the same twelve entries that ship as the offline seed — and the console labels the provenance as degraded rather than pretending discovery succeeded. Two optional indices behave the same way: the benchmark index and the pooled quality index have caches with their own TTLs and their own off switches, and no key means no request is made at all.
There is one case that is genuinely online-only, and it is worth stating plainly: a live model call. If you have configured a provider key, every turn is an HTTPS request to that vendor, and the office cannot make one without a network path to it. That is not a dev3d limitation — it is what using a hosted model means. If your goal is an offline office, the two configurations that work are mock mode (deterministic, free, no network) and a local runtime on the loopback interface, which is described on Running it and paying for it.
How many agents is "a company"?
Is it really thirteen agents, or thirteen prompts on one model? The shipped organisation is thirteen named roles across eight departments, and each role is a separate model call configuration — its own model policy, skills, tool grants and appearance. How many distinct models that resolves to depends entirely on what you configure and how routing scores that turn.
Why
The number is a design decision, not a headcount target. Thirteen roles across eight departments is the smallest organisation in which somebody can be paid to disagree with somebody else. The departments are executive, design, research, technology, frontend, backend, platform and quality, and the roles run from Ada as Chief Executive and Vera as Chief Technology Officer, through the design, frontend, backend and quality leads, to four engineers who do the building and a researcher who is the only one whose policy allows a nano-tier model.
The important part is that "employee" is a configuration, not a model. A role carries a ModelPolicy with a default tier, per-task-class overrides, a hard floor and ceiling, an escalation threshold and a per-turn output cap. Which concrete model serves a turn is decided again for every turn by the router, from the policy, the stage's task class, a complexity estimate, the installation's posture and the budget left in the run — so the same employee can run on a nano model for an intake summary and a frontier model for an architecture decision, and the decision is recorded with its reasons. Model routing has the mechanism; the short version is that two employees are distinct because of what they are allowed to do and how much model they are allowed to buy, not because each one owns a model.
What are the thirteen "employees" actually?
Are these people, personas, or just prompt templates? Each one is a persisted configuration record: a role with a name, a title, a department, a seniority, a model policy, a list of skill ids, a list of granted tools, an appearance and a seat. A turn belongs to exactly one of them, and the record of that turn carries who it was for and what they were asked.
Why
The distinction from "prompt template" is the part that matters, because a template is a string and a role is a set of capabilities the engine enforces. A role's tool grants decide which tools it may call; a call outside the grant is refused with a message naming the role, not silently dropped. A role's model policy bounds what a turn may spend. A role's skill ids decide which parts of the skill catalogue are even candidates for its turns. A role's seat decides where the avatar stands. Change any of those and the employee behaves differently, without touching a prompt anywhere.
The org chart is live data rather than a fixture. You can hire a role, fire one, change a model policy, move a seat, and switch a routing posture from the console while runs are in flight — and the office plans another floor module for itself when the roster outgrows the building. The core asset holds 21 seat anchors, 13 desks and 7 room anchors, and those counts are asserted at build time rather than eyeballed; beyond the core, generated seats are namespaced by module so two pods cannot claim the same seat.
Two of the statuses you might expect are not real. The talking status exists, has the label "in a meeting", a colour and a full set of body language, and no code path in the server ever sets it — the vocabulary anticipates a behaviour the engine does not have. And queued and done are run statuses used for badges and filters, not employee statuses; acting appears nowhere in the repository at all. The seven real employee statuses are offline, idle, thinking, working, talking, blocked and error. The office has the colour table.
Does it replace a person?
Will dev3d do a developer's job? No. It is a small organisation that will produce a real, reviewed, verified artefact for a scoped brief, and it will do it faster and more legibly than a chat loop. It is not an engineer: it does not know your codebase's history, it cannot talk to your customers, and it is not accountable for what it ships.
Why
The honest framing is that dev3d automates a workstream, not a job. What it does well is the part of a project that is genuinely decomposable: understand a brief, plan workstreams, research and argue an approach, fix a file-level technical plan, write real files into a workspace, review them, verify them, and report. Runs are bounded by a pipeline, a budget and a participant list. Nothing about that is a career.
What it does not have is worth being specific about, because it is exactly the list a buyer would otherwise assume. It does not know the history of your repository beyond what its tools can read in the run's workspace. It does not remember yesterday: runs are separate, and a plan session lives only in one browser's local storage. It cannot answer a question in a direct message from your workspace, because direct conversations deliberately carry no tools at all — the prompt tells the model to say so rather than claim to have read anything. And it does not judge whether the thing it built is the right thing to build; that judgment arrives with the brief you wrote.
What it does give you is a first draft with an audit trail, at a cost you set. Every turn is attributable to an employee, has a stated purpose, records the model that answered and why, the skills pulled in, the files written and the money spent. That is a materially different proposition from "an agent did something", and it is the reason to use it: not that it removes a person, but that the work it does produce can be checked by one. Design thesis argues the case properly; Use cases describes what people point it at.
Is it an IDE, or a chat wrapper?
Is dev3d an editor plugin or a nicer interface over a chat model? Neither. It is a separate application with its own server, its own console and its own record store; it does not integrate with an editor, and a chat box is only one small part of what it does. Nothing in its design assumes you were chatting with a model first.
Why
It is not an IDE because it does not edit your code with you. There is no editor integration at all: no language server, no extension, no inline completion, no diff review surface inside an editor. The office works on files in a project directory and writes them itself, through tools confined to that directory, and the console shows you the resulting record — which files a turn wrote, what it cost, what model it ran on. If your mental model is "Copilot but with a floor plan", the model is wrong in the direction that matters: dev3d is something you commission work from, not something that sits in your editor's gutter.
It is not a chat wrapper because the chat is one command among many and the least privileged of them. A direct message to an employee routes on the role's default tier with the task-class mapping deliberately removed, and the turn has no tools at all — it cannot read the workspace, and the prompt instructs it not to claim otherwise. The substance of dev3d is the pipeline: twelve stage kinds composed into three shipped pipelines, four ways of scheduling the participants of a stage, and a record hierarchy of run, stage, turn and tool call that persists everything. That is a workflow engine with a company drawn on it, and no amount of prompt engineering over a chat box produces the routing decision, the budget gate or the artifact tree.
The honest comparison is not to a chat client but to an unattended agent loop, and the difference is where the value sits. A plain loop gives you a transcript; dev3d attaches every turn to a named employee with a purpose, a model and a reason, so "was that turn worth a frontier model" has an answer in the record rather than in your recollection. How a run flows shows the whole path from brief to report.
Is it a hosted service?
Do I sign up somewhere, or is this a SaaS product? No. You run the orchestrator on a machine you control, against your own provider keys, with your own SQLite file. There is no hosted control plane, no account, and no usage metering anywhere except the vendor bills you pay directly.
Why
The architecture makes this a fact rather than a policy. One orchestrator process serves both the HTTP API and the office UI, from the same port, and persists to one SQLite file. Provider keys are read from the process environment and never leave the server: they are not written to a settings row, not logged, and not sent to the browser. The plugin host runs in that process, with that process's authority. There is no component of dev3d whose job is to talk to a control plane, because there is no control plane.
What this site is, to be precise about it, is documentation plus a plugin marketplace. The marketplace serves a catalog document and bundle downloads to hosts that choose to register it; it does not know what your office is doing, and a host that never registers a source never contacts it. The one thing the site does learn about an install is recorded when a host downloads a bundle — the plugin version, the dev3d version and operating system parsed from the user agent, and a hashed address for counting unique installers — and Privacy describes that in full, including the parts it does not cover.
The corollary is that you own the consequences. Because there is no hosted layer, there is also nothing between your machine and a misbehaving run: no operator, no quota service, no kill switch you did not build. The orchestrator has no authentication of its own and is meant for the loopback interface — anything that can open the socket can hire, fire, spend and install. Read Environment before you change the bind address, and Known gaps before you trust it with something expensive.
What does "the office" change about behaviour, versus a plain agent loop?
Does the office actually change what the system does, or is it presentation? It changes three real things: who is accountable for a decision, how much model a piece of work is allowed to buy, and whether a human can see a partial failure. The building is how those three stay legible, not a decoration over a queue.
Why
Accountability first. A pipeline stage names the roles that own it, and the engine refuses to start a pipeline the floor cannot staff — so a run is not a bag of calls, it is a sequence of decisions with owners. The product pipeline distributes them concretely: the chief executive owns understanding the brief and the final report, the researcher owns the one optional stage, the leads and the CTO debate and then converge in a workshop, the technical plan belongs to the technology role alone, four engineers build in parallel, the review stage runs as a loop whose chair is deliberately not the producer of the work, and quality verifies independently of everyone who built anything. That shape is why "spend a frontier call here and a nano call there" can be a policy rather than a hope.
Price second, and this is the part a flat loop cannot do. Every turn is priced before it is taken, because the model is chosen per turn from a policy that expresses how much model the work deserves. The tiers are nano, small, standard, strong and max, and the shipped policies span all five. A model that fits the work better at a different tier can still win, which is the nuance the router implements and most descriptions of it get wrong.
Visibility third, and it is about failure as much as success. The interface shows seven distinct employee statuses, each carried by colour, an emissive tint and posture at once; per-person panels show the routing decision behind the last turn with its full reason string; the activity feed carries each debate speech attributed to the speaker who made it. That matters most in the cases that are hardest to see: a turn that hits its output cap stops with whatever it produced, and both partial failures now settle as failed turns that reach the wire, so the transcript is where the truncation shows. An interface that shows you which employee, which stage and which turn is how you find that. Known gaps documents the case in full.
Still unanswered?
- Contact — ask the question this page did not.
- Documentation — the whole manual, if you would rather browse than search.
- The office — what the floor plan, the seats and the colours actually encode.
- Introduction — the same territory as this page, written as continuous prose.
- Known gaps — the limits behind several "no" answers above.
- Features — the same capabilities described for someone choosing software.
Where to go next
Linked from
Did this page answer your question?