os.neu: An Early Experiment in Building an AI Workspace Across Models, Documents, and the Web

2026-11-13来源 dev.to AIEnglish
os.neu: An Early Experiment in Building an AI Workspace Across Models, Documents, and the Web

By Billy Lee — NeuAvenue Inc.

I’m building os.neu, an early-stage AI workspace that explores a simple question:
What happens if AI interaction, document creation, model selection, and web research are brought into one working environment instead of being split across multiple applications?

This is not a claim that os.neu is already a new operating system or autonomous AI platform.

It is an early technical prototype. I’m releasing it to a limited group of users because I want to understand what actually works in real environments—and what does not.

What is os.neu?


os.neu currently runs as an application layer on top of existing hardware and operating systems.

It does not replace Windows or Linux, and it is not a new operating-system kernel. The current MVP provides an AI-focused working environment where users can connect supported AI models and use them for practical knowledge-work tasks.

The current prototype focuses on three areas:

  • Connecting and managing supported LLMs
  • Creating and editing documents, presentations, and spreadsheets
  • Web browsing through daf.neu The goal is not to build another chatbot.

The goal is to investigate whether a more connected AI workspace can reduce the friction between asking a question, researching information, creating content, and producing a usable result.

OS.neu quickstart on Ubunutu 26.04 LTS

Why build another AI workspace?

A typical AI workflow today can look like this:

  1. Search the web.
  2. Open an AI chatbot.
  3. Copy information into the conversation.
  4. Generate some text.
  5. Move the result into a document.
  6. Open a presentation tool.
  7. Copy more information.
  8. Build slides.
  9. Move between applications again. The individual tools can be powerful.

The problem is often the workflow between them.

I started building os.neu to explore whether these steps could be brought closer together.

This is still an experiment.

Multiple AI models instead of one fixed provider

How to use one fixed AI model on daf.neu

One design decision in os.neu is to avoid making the workspace dependent on a single AI provider.

Different models can have different capabilities, costs, latency, context limits, and access requirements.

The current Settings interface therefore allows users to manage model connections and select which available models can appear inside the workspace editors.

The interface currently displays several model/provider entries.

However, there is an important distinction:

A model appearing in the interface does not mean that it is automatically connected or available to every user.

For example, the current test environment demonstrates a successful OpenAI GPT-4.1 connection, while other providers may require the user's own API credentials.

This distinction is important because I don't want the product documentation to imply capabilities that have not actually been implemented or verified.

Model selection is part of the experiment

os.neu currently allows users to configure a default model and control which connected models are exposed in the document, spreadsheet, and presentation workflows.

The current architecture is intentionally simple:

User → Connected Model → AI-assisted workflow

It is not yet an automatic model-routing system.

os.neu does not currently claim to automatically select the best model for every task or orchestrate multiple models autonomously.

Instead, I want to test a more basic question first:
Does giving users more control over the AI models they use actually improve their work?

That answer should come from usage rather than assumptions.

From prompts to actual work

Another major part of os.neu is AI-assisted document creation.

The current MVP can be used for workflows involving:

  • Reports
  • Proposals
  • Presentations
  • Spreadsheets
  • Structured information
  • Research-related documents The important design principle here is that AI output is treated as a draft.

Users remain responsible for reviewing, editing, correcting, and approving the final result.

This is particularly important for professional and research workflows.

The objective is not:
“Let AI finish everything.”

Instead, it is closer to:
“Let AI help move the user from an initial idea to a useful working draft.”

Where daf.neu fits

Research and content creation are often part of the same workflow.

For example:

Research → Compare → Organize → Write → Present

daf.neu is the web-browsing component within the Neu Workspace environment.

The intention is to reduce some of the friction between web research and AI-assisted content creation.

But again, there is an important limitation.

os.neu does not claim that web browsing automatically verifies sources or guarantees research accuracy.

Users should still examine important sources and independently verify critical information.

How does os.neu run?

Another area I'm experimenting with is deployment.

The current project supports different ways of accessing the environment rather than requiring users to replace their existing operating system.

The current project includes:

  • Existing Windows environments
  • Existing Linux environments
  • A Linux JeOS-based USB boot environment
  • A practice/guest environment

The USB environment is Linux-based and should not be confused with the Windows application installer.

For the current Wave-1 early prototype program, Linux access is required for installation and activation.

This distinction is important because the project has several installation paths, but they do not all provide the same capabilities.

What os.neu is not

I think this section is especially important for an early-stage developer project.

