So me and my friend have decided we want to make a claude ai agent targeted at small businesses and individuals. I would appreciate it if someone can give their honest opinion on it :) (its called arca) and we even made a website called arcaops.xyz heres a rough idea on the business model:

An AI agent for small teams that watches Slack, Notion, and Google Calendar, and handles the busywork between those tools — acting on its own when it's confident, and asking a human when it's not. The pitch is explicitly "no silent automation, no surprises."

Target user: small business owners / small teams (validated at networking events in Zürich — the deck cites owners saying yes because status updates, scheduling, and follow-ups eat hours a week and they can't justify hiring for it).

The core mechanic — this is the actual product, not the integrations

1. Arca watches events across the connected tools (new Slack message, Notion status change, calendar change).
2. It scores its own confidence about the right action.
3. High confidence → acts automatically (drafts a reply, updates a status, files a card).
4. Low confidence / high stakes → surfaces to the human first, showing its reasoning, before doing anything.

That confidence-gated trust layer is the differentiator — a plain Zapier-style integration wouldn't have it.

After about a year of building, testing and constantly finding things to improve, Nyx AI is finally out. It is available in 240 markets and 6 languages.

Nyx AI is a local first AI workspace for Windows for chat, coding, documents, previews and automation.
You can run models locally through Ollama or connect OpenAI, Anthropic, Ollama Cloud or your own compatible endpoint. No Nyx AI account is required for local use.
One area I spent a lot of time on was agent safety.

In Nyx AI Lab the model can work with files, run shell commands and Python, use Git, run builds and tests, and preview PDF, DOCX, XLSX and PPTX files.
Locked execution uses Windows AppContainer isolation where supported, alongside workspace file controls, command risk checks, approval controls and native Windows confirmations for certain higher risk actions.

There is also a built in privacy sanitiser designed to detect and redact recognised sensitive information before messages are sent to non local models. It is best effort and cannot guarantee that every sensitive value will be detected.

No sandbox is completely secure and these controls reduce risk rather than eliminate it. The limitations and residual risks are documented in the public threat model, and the legal and technical documents are available inside the app.

Would genuinely appreciate anyone trying it and telling me what you think.

Website
[https://nyxai.uk
Microsoft Store
)Microsoft store nyx ai

Hey folks 👋

We just open sourced TrueForge, our vendor-neutral agent harness for building general-purpose agents.

It handles the runtime pieces that get painful quickly : context management, tool/MCP execution, subagents, sandboxing, approvals, persistent state, and more.

We also benchmarked the harness itself. With the same Opus 4.8 model, TrueForge delivered a similar solve rate at ~30% lower cost than Claude Managed Agents. Switching to an open model pushed that to ~75% lower cost on the same benchmark.

Would love feedback from people building agents.

⭐ Star the repo: https://github.com/truefoundry/trueforge

📖 Read the launch article: https://x.com/truefoundry/status/2090081376330715176

This is the app (called "LWP+"), and I've shown here the video that I've published there:

https://play.google.com/store/apps/details?id=com.lb.lwp_plus

At first I was happy about what I created on the video, but then I thought that it looks more like a tutorial here, instead of maybe focusing on what's the most interesting. Surprisingly, ever since I've published the video, it actually got quite some views already (29 after 2 days), despite the fact it's a bit of a niche app. Still, I think maybe it can be improved.

I want to know what you guys think about the video (which has audio, BTW).

Here's about the app:

It's a live wallpaper app, that has these features:

1. Allows showing color/image/animation/video as content (users choose the file from the file system). No special effects so some users that complain about the dimming/zooming effects actually like using it. Users can also choose whether it should scroll or the type of automatic cropping.

2. Allows (some) control over the Material-You colors of the OS, as it lets users to choose the colors to report the OS about what's on the wallpaper. This means that like on Android 17, users can choose the colors they want (if the OS supports it) despite the content not matching it.

3. Setting of double-tap to lock the screen. Some launchers don't offer this, so I added it to the app too.

4. Some extra flags that (on some devices) should affect colors further, such as black/white text and/or black/white icons on status bar and/or lock screen and/or launcher.

The app is completely free, ad-based. Users can remove the ads including by just watching full screen ads. Originally it was created to offer dark-theme on devices as it wasn't a toggle on the OS settings, and was based on the colors of the wallpaper.

Quick backstory: I'm not a developer. No CS degree, never written a line of Swift before this. But I kept missing return deadlines, forgetting free trials before they turned into paid subscriptions, and losing track of invoice due dates — so instead of just complaining about it, I decided to try building the fix myself using Claude Code (Anthropic's AI coding tool) as my actual dev partner.

