switch

We Tried Building an AI Security Researcher That Never Sleeps A few days ago, Binance disclosed a major security incident involving approximately $6.34 billion in impacted digital assets. Let that sink in for a second. $6.34 billion. Binance later explained that the attack involved compromised internal systems and unauthorized wallet transactions. The company also said it would absorb the financial impact rather than pass it on to users. And this isn't just a Binance problem. It's a reminder of how expensive security failures can become, even for companies with dedicated security teams. Meanwhile, we're in a world where developers are shipping code faster than ever. AI has made building products significantly easier, but security hasn't necessarily caught up with that speed. More code is being shipped, more products are going live, and vulnerabilities can easily slip through the cracks. We started thinking: what if teams had a security researcher working alongside them all the time? Someone who could investigate potential vulnerabilities without having to wait for a manual security review. Well, we decided to try building exactly that. Meet Hackclawd 🦀 We tried putting an AI security researcher inside Slack that never sleeps, never takes a day off, and doesn't ask for weekends off. 😂 That's basically Hackclawd. We built an AI-powered bug bounty agent that works directly inside your team's Slack workspace, powered by Switch. The idea was pretty simple. Developers already spend most of their time collaborating in Slack, so why should security testing feel like an entirely separate workflow? With Hackclawd, you simply give it an authorized bug bounty program or codebase, and it gets to work. So, how does it actually work? Once you mention Hackclawd in a Slack channel and provide the program details and scope, it kicks off its security workflow. It investigates potential vulnerabilities across different surfaces, including: - Web applications - Solidity and smart contracts - AI systems But here's where things get interesting. We didn't want to build another AI tool that scans some code, throws a bunch of suspicious findings at you, and calls it a day. Hackclawd also validates potential findings by running proof-of-concept code inside an isolated Upstash Box sandbox. The sandbox has restricted network access, so PoC execution happens against local copies rather than live targets. Once it's done, Hackclawd sends a report back to Slack containing the potential vulnerability, supporting evidence, proof-of-concept code, and reproduction steps. Findings remain candidates until a human reviews and confirms them. Basically, it does the heavy lifting while your team stays in the workflow they're already familiar with. Building it with Switch One of the interesting parts of this project was bringing everything together. We used Switch to connect Slack to our AI agent and manage conversations across channels and threads. Under the hood, we also integrated: - Nebius: For the AI model powering the agent. - Upstash Box: For isolated proof-of-concept execution. - Slack: The interface where teams interact with Hackclawd. sandbox-quantum/switch - Switch: The layer connecting everything together. Getting these pieces to work together into one workflow was a fun engineering challenge. What's next? Hackclawd is our attempt at making security research more accessible and less painful for development teams. We're not trying to replace security researchers or claim that an AI agent can catch every vulnerability. We just think teams should have a way to automate more of the tedious work involved in finding and validating bugs. Because if AI is helping us write code faster, maybe it should also help us find the security issues in that code. And honestly, having a security researcher in Slack that never asks for a day off sounds pretty cool to us. 😂 Built with Switch. Check out the project: fozagtx/hackclawd #BuildWithSwitch #Cybersecurity #AI #BuildInPublic