os.neu is currently:

  • An early-stage MVP
  • An AI workspace
  • An application-layer environment
  • A multi-model connection experiment
  • A document/presentation/spreadsheet workflow experiment
  • A web-research workflow experiment It is not currently:
  • An independent operating-system kernel
  • A replacement for Windows or Linux
  • A production-ready AI operating system
  • An autonomous AI agent platform
  • An autonomous multi-agent execution system
  • A system that guarantees accurate AI-generated documents or web research I believe being explicit about these boundaries is important when developing AI infrastructure.

The current implementation should be evaluated based on what actually exists, not on the long-term vision.

What I want developers to test

I'm particularly interested in developers and technical users who are willing to test the system in real environments.

Some useful test areas include:

  1. Installation
  • Does installation work on your Linux environment?
  • Are there hardware compatibility problems?
  • Does the application start correctly?
  • Are startup errors understandable?
  1. AI model connections
  • Is model configuration understandable?
  • Is selecting a default model useful?
  • Are API-key requirements clear?
  • Does changing models improve your workflow?
  1. Document workflows

Try using os.neu for something you would normally do in another application.

For example:
Research a topic → collect information → generate a report → edit the result.

Then tell me where the workflow helps and where it creates additional friction.

  1. Presentations

Try creating a presentation from an actual task rather than a toy example.

I'm particularly interested in:

  • Output quality
  • Editing experience
  • Structure
  • Reusability
  • Time saved
  • Places where manual correction is still necessary
  1. Web research Use daf.neu as part of an actual research workflow.

I'd like to know:

  • Does the integrated browser make research easier?
  • Does it reduce application switching?
  • Where does the workflow break down?
  • What information do you still need to move manually?

What kind of feedback is useful?

The most valuable feedback isn't necessarily:
“Looks great.”

I'd rather know:
“I tried to do X. I expected Y. Instead, Z happened.”

For example:

Environment

  • Linux distribution
  • Hardware
  • Installation method

Task

  • What were you trying to accomplish?

Expected

  • What did you expect os.neu to do?

Actual

  • What actually happened?

Problem

  • Error message
  • Unexpected behavior
  • UI confusion
  • Performance issue

Suggestion

  • What would you change?

This kind of information is much more useful for development than general product opinions.

Current Wave-1 Early Access

The current Wave-1 program is intentionally limited.

Linux access is required for Wave-1 installation and activation.

Applications are reviewed manually, and applicants are classified as:

  • GREEN — currently suitable for Wave-1 testing
  • YELLOW — waitlist/discovery
  • BLUE — future research

Only selected GREEN applicants receive a time-limited installation link.

The application JSON generated by the Early Access page is an application record, not the os.neu installation package. Applicants must also send the prepared application email to complete the submission process.

Why I'm opening the prototype now

I don't want to build os.neu entirely from assumptions.

I want to observe:

  • How people actually install it
  • Which workflows they attempt
  • Which AI models they prefer
  • Where the interface becomes confusing
  • Where the technical architecture creates friction
  • Which features people repeatedly use
  • Which features they ignore
  • Whether the product is useful enough to return to

Some of the validation goals are deliberately measurable, including successful installations, recurring usage, repeated workflows, paid-conversion experiments, and task-efficiency measurements.

These are research goals, not current results.

Try it and tell me what breaks

If you are interested in testing an early AI workspace rather than evaluating a polished commercial product, I'd like to hear from you.

I'm especially interested in developers, researchers, technical users, and people who regularly work with:

  • Documents
  • Presentations
  • Spreadsheets
  • Research
  • Data
  • AI-assisted workflows

Try os.neu

Product Overview: https://os.neuavenue.com/welcome

MVP Download:

This manual is English. Use Linux or Windows below. The Back button is Back.
Linux

Public home: https://os.neuavenue.com
Docs home: https://docs.neuavenue.com
USB recovery (for Linux): https://os.neuavenue.com/tutorial
Windows (this chapter as its own page): https://docs.neuavenue.com/windows-install-guide.md

Linux plant pack: neuos-linux.tar.gz
Windows Setup in one place all-in-one to get started directly: os.neu-Setup.exe
Windows source pack (developers): neuos-windows.zip
USB kit: neuos-boot-kit.tar.gz
Demo: https://os.neuavenue.com/

Learn about Medium’s values
Installation Guide: https://docs.neuavenue.com/

Supported Models and Connection Requirements: https://www.youtube.com/watch?v=gB42moYWbck&t=25s

The most useful contribution you can make is not a positive review.

It is a real test.

Install it.

Try an actual task.

Find something that doesn't work.

Then tell me what happened.

That is how I want to develop os.neu.

Building. Testing. Learning in public.

— Billy Lee
NeuAvenue Inc.
Early Access
os.neu Early Access
Product / Demo
os.neu

原文:https://www.a8q9.cn/en/article/os-neu-an-early-experiment-in-building-an-ai-workspace-across-models-documents-a-bf9af9.html

相关文章