The result is Untilly: you photograph a receipt, contract, invoice, or trial confirmation (or upload it as a PDF), it detects the relevant date, and reminds you before it's too late. A few decisions I made early on:

The AI only ever suggests a date — you always confirm it against the real document before it's saved. I didn't want a "trust the black box" tool for something people rely on.
No account, no cloud, everything stays on your phone.

Different wording for different situations (a return deadline feels different from a trial about to charge you, so the app treats them differently).
What surprised me building this without a coding background: the app itself came together faster than I expected, but everything around it — App Store Connect, subscription setup, tax forms, privacy questionnaires — ate at least as much time as the actual product. Nobody warns you about that part.
I also tried adding a Share Extension (send a PDF straight from Mail/Files into the app) and had to abandon it after fighting an entitlements bug for hours — sometimes you just cut scope and ship what works.

It's live now on the App Store, free to try with a few tracked items, optional premium for unlimited: https://apps.apple.com/app/id6792659522

Curious whether other non-technical folks here have tried building with AI tools instead of learning to code or hiring out — did it actually hold up once you got past the prototype stage?

I'm the developer, and this is my project, so read it with that in mind.

The part I think is actually interesting is a refusal, so I'll start there. My app can run AI-generated shell commands and Python inside a Windows sandbox using AppContainer. Before it treats a sandbox level as available, it tests on your machine that Windows is actually enforcing that boundary, and it fails closed when a sandbox level you chose can't be established: the command is refused rather than run with weaker protection. The UI always shows which isolation level actually ran, because "sandboxed" is a claim and the app should have to prove it.

The app is Nyx AI, a Windows desktop workspace built around an AI agent. It does documents, spreadsheets with live formulas, slide decks, PDFs, web research and data analysis as well as code editing and shell work. You bring your own model: Ollama running on your PC with no API key stored in the app, or your own OpenAI, Anthropic or Ollama Cloud account. It ships no models and no inference runtime, so local means installing Ollama yourself first.

Honest qualifier on "local-first", because you'd catch it anyway: a local Ollama model keeps ordinary prompts on your PC, and small background helper calls can use a local model when one is available. On the Auto routing setting, though, heavier coding, reasoning and planning work normally prefers a cloud route you've configured. Local-first is a supported way to run it, not a guarantee that nothing ever leaves the machine. The docs say exactly that.

There are four isolation levels: Automatic, Standard, Sandbox + internet, and Sandbox · no internet. They use two Windows mechanisms: AppContainer for the two Sandbox levels and a Job Object for Standard. Standard is documented as not being a filesystem or network jail.
At the no-internet level, the sandbox is created without internet capability, so the operating system itself refuses outbound traffic from AI-run code. That still isn't an air gap for the whole app: chat still goes to whichever model provider you chose, and the update check, dependency installs you approve, and one-time component downloads can still touch the network. The threat model lists all of it.
Approvals come in two kinds. Ordinary ones are cards inside the app. Higher-risk model actions and certain sensitive operations can require a native Windows confirmation dialog outside the model-controlled interface. Nothing sent from the chat window can mark an action pre-approved, and if the dialog can't be shown the action is refused.

A smaller set of prohibited actions is refused outright in every mode and never offered for approval at all.
There's also an audit trail: a plaintext action log, plus an encrypted, hash-chained forensic log of approvals, denials and sandbox blocks. If a recorded entry is later altered, verification can show it. The docs also state plainly that this cannot prove nothing is missing.
Now the parts you'd find out anyway, so here they are first.
Windows 10/11 x64 only, because the sandbox is built on Windows-specific isolation. There is no macOS, Linux or Windows-on-ARM build.
It is proprietary and closed-source, free for personal non-commercial use, with a separate licence required for commercial use.