Handover: I made three AI agents run an exit interview in team chat When someone leaves a team, the things they know usually leave with them. You find out three weeks later, when a cron job fails at 2 a.m. and the only person who knew the fix is gone. The runbook says "TODO". For the Flip the Switch hackathon I built Handover. Three AI agents and the people involved run the handover in an ordinary chat channel. This post covers what it does, how to set it up from zero, and what I got wrong along the way. - Repo: PinnacleCryptNG/handover - Demo video: youtu.be What it does Handover has two rooms and three agents: | Room | People | Agents | | --- | --- | --- | | payments-handover | Ada (leaving), Maya (manager) | Interviewer, Scribe, Buddy | | payments-onboarding | Ben (taking over), Maya | Buddy, Scribe | 1. The Interviewer reads the system's folder first: code, cron file, runbook. Then it interviews Ada one question at a time. It asks what she owns, the recurring jobs, how things break, access and contacts, open promises, and the "never do X" rules. 2. The Scribe checks each answer against the files. It writes HANDOVER.md, where every fact has a source: "(Ada, interview)" or "(ops/crontab:3)". Anything nobody confirmed goes under Open questions. Nothing is guessed. 3. Maya, the manager, reads the guide in chat, asks for changes and replies "approve". 4. Only then does the Scribe publish the guide as a room document in Ben's room. 5. The Buddy answers Ben's questions from the guide. If the guide has no answer, it asks Ada in the other room, brings her reply back to Ben and tells the Scribe to update the guide. The sample system is a small, made-up payments sync (workspace/ledger-sync). It has the kind of gaps real systems have: a month-end job the runbook marks TODO, a hard-coded FX fallback rate and a rate-limit workaround nobody wrote down. !Ada answers the Interviewer; Ben's room waits for the approved guide Why Switch Switch connects coding agents like Claude Code, Codex and OpenCode to normal chat rooms. Five Switch features carry this project: - Templates: one YAML file creates all three agents, both rooms, a room group, the links between the rooms and the first message in each room. - @mentions: people and agents talk by mentioning each other in a normal Mattermost channel. Slack, Teams, Discord and Telegram work the same way. - Linked rooms: the Buddy can carry a question from Ben's room to Ada's room and back. - Room documents: the approved guide is a document attached to the onboarding room, so everyone there reads the same text. - Working directories: all three agents run inside the system's folder, so the Scribe can cite a file and line instead of trusting the interview. Setting it up from zero You need Docker and an agent provider. 1. Switch Console and a local server Download Switch Console from the releases page and choose Run a local server. Console starts the Switch server and a Mattermost instance in Docker on your machine, so you don't need a Slack workspace to try it. Two Linux tips that cost me time: - Mattermost might not be on port 8065. Console picks free ports. Read the real one from ~/.config/switchdash/local-switch-server/ports.json. - Secret storage. On a Linux machine without a desktop keyring, Console warns that secure storage is unavailable. Installing gnome-keyring and starting Console with --password-store=gnome-libsecret fixed it. 2. An agent provider I used OpenCode with Kimi K2.6 on Nebius Token Factory. Any OpenAI-compatible endpoint works the same way. This is ~/.config/opencode/opencode.json: { "provider": { "nebius": { "npm": "@ai-sdk/openai-compatible", "options": { "baseURL": "https://api.tokenfactory.nebius.com/v1/", "apiKey": "{env:OPENAI_API_KEY}" }, "models": { "moonshotai/Kimi-K2.6": { "name": "Kimi K2.6" } } } }, "model": "nebius/moonshotai/Kimi-K2.6" } Export your key as OPENAI_API_KEY before starting Console. The key stays in your environment and never goes into the file. Claude Code or Codex also work: pick them under Advanced when you use the template. 3. Users You need one person for each role. For a demo, create them in the local Mattermost: C=$(docker ps --format '{{.Names}}' | grep mattermost) for u in ada ben maya; do docker exec $C mmctl --local user create --username $u --email $u@example.com --password "<choose one>" docker exec $C mmctl --local team users add switch $u done 4. The template In Console, open Templates → Import template, pick templates/handover.template.yaml, then Use template. The form comes from the template's params: a name for the handover, the three people, the system folder and the chat app. The preview on the right shows what will be created. !The template form and its preview: three agents, two rooms The rooms and links part of the template is short: rooms: - name: "{slug}-handover" agents: ["{slug}-interviewer", "{slug}-scribe", "{slug}-buddy"] users: ["{$creator}", "{leaver}", "{manager}"] kickoff: | @{slug}-interviewer @{leaver} is leaving and hands {slug} over to @{successor}. Read the system folder, then greet @{leaver} in one line and ask your first question. - name: "{slug}-onboarding" agents: ["{slug}-buddy", "{slug}-scribe"] users: ["{$creator}", "{successor}", "{manager}"] links: - { from: "{slug}-onboarding", to: "{slug}-handover", label: interview with the leaver } - { from: "{slug}-handover", to: "{slug}-onboarding", label: successor's room } Most of the work is in each agent's instructions, which are plain English. Click Create all, and the Interviewer greets the leaver within seconds. 5. Run it Sign in to Mattermost as ada and answer the questions. Sign in as maya to review the guide, and as ben to ask the Buddy things. If you want to replay a run, scripts/mm.py posts and reads messages as any user through the Mattermost API. !The Scribe's summary, Maya's change request and her approval !Ben asks two questions; the Buddy answers one from the guide and gets the other from Ada What I learned An agent only sees messages that mention it. This caught me during the recorded demo. The Interviewer posted its notes as plain messages, without @payments-scribe in front. It finished with "interview complete", and the Scribe never woke up. The instructions said "tell the scribe", which isn't the same as "start the message with @payments-scribe". The fix was to spell it out and give the reason: *"post a note that starts with @{slug}-scribe (the scribe only sees messages that mention it)"*. Name the role, not just the person. In one run, the Scribe asked Ada to approve her own guide, probably because she was the last person who had talked to it. Changing "ask @{manager}" to "ask @{manager} (the manager, not the leaver)" fixed it. With templates, a placeholder becomes a username at runtime, so the agent can lose track of what that person's role is. "Read the folder first" is the most useful line in the template. Because the Interviewer reads the code before it asks anything, its first question already names the system: "You own ledger-sync — who else depends on it staying healthy?" The Scribe also caught a gap Ada never mentioned: the month-end section of the runbook still says TODO. Make the agent cite sources. Requiring a source on every fact, and an Open questions section for everything else, made the guide trustworthy. It also gave the Buddy a clear rule: if the answer isn't in the guide, don't make one up, ask Ada. Approval should be a real gate. The Scribe publishes only after the manager replies "approve" in chat. Maya's change ("make Ben the owner of the token rotation") shows up in the guide before it reaches Ben. Try it Clone the repo, import the template and point System folder at workspace/ledger-sync, or at a real system you're about to hand over. The full transcript of a run is in examples/transcript.md and the guide it produced is in examples/HANDOVER.md. #HowISwitch

