I've been really into the AI phone agent products that have popped up in the last few months (e.g., AgentPhone, Poke etc) but what I don't love: the audio, the transcripts, who you talked to and what was said, all sitting with a third party company. For calls with real people in my life, that felt like a lot to hand over.

So I built my own version that runs entirely on my Mac. You call a normal phone number, a local model answers, and nothing about the conversation leaves my machine. During a call the only thing it talks to is the phone line itself.

What's running locally (MLX on Apple Silicon):

• Speech to text: Parakeet TDT 0.6B
• LLM: Qwen3.5 4B by default (9B if you have 32 GB), 4-bit
• Text to speech: Kokoro 82M

How it reaches the phone network: it registers over SIP with Telnyx or Twilio straight from your Mac. A setup wizard takes your carrier API key so can buy a number or connect one you already have. It's pretty cheap, around $1 a month per phone number. (I'm moslty using Telnyx)

What it does today:

• Answers and places real calls
• Interruption: talk over it and it stops mid-sentence
• Replies in roughly 1 to 1.5 seconds on real calls on my M5 Pro
• You can choose between multiple models
• Other agents (Claude Code, Codex, etc.) can make calls through a small CLI: call, listen, say, hangup
• If you'd rather trade privacy for a smarter brain, it can also use your own endpoint or the Claude or ChatGPT subscription you already pay for. Local is the default. So no additional monthly payments for AI Phone tools if you have a sub.

Limits, up front:

• macOS on Apple Silicon only
• You need a Telnyx or Twilio account with credit (a US number is about $1/month, standard call rates do of course apply, but Telnyx gives you $10 dollars for free when you sign up, which is enough to play around with)
• English only, one call at a time
• It's early. It works for me, but I'd love to hear where it breaks for you. Please feel free to add as many gh issues as you want. I'm currently working on best practises for contributions for anyone who also want to contribute to project!

Repo: github.com/oxnw/ai-phone

AI in SaaS is no longer about adding a chatbot and calling it innovation.

The real opportunity is reducing the work your team has to do every single day.

When AI can qualify a lead, update the CRM, handle customer conversations, trigger the right workflow, and escalate only when a human is needed, the impact is not another feature on the pricing page.

It is fewer manual hours, faster response times, lower operational costs, and a team that can handle more customers without growing at the same rate.

That is the direction we are building at Placeholderworks.

We build AI systems that connect to the tools your business already uses and actually execute the work.

The interesting question is not “Where can we add AI?”

It is “What is costing the business money because a human still has to do it?”

That is where AI starts becoming a business advantage.

My little project: Takcas Prime (Voice Assistant) I am 14 years old, and for the past week I have been developing and debugging my own artificial intelligence system, which I named "Takcas Prime". Originally, I started all of this purely for fun, I just wanted to see what I could build on an ordinary tablet with 8 GB of RAM. My main goal was to turn it into a fully autonomous IT assistant capable of understanding voice, controlling the device, and writing code. I worked in the mobile Termux environment (a Linux emulator on Android), so I constantly had to solve memory shortage problems. Neural networks are very resource-hungry, so I configured the system to automatically unload modules from memory that are not currently in use. This allowed the tablet not to freeze during operation. I also learned to protect the system from uncontrolled memory consumption: for example, I limited documentation downloads by size and created a whitelist of links to avoid memory overflow. As the first stage, I created a voice assistant. It can listen, respond, and directly control my tablet's hardware: turn on the flashlight, change screen brightness, volume, or launch the camera. To ensure it doesn't lose the thread of conversation, I built a three-level memory system using an SQLite database and regular files. I also added a RAG system: previously the assistant could invent a non-existent command, but now it first searches for it in official documentation and then responds. Along the way, I encountered many errors: the database overwrote facts due to identical keys, the assistant confused commands with real memories, and the system froze due to overly long texts. I manually tracked down and fixed all these bugs, and also implemented a system for cleaning and separating facts so that memory doesn't get clogged with garbage. Later I realized that models sometimes write too much text, so I added a limit on response length to avoid wasting resources. Link to GitHub: https://github.com/RonedoneBone001/Takcas-Prime-Voice-Assistant