Because the source is not public, I have tried to make the externally verifiable parts unusually transparent. The full threat model is public, including trust boundaries, network paths and residual risks, and you can independently monitor its network behaviour.
It's beta software. It has not been independently audited. Prompt injection is documented as not solved, and the app itself ships the line "no sandbox is 100%".
Nyx AI sends no usage analytics, telemetry or crash reports of its own. Automatic update checks are on by default and can be disabled. A check sends the installed version, and the connection necessarily exposes the requesting IP to the update host. Installing from the Microsoft Store also means Microsoft's own platform diagnostics apply under Microsoft's terms, not the app's.
Site and threat model:
https://nyxai.uk

Install is through the Microsoft Store. The website does not host the installer.

Two things I'd genuinely like opinions on.
Where would you draw the line between approvals that deserve a hard OS dialog and ones where an in-app card is enough?
And if you read the threat model, what's missing from it?

Some of you may know me from LMX Designs. I took a completely different path.

Over the last year, I went from designing and building creative projects to building LMX Synthetic from the ground up a Synthetic AI creative platform built for creators.

Now I’m using LMX Synthetic to create an original universe called Project LMX.

This is the first scene:

Chaos Chloe escaping the LMX Laboratory.

I’m using my own platform to stress-test it with my own projects, because I’m a creator first at heart. I want to push it as hard as I can before I open it up to everyone else.

At the end of the day, I’m a creator building for creators and that’s a perspective I don’t think you see enough in AI.

This is only the beginning.

Let me know what you guys think. Would you watch a short episodic series built around escaped LMX experiments?

I have been testing local coding models on an AMD Radeon AI PRO R9700 with 32 GB VRAM. Instead of comparing only tokens per second or asking the models to generate isolated functions, I ran two of my daily Pi coding profiles through the same repository-level workflows.

The short version: Qwen3.8 caught every requirement, while my Qwen3.6 "precise" profile finished 3.12x faster but missed one CLI requirement that was not covered by the visible tests.

Models and profiles

Qwen3.8 profile

• Unsloth Qwen3.8 27B UD-Q6_K_XL GGUF
• 65,536-token Pi context
• 2,048-token maximum response
• Native Qwen3.8 developer/tool template
• Low reasoning effort with a 1,024-token server reasoning budget
• Temperature 1.0, top-p 0.95, top-k 20, min-p 0
• Embedded MTP enabled with two draft tokens
• Q8 target and draft KV caches
• About 28.78 GB VRAM allocated

Qwen3.6 precise profile

• Unsloth Qwen3.6 27B MTP Q6_K GGUF
• Qwen Sharp chat template
• 65,536-token logical Pi context
• Temperature 0.1, top-p 0.95, top-k 40, min-p 0.05
• 128-token reasoning budget
• MTP enabled with three draft tokens

Both were served through the same llama.cpp Vulkan router with one model loaded at a time. Pi ran offline with its read, edit, write, grep, find, ls, and shell tools enabled.

What I tested

I used four fresh Git repositories created from identical broken baselines:

1. Fix a stale cache after JSON persistence.
2. Add task priorities across the model, service, JSON compatibility, CLI, and README.
3. Refactor dependency ordering to include dependency-only nodes, remain deterministic, and reject cycles.
4. Make batch persistence atomic across validation and filesystem replacement failures.

Each model received the same prompt and repository. Every workflow used a new Pi session. The agents could inspect the repository, edit files, and run the five visible unittests. I did not send any repair prompts after Pi exited.

I then ran one external grader per workflow. These checks were outside the working repositories and were never shown to the models. They covered cases such as CLI filtering, duplicate dependency edges, generator validation, injected os.replace failure, cache preservation, and temporary-file cleanup.

Results

Metric	Qwen3.8 27B	Qwen3.6 precise
Visible tests	20/20	20/20
External checks	4/4	3/4
Combined checks	24/24	23/24
Workflows completed	4/4	4/4
Total wall time	12:05.10	3:52.41
Model turns	53	39
Tool calls	78	58
Generated tokens	24,941	8,326
Non-cached input tokens	27,604	21,382
Cache-read tokens	385,983	186,383
Changed lines	182	115

Per workflow:

Workflow	Qwen3.8	Qwen3.6 precise
Cache invalidation	6/6, 1:38	6/6, 1:00
Priority feature	6/6, 3:46	5/6, 1:08
Dependency refactor	6/6, 1:41	6/6, 0:55
Atomic batch persistence	6/6, 5:00	6/6, 0:49