Switch from zero: ship a human-in-the-loop data quality agent to your team chat I spent the Flip the Switch hackathon building Shield, an agent that checks a daily table, explains what it finds in a team channel and only fixes data after a person approves. This post is the guide I wish I had on day one: how to self-host Switch with no desktop app, how a custom agent joins a room, and the three things that will block you the first time. Everything here was run on Switch 0.31.0 in a GitHub Codespace. All the data is fictional. Shield at a glance - 6 incident types caught: stale business date on a green pipeline, row count drop, schema drift, null spike, duplicate keys and a late upstream file - 5 Great Expectations expectations plus the business-date gate behind those checks - 5 fix actions, and 0 of them run without a person approving in the chat - 42 unit tests, plus an end-to-end test that plays every scenario through a real Switch server on a fresh GitHub runner - US$ 0 to run: self-hosted Switch, a local open model, free CI {% embed youtu.be %} Raw screen recording of the chat, no edits: shield_demo.mp4 !Approving a fix in the channel: Shield holds the report, re-runs the partition, checks again and releases the hold What Switch is, in one paragraph Switch turns a chat channel (Slack, Teams, Discord, Telegram or Mattermost) into a room where people and AI agents work together. Switch ships no agents and no models. It gives you the room, the membership, the shared documents and a wire protocol, and your agent brings the brains. That split is why it fits a "human in the loop" workflow so well: the approval happens where the team already talks. There are two ways in: - Switch Console, the desktop app, runs a server for you and manages Claude Code, Codex or OpenCode agents. This is the 10-minute quickstart. - Self-hosting with the published Docker Compose file, plus any agent that speaks the protocol. This is what I did, because I wanted a custom Python agent and a headless setup I could run in CI. Step 1: start a Switch server with its own Mattermost You need Docker with Compose v2. The server, its database, the Gateway (admin surface) and a bundled Mattermost all come from one compose file in the Switch repo. git clone https://github.com/sandbox-quantum/switch.git && cd switch cp .env.example .env bash deploy/local/generate-env-secrets.sh .env local # fills every password and token sed -i 's/^SWITCH_VERSION=.*/SWITCH_VERSION=0.31.0/' .env docker compose -f deploy/local/standalone-docker-compose.yml --project-directory . \ --profile collab --profile gateway up -d Three things worth knowing: 1. Pin SWITCH_VERSION. The compose file refuses to start without it, on purpose. Take the version from the container registry, not from the GitHub releases page, which tracks the desktop app. 2. The collab profile is Mattermost; gateway is the admin surface. With both on, a setup container creates a Mattermost admin, a normal user called user, a team called switch, and links Mattermost as the default bridge. When docker wait on that container returns 0, you are ready. 3. Ports: 8000 is the API and the agent bridge, 3000 the Gateway, 8065 Mattermost. Everything binds to 127.0.0.1 by default. In my repo the script moves them to 18000/13000/18065 so they never collide with another Switch. !Mattermost after setup: the data-quality channel with Shield as a member Step 2: register a custom agent An agent is registered once, out of band, with the server's AGENT_REGISTRATION_TOKEN from .env. For a process that is always running (rather than a session Console starts on demand), use the lower-level POST /agents with an always_on connection model: import requests r = requests.post(f"{SWITCH}/agents", headers={"Authorization": f"Bearer {REGISTRATION_TOKEN}"}, json={ "name": "shield", # what people type after @ "description": "Data quality teammate", "connector_type": "custom-python", "integration_profile": { "connection_model": "always_on", "message_exchange": True, "pre_invocation_mediation": [], "post_invocation_mediation": [], "event_reporting": [], "command_capabilities": {"reset": "unsupported", "compact": "unsupported", "interrupt": "unsupported"}, }, "tools": [], "models": [], "metadata": {}, "overwrite": True, }) agent_id, api_key = r.json()["id"], r.json()["api_key"] # the key is shown once: store it The convenience route POST /agents/register-known only knows Claude Code, Codex, OpenCode and Antigravity, so a custom agent goes through POST /agents. Step 3: open the event stream and keep it alive Down is one Server-Sent Events stream, up is plain HTTP. The part that trips people up is that the connection is identified by an id you generate, not by the socket: conn = str(uuid.uuid4()) # generate once, reuse on every reconnect stream = session.get(f"{SWITCH}/agents/{agent_id}/events", params={"connection_id": conn, "scope": "single", "filter": "addressed", "rooms": room_id}, headers={"Accept": "text/event-stream"}, stream=True) - The first frame is always connection_state. Read the rooms and cursor from it rather than assuming. - Beat every 2 seconds with POST /agents/{id}/connection/beat and {connection_id, cursor}. The TTL is 6 seconds. A 404 or 409 on the beat means "reopen the stream", not "back off". - filter=addressed means you only receive messages that mention your agent. That is what you want for a chat agent. - Declare the room on the URL (rooms=). A room subscribed after the stream opens can miss its buffered events. Shield's whole client is about 150 lines: shield/switch_client.py. Step 4: create the room, and the channel appears Operations are POST /agents/{id}/ops/{name} with the arguments as the body, plus an X-Switch-Connection-Id header when the operation needs a connection. create_room on the default bridge creates the Mattermost channel for you: room = op("create_room", { "name": "data-quality", "description": "Data quality incidents for sales.orders", "agent_names": ["shield"], # include yourself, or you are not a member "user_names": ["user"], # Mattermost usernames "channel_type": "channel_public", "instructions": "Shield never changes data without an approval in this room.", }, connection_id=conn) To answer in the room, POST /agents/{id}/message with {room_id, content} needs no connection at all. Markdown renders in Mattermost. Step 5: the three things that will block you 1. "You're not permitted to direct messages to me in this room." A new agent answers only its owner, and an agent registered with the registration token is owned by a bootstrap account, not by you. Nobody can talk to it. The Gateway admin (credentials in .env) can clear the policy: s = requests.Session() s.post(f"{SWITCH}/gateway/auth/login", json={"email": ADMIN_EMAIL, "password": ADMIN_PASSWORD}) s.put(f"{SWITCH}/gateway/agents/{agent_id}/addressing-policy", json={"policy": None}) With no policy, room membership decides who can reach the agent. In production, set a policy that names the people allowed to approve. 2. "I'm currently offline: my connector isn't reporting in." Switch answers on your agent's behalf until it sees heartbeats. If your test posts a message in the first seconds after the agent starts, the agent never sees it. My end-to-end test simply asks @shield help until the real answer comes back. 3. Nothing happens and there is no error. Messages that do not @mention the agent are delivered to nobody when you use filter=addressed. Check the Switch logs (docker logs <project>-switch-1): lines from switch_core.delivery.addressing tell you exactly why a message was or was not delivered. Step 6: make the human the gate This is the part that makes it a workflow rather than a bot. Shield follows one rule: a scan only records findings; only an approval changes data. !Shield's finding in the channel: what broke, why it matters, who is affected, and the proposed fix Each finding gets an id and three possible answers, all plain messages in the room: - @shield approve F-1 runs the proposed actions, checks again, and posts the result. - @shield edit F-1 hold_dashboard+notify_owners changes the plan before approving. - @shield reject F-1 known test load closes it with a reason and touches nothing. Switch passes the sender's name with every message, so the audit trail records who decided. Shield writes that trail to a room document (create_room_document, then update_room_document), which every member of the room can read later. !The audit trail Shield keeps in the room: who did what, and when The main check is the business-date gate from my article Your pipeline ran green and shipped last week's data anyway: the greatest attempt per job and date wins, and a date is ready only when every required job's newest attempt succeeded for that date. The other five checks (schema, row count, nulls, duplicates, late files) are a Great Expectations suite, and owners come from a catalog adapter shaped like OpenMetadata's API. Where the AI sits, and where it does not Shield's language model is a small open model, Gemma 3 4B, served on the same machine by Ollama through its OpenAI-compatible API, so it costs nothing and no data leaves the host. It has two jobs: - It writes the "why it matters" line from the finding. If its answer contains a number or runs long, Shield throws it away and uses a fixed sentence, because the numbers have to come from the checks. - It understands plain language. @shield are today's numbers ok to publish? runs a scan. @shield sure, go ahead with F-1 does not approve anything: Shield answers "I read that as @shield approve F-1. I only change data on an exact command." A misread can cost a message, never a table. That boundary is the design choice I would repeat in any agent that touches production data: let the model read and explain, and keep every write behind an exact, human command. Step 7: test it like a person would Mattermost has a plain REST API, so an end-to-end test can log in as the demo user, post @shield break stale_business_date, @shield scan, @shield approve F-1, and wait for each reply. In my repo, that runs on a fresh GitHub Actions runner on every push: start Switch, register Shield, play every scenario. If the test passes, the README is telling the truth. What I learned - Switch does the parts I did not want to build: who is in the room, who may talk to the agent, where the shared notes live, and the bridge to whichever chat app the team uses. My agent only had to speak HTTP and SSE. - Read the server's answer, not your request. The connection_state frame, the heartbeat response and the addressing logs all tell you what Switch actually decided. - Keep the transport out of your logic. Shield's command handling takes a string and returns replies, so 42 unit tests run with no server at all, and the Switch-specific code stays small. - Put the gate in the conversation. A check that blocks a pipeline is useful. A check that explains itself to the people who own the data, and waits for one of them to decide, is a workflow. The code, the setup script and the end-to-end test are here: jenniferevangelista-de/shield-for-data.