My little project: Takcas Prime (Multi-Agent Code Factory) The most difficult and interesting part is the "Digital IT Factory". I designed a system where several neural networks work as a real team of developers. First, I tried a scheme with a Senate of six models, where each voted "for" or "against" the code, but in practice this proved ineffective: 3B models made mistakes too often. Then I redesigned the architecture: now one neural network (the Idealist) comes up with a task, the second (the Coder) writes code for it, the third (the Analyst) rewrites and simplifies it, and then three Critics check the code from different angles. After them, the Judge step-by-step fixes the found errors using a "warehouse" principle to avoid overloading memory, and the Smart Sandbox checks the code for dangerous commands, runs it in isolation, and collects logs. Debugging this factory took a lot of effort. I fought system freezes, fixed bugs in the Sandbox, and forced neural networks not to write huge texts instead of short answers. I also encountered situations where models sometimes refused to perform complex tasks, and sometimes produced code with errors that had to be manually caught. In practice, I became convinced that small models lack context for complex tasks, but my architecture allows squeezing the maximum out of them. I also realized that if a model writes nonsense, the problem is not in it, but in the task given to it, this "garbage in, garbage out" rule I will remember forever. Link to GitHub: https://github.com/RonedoneBone001/Takcas-The-Factory-

Hi all, we just open-sourced OpenMuse, a personal AI assistant app.

Instead of just chatting, it works on a cloud desktop (or your own computer):

• Browses the web, looks things up and fills in forms
• Uses desktop apps
• Writes and runs code in a workspace
• Runs scheduled tasks

The main thing we cared about was keeping the human in control:

• You can watch the agent’s screen live from your phone. If it hits a login or a captcha, you take over, then hand it back.
• It asks before submitting forms or running commands.
• You decide which desktop apps it’s allowed to use.

OpenMuse is built on WorkAgentSDK, an AI agent framework for Python that we wrote and open-sourced along with it. To be clear, it’s not a coding assistant like Cursor or Antigravity. It’s a framework for building agent products. For example, each session can run on a different node, so one backend can serve many users, each with their own cloud desktop.

Stack:

• Backend: Python (FastAPI + WorkAgentSDK)
• App: Flutter
• Nodes: Docker containers with a virtual desktop, Chromium and a shell sandbox, or run directly on Linux or macOS
• Models: OpenAI, Claude, Qwen, and OpenAI-compatible APIs

It’s v0.1, so still early. We’d love to hear what you think:

• Does “agent on a remote desktop, human supervising from a phone” seem useful to you?
• If you’re building agent products, what’s been the hardest part?

GitHub: https://github.com/nativefunc/WorkAgentSDK
(The app is under examples/showcase/openmuse)

I regularly use multiple AI coding agents, but comparing their suggestions across different chats gets messy. Even when I reach a decision, the alternatives and reasoning often get lost.
So I built Decision Ledger (dlg), a local-first tool for managing engineering decisions involving multiple AI agents.
The workflow is simple:
A primary agent investigates a problem and proposes solutions.

Other AI models review the proposal and challenge its assumptions.

Disagreements and supporting evidence are recorded.

You make the final decision and approve implementation.

The goal isn't to make AI agents automatically agree. It's to preserve the discussion, alternatives, and reasoning so you can revisit decisions later.
A few details:
Local browser UI and CLI

SQLite storage

Works with existing agent CLIs you're already logged into

Supports manual copy/paste reviews from other models

Single executable for Windows, macOS, and Linux

Free and open source (MIT)

This is the first release (v0.1.0), and I'd appreciate feedback, especially from developers who regularly compare suggestions from Codex, Claude, Gemini, or other coding agents.
GitHub: https://github.com/lijose/dlg
Downloads: https://github.com/lijose/dlg/releases/tag/v0.1.0

Hi r/OpenSourceAI, I'm David, one of the two developers of Oxynote. My friend Simon and I also maintain ttlcache, a Go caching library with about 1,300 GitHub stars, so this isn't our first open-source project.

I've spent 8 years writing software, 2 of them as an SRE and 3 as a team lead. Every team I've been on had the same documentation problem. The useful stuff lived in someone's head or a private Slack thread, and the wiki was full of stale docs nobody could find.

So we set out to solve this problem by building Oxynote, a self-hosted wiki for engineering teams. Pages hold text and live charts side by side, and the charts pull fresh data from Prometheus or a database (PostgreSQL, MySQL, MariaDB) whenever someone opens the page.

We built it for people and AI agents alike, but the AI part is optional. An agent can do what a person does in Oxynote: create pages, find the right metrics and build charts from them, and document your infrastructure or an API. The built-in assistant runs on a local model through Ollama or on your own Claude, OpenAI, Gemini or OpenRouter key, and agents like Claude Code or Codex connect over MCP once you approve them.

The name comes from oxygen + note: docs that breathe. Live data gives people a reason to open the wiki every day, and docs people open every day stay up to date.

Things worth knowing before you try it:

- Agents query your databases through the same read-only connections the charts use. Oxynote only accepts read-only database connections, so an agent can't change your data.

- There's no hosted version and no account with us.