The server stayed healthy throughout the run: zero service restarts and no OOM, Vulkan device-loss, segmentation-fault, or fatal events.

The interesting failure

Both models passed every visible test. The difference appeared only in the external priority grader.

The prompt explicitly required --priority support on both the create and list CLI commands. Qwen3.8 implemented both. The precise profile added priority support to the data model, persistence, service filtering, and create --priority, but it forgot list --priority.

That is exactly the kind of omission that a normal green test suite can hide. Qwen3.8's extra reasoning and repository exploration were expensive, but in this run they bought a real requirement-coverage win.

Patch quality

Both models handled the cache and dependency tasks correctly. Both atomic implementations validated the full batch before mutation, preserved disk and cache state after an injected replacement failure, and cleaned temporary files. Qwen3.8 additionally flushed and called fsync before the atomic replacement.

Qwen3.8 was less economical overall. It changed 182 lines versus 115, used 36% more model turns, made 34% more tool calls, and generated almost exactly 3x as many output tokens. The priority documentation and public exports were useful, but the model's native reasoning style is undeniably verbose.

My takeaway

I am not replacing the precise profile outright.

• Qwen3.6 precise remains my choice for fast edits with a strong existing test suite. It completed this benchmark 3.12x faster and used one-third of the output tokens.
• Qwen3.8 is the better choice for underspecified, cross-layer, or agentic work where missing one requirement is more expensive than waiting longer. It was the only profile to satisfy every visible and hidden check.
• A useful two-model workflow may be Qwen3.6 precise for implementation and iteration, followed by Qwen3.8 for requirement review—or Qwen3.8 for the initial complex implementation and precise for fast follow-up fixes.

This is only four Python workflows with one stochastic run per model. It does not establish universal model rankings, and the profiles are not architecture-normalized: they use the settings I actually run in Pi. Still, I found the result more useful than another isolated HumanEval-style score because it exposed a genuine repository-level omission.

Model source:

• Qwen3.8 GGUF
• Qwen3.8 local guide

I can share the exact prompts, external grader, Pi JSON event transcripts, and patches if people are interested.

I've been building Pinaka on the side for the past few months — an AI agent that automatically writes root cause analyses when a bug ticket is filed.

The problem it solves: every time a production bug hits, a senior engineer spends 2-3 hours investigating before writing a single line of fix. The actual fix takes 20 minutes. The investigation takes the rest of the day.

Pinaka eliminates that investigation step. Tag a Jira ticket or mention @pinaka-app on a GitHub Issue — it reads your indexed codebase, captures runtime context via an SDK, and posts a structured RCA as a comment. Root cause, exact file, exact line, fix approach. Automatically.

What I've validated so far

Ran it against real open source bugs:

• BullMQ issue #2487 — code only scored 6.5/10, code + runtime context scored 9.2/10 against the actual merged fix
• Prisma ORM issue #29480 — open bug, no ground truth, diagnosed from behavioral contrast across test files
• Pinaka's own Java SDK — found a real ForkJoinPool exhaustion bug, fix shipped same day

All three write-ups are public, including the limitations.

What I'm looking for

couple of engineering teams (2-150 engineers) using GitHub who want to try this on a real production bug. Free, no commitment. I'll personally onboard you and be available for any questions.

Works with Jira and GitHub Issues. No Jira required. One OAuth click to connect. First 5 RCAs free.

Honest state of the product

No paying customers yet. Building in public. The product works — the benchmarks above are real — but I need real teams on real codebases to validate it beyond my own test cases.

If this sounds useful for your team, drop a comment or DM me. Happy to show you a live demo on your repo.

👉 getpinaka.com

Kit is an open source app that puts your entire dev environment in one window. Code editor, real Chromium browser, terminal, git panel, autonomous AI agent, visual pipeline builder, whiteboard, email and calendar all connected.

The interesting part: the AI sees everything. Ask it a question in the terminal and it already knows what file you have open, what page you're browsing and what your git state is. No copy-pasting context between windows.

The agent takes plain English tasks, plans and executes in a loop using your actual project files. Every file write or shell command asks permission before running.

MIT licensed, macOS and Linux. Bring your own OpenAI or Anthropic key.

https://github.com/raiyanyahya/kit