@kunalstwt @WeMakeDevs @WeAreDevs perfect, then it's whatsapp-first. forward the "sent you 500" messages to a bot, it keeps the ledger and tells everyone who owes whom at the end. already wired whatsapp + twilio in my oss PRs, so this one's happening switch#1166 switch#1244

团队散在 Slack、Teams，AI 队友各聊各的？ switch 是自托管 AI 队友平台：每个频道变成人和 agent 同房间，共享上下文，换 agent、换模型都不丢。 多平台协作的话，同房间共享上下文比来回转发强。 先把它接进哪个频道，是 Slack 还是 Teams？ #AI队友 #开源@grok sandbox-quantum/switch

Agents 2.0 is here! Master Full-stack AI Engineering In today's newsletter: - This inference engine runs LLMs 4x faster than llama.cpp. - Agents 2.0 is here! - Continuous batching in LLMs, explained visually. TODAY'S ISSUE OPEN-SOURCE This inference engine runs LLMs 4x faster than llama.cpp: We ran Qwen3.5 9B on a base M5 MacBook Pro using three local inference engines, one at a time. - llama.cpp reached 22.0 tokens/s - MLX reached 25.1 tokens/s - Uzu reached 92.1 tokens/s The video shows all three runs side by side. The first two results do not mean llama.cpp or MLX are poorly optimized. Both are approaching a physical limit of ordinary local decoding. Generating each new token normally requires another pass through the model. That pass streams roughly 5.2 GB of weights through memory. A base M5 provides about 153 GB/s of memory bandwidth. At one token per pass, the theoretical ceiling is roughly 153 ÷ 5.2, or 29 tokens/s, however fast the GPU computes. Uzu gets past that by optimizing speculative decoding for Apple Silicon. Speculative decoding uses a smaller drafting system to propose several future tokens. The full 9B model then checks those proposals together instead of generating every token through a separate pass. Uzu pushes this further in two ways. → It drafts up to 16 positions and uses Weaver to turn independent guesses into coherent sequences. → It verifies several possible sequences as a tree, then commits state only for the path the full model accepts. The 9B model remains in control of the final output. Uzu simply gives it more useful work to approve in each pass. In our run, every pass of the 9B model produced 7.5 output tokens on average. Ordinary decoding produces exactly 1. That is how Uzu reached 92.1 tokens/s on hardware whose one-token-per-pass ceiling is roughly 29. The rest of the engine is designed around this path too. Uzu ships its own quantized checkpoints, and on M5 chips its Metal kernels run verification through the GPU’s accelerated int8 matrix path. It is an open-source inference engine with bindings for Rust, Swift, Python, and TypeScript. The repository is here: trymirai/uzu (don't forget to star 🌟) TOGETHER WITH SWITCH Agents 2.0 is here! Anthropic. OpenAI. xAI. Are all racing to build an AI coworker. These are agents that can work alongside humans, talk to other agents, and coordinate tasks in a shared workspace. But the catch is that each product ties the model, runtime, memory, and orchestration to one company’s stack. Most teams won’t use one provider for every job. They may use Claude Code, Codex, OpenCode running locally, and custom agents for internal systems. Making them collaborate with each other and your team usually means building the glue yourself. That is vendor lock-in. In the video above, we have shown how to bring humans and agents from different providers into one shared workspace using an open-source coordination layer you can host yourself. Humans can talk directly to agents. Agents can talk to each other. And people can join the conversation, add context, or give further instructions as the work unfolds. The project is called Switch, and it brings this collaboration into Slack, Teams, Discord, Telegram, or Mattermost. You give each agent a role and can work through a Manager. The Manager creates rooms, brings in the relevant agents, carries context between them, and returns the result. In the video below, we gave the Manager two incidents. → The inference API started returning 500s after a morning deploy → A recommendation-model training job had been frozen for six hours From one message, it created two linked rooms, brought in a Software Engineer, Architect, and QA Lead, and ran both investigations in parallel. Then the engineer investigating the training failure checked the linked inference room and spotted the same config push behind both failures. The Manager returned one consolidated RCA to the original channel. Throughout the run, we could follow the conversations, give additional instructions, and inspect the underlying agent sessions in Switch Console. That is what we mean by Agents 2.0. Humans and agents working together, sharing context, and contributing as the work unfolds. We build everything locally with Docker and Mattermost and follow the run through to the final handoff. Models will keep changing, so the coordination layer should be able to run separately from any one provider. GitHub: sandbox-quantum/switch (don’t forget to star 🌟) LLMOps Continuous batching in LLMs, explained visually: In traditional ML inference, a batch is a matrix. Every input is padded to the same length, one forward pass runs, and every row finishes at the same moment. LLM decoding does not work that way. One forward pass produces one token per sequence, so a request needs as many passes as it has output tokens, and nobody knows that count until the model emits a stop token. Under static batching, membership is fixed when the batch starts. A request that finishes in 30 tokens holds its slot until the slowest request in the same batch finishes at 400. The GPU keeps paying the full weight read for a batch that is mostly empty. Loading model weights out of HBM costs the same whether four slots are producing tokens or one. Continuous batching moves the decision boundary. Instead of scheduling once per batch, the scheduler runs a single forward pass, gets control back, and decides again. A finished request leaves at the next iteration boundary, and a queued request takes its slot right there. No slot stays reserved for work that is already done. Anyscale benchmarked both OPT-13B on a single A100. With uniform generation lengths, the two policies came out about level (as expected), and as output length variance rose, static batching fell to around 81 tokens per second while vLLM reached 23x the throughput of naive Hugging Face serving. Variance drives the entire gap. Production traffic mixes 30-token replies with 400-token ones, which is exactly the condition static batching handles worst. None of this alters the model. vLLM, SGLang, TGI, and TensorRT-LLM all run it by default, and NVIDIA implements the same mechanism under the name in-flight batching. The animation below depicts the continuous batching process: To dive deeper into continuous batching specifically, we wrote a full breakdown of the scheduler underneath it. It covers what happens between two forward passes, how tokens get handed out against a fixed budget, why the scheduler needs no separate path for prefill and decode, and what preemption costs you when the KV cache fills up mid-generation. Read it here → THAT'S A WRAP NO-FLUFF RESOURCES TO... Succeed in AI Engineering roles All businesses care about impact. That’s it! - Can you reduce costs? - Drive revenue? - Can you scale ML models? - Predict trends before they happen? We have discussed several other topics (with implementations) in the past that align with such topics. Master full-stack AI engineering Here are some of them: - Learn MLOps from first principles to production in this course with 18 parts → - Learn everything about MCPs in this course with 9 parts → - Learn how to build Agentic systems in this course with 14 parts. - Learn how to build real-world RAG apps, evaluate, and scale them in this course. - Learn sophisticated graph architectures and how to train them on graph data in this course. - So many real-world NLP systems rely on pairwise context scoring. Learn scalable approaches here. - Learn how to run large models on small devices using Quantization techniques. - Learn how to generate prediction intervals or sets with strong statistical guarantees for increasing trust using Conformal Predictions. - Learn how to identify causal relationships and answer business questions using causal inference in this course. - Learn how to scale and implement ML model training in this practical guide. - Learn techniques to reliably test new models in production. - Learn how to build privacy-first ML systems using Federated Learning. - Learn 6 techniques with implementation to compress ML models. Master full-stack AI engineering All these resources will help you cultivate key skills that businesses and companies care about the most. Partner with US ADVERTISE TO 950k+ AI Professionals Our newsletter puts your products and services directly in front of an audience that matters, including thousands of leaders, senior data scientists, machine learning engineers, data analysts, etc., around the world. Get in touch today by replying to this email. Today’s email was brought to you by Avi Chawla and Akshay Pachaar. Looking for more? Unlock our premium DS/ML resources. © 2026 Daily Dose of Data Science

Announcement: Flint AI is now Switch AI. Hey everyone, Giving you all the heads up that we're having a bit of a rebrand. Flint AI is now Switch AI. As a result, we're moving our reddit community to reddit.com . We're renaming our free collaboration solution, Switch - to Switch Rooms. The repository name is unchanged, so you'll continue to receive updates as normal and can grab an updated copy of the code at any point here. If you've been using our free Flint CLI tool, we've renamed the repo to "switch-trust-cli", there's a redirect in place so you should pick up the new versions automatically as they're released. We'll continue to cross-post activity and info from our new home on reddit to this one, but this space will be left read-only and will eventually be retired. We hope to see you at our new home!

@github_skydoves @switch_ai_ Repo for anyone who wants to skip the shortlink: sandbox-quantum/switch. Beyond Slack, Teams and Discord it also bridges Telegram and Mattermost, so a Claude Code agent on your laptop and a teammate's Codex agent can sit in the same channel.