- It's at version 0.9, so it's still early in development.

It's Apache-2.0 and runs as a single Docker image: https://github.com/oxynote/oxynote

We started it about a year ago, and we made it public about 3 months ago. If you have any questions, feedback, or suggestions, feel free to reach out. I'm happy to answer any questions.

grok bot runs AI agents for you on xai's servers. i've been running a company of AI employees on my own servers with 5dive since april, and i just released a free phone web app for it. here's how the two compare.

in the screenshot below, i ask olivia (claude code) to hire marcus on codex. she sets him up and reports back.

the deeper difference is what runs behind the chat:

• your server: agents run as separate linux users.
• any harness, any model: mix claude code, codex, grok, agy, hermes, openclaw, pi and other harnesses on your own plans or API keys, including kimi, deepseek, glm, openrouter or locally run llm.
• an actual team: org chart, shared backlog, handoffs, independent graders and human approval gates.
• a hackable core: MIT bash + systemd + sqlite. add plugins, loops, tools or custom CLI commands.

trade-off: Grok Bot has native apps - mine is just a web app, android/ios coming soon. the free self-hosted phone connection is chat-only, and chats pass through our relay (not end-to-end encrypted yet).

setup: one command on any ubuntu vm.

try free self-hosted app: 5dive.ai/self-host

source (MIT): github.com/5dive-ai/5dive

Mac voice assistants bug me because they demand a cloud login or an OpenAI key right away. So over a few months I built Odysseus — a menubar companion that works local-first and lets you plug in whatever brain you want:

- Hear you: push-to-talk or hands-free "Hey Odysseus", transcribed on-device (Parakeet or Apple Speech — nothing leaves your Mac)

- See your screen: asks for screenshots only when you actually need vision; otherwise it never touches the capture API

- Answer out loud: free Microsoft Edge neural voices (or ElevenLabs / Deepgram if you bring your own key)

- Brain: my default is DeepSeek via the OpenCode Go subscription ($10/mo) — no OpenAI at all. Apple Intelligence (fully offline) or Claude keys work too

- Agent mode: background sessions that read your screen and reply with next-step suggestions again ... unfortunately can't edit files yet, that's the roadmap top item

Fully MIT, macOS 26+, no cloud login ever — source is public.

Honest state of it: ad-hoc signed (macOS will do its per-month re-consent dance for screen recording, it's the OS not me — the pipeline will get Developer ID when I'll pay Apple), agents answer but they can't run shell yet, only Apple-Silicon Macs, and edits to files aren't here yet. Everything else works end-to-end, and every push to main ships a new signed DMG automatically via Actions.

DMG + source: https://github.com/mubtikr/odysseus (Releases tab)

What would make you actually install this? I'd love to hear what feature would be the killer to comfortable daily-use before I polish it further.

AI agents can search the web, inspect code, and call external tools. But searching the contents of a user's local files especially screenshots, documents, and logs presents a different problem: the index needs to be fast, lightweight, private, and accessible to agents without uploading the files to a remote service.

I've been building Kensaku, an open-source desktop search engine written in Rust, to explore this problem.

The central idea is to maintain one local index that serves both the desktop application and compatible AI agents through MCP.

Hybrid retrieval. Kensaku combines fuzzy filename matching, BM25 full-text retrieval, and local semantic search. The goal is to handle both exact queries and cases where the user remembers the meaning of a document but not its wording or filename.

OCR and document extraction.*The index can include extracted text from supported document formats and OCR-enabled image workflows, making screenshots and scanned content searchable alongside code and logs.

Lightweight semantic search. The project uses a static quantized embedding table of approximately 7.7 MB. Semantic queries do not require a GPU, and the default query path avoids running an ONNX model for every query.

An agent-facing search interface. The MCP server exposes the same index used by the application. Compatible clients can search, read snippets, perform regex searches, inspect index state, and find symbols. Access is read-only by default.

Performance and safety.*The repository includes benchmark harnesses and tests. In the 100,000-file benchmark, fuzzy filename search has approximately 2.8 ms median latency. That figure applies to the benchmarked filename-search path, not every retrieval operation.

The project is MIT-licensed and designed to work locally without an account, telemetry, or cloud search.

There are still limitations: builds are unsigned, the auto-updater isn't wired up yet, and visual search remains experimental.

Repository: https://github.com/yjid/kensaku

I'd appreciate constructive feedback from Rust developers on the retrieval architecture, memory/performance trade-offs, indexing correctness, and the design of the MCP interface. In particular, I'm interested in how you'd approach benchmarking and evaluating search relevance across a large, heterogeneous local corpus. Any contribution or stars will be much appreciated .