Show

We were always frustrated by the little effort made towards building agentic models that run on budget phones, so we conducted investigations that led to an observation: agentic experiences are built upon tool calling, and massive models are overkill for it. Tool calling is fundamentally retrieval-and-assembly (match query to tool name, extract argument values, emit JSON), not reasoning. Cross-attention is the right primitive for this, and FFN parameters are wasted at this scale.

Simple Attention Networks: the entire model is just attention and gating, no MLPs anywhere. Needle is an experimental run for single-shot function calling for consumer devices (phones, watches, glasses...).

Training: - Pretrained on 200B tokens across 16 TPU v6e (27 hours) - Post-trained on 2B tokens of synthesized function-calling data (45 minutes) - Dataset synthesized via Gemini with 15 tool categories (timers, messaging, navigation, smart home, etc.)

You can test it right now and finetune on your Mac/PC: https://github.com/cactus-compute/needle

The full writeup on the architecture is here: https://github.com/cactus-compute/needle/blob/main/docs/simp...

We found that the "no FFN" finding generalizes beyond function calling to any task where the model has access to external structured knowledge (RAG, tool use, retrieval-augmented generation). The model doesn't need to memorize facts in FFN weights if the facts are provided in the input. Experimental results to published.

While it beats FunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350M on single-shot function calling, those models have more scope/capacity and excel in conversational settings. We encourage you to test on your own tools via the playground and finetune accordingly.

This is part of our broader work on Cactus (https://github.com/cactus-compute/cactus), an inference engine built from scratch for mobile, wearables and custom hardware. We wrote about Cactus here previously: https://news.ycombinator.com/item?id=44524544

Everything is MIT licensed. Weights: https://huggingface.co/Cactus-Compute/needle GitHub: https://github.com/cactus-compute/needle

When you sell software to large businesses, you realize that each customer needs their own workflow and features. Traditionally, this either means long engineering roadmaps or the customers end up using workarounds.

But what if everyone could build their critical missing features just by talking to an AI? That’s what we do at Gigacatalyst. We provide an AI customization layer for your customers, CS team, and sales team to build these missing critical workflows without needing any engineers at all. Think Lovable, but built on top of YOUR platform.

We connect to your product's APIs, learn your data model and design system, and let non-technical users build governed apps via natural language - inside your product, under your brand.

Here’s what it looks like in action: https://www.youtube.com/watch?v=_taSpSphH6E

One of our customers, a Series B company, saw their users (not engineers - managers, ops people, facility directors) build critical workflows like:

- Parts stockout prevention: A maintenance manager typed "show me which parts will run out in the next 2 weeks based on usage over the last 90 days, accounting for vendor lead times." The app tracks consumption velocity, forecasts stockouts, and alerts before it's too late. He says it's prevented ~$500K in emergency downtime.

- Invoice OCR from phone photos: Technicians kept losing paper invoices. The prompt: "upload a photo of the invoice, extract vendor name, date, amount, and line items, then match it to the purchase order and flag discrepancies." Now techs snap a photo on-site to automatically add to the system of record.

- Restaurant emergency triage: A pizza chain's facilities manager was drowning in maintenance requests. He built a priority matrix: "walk-in freezer not cooling" auto-routes as CRITICAL, "dining room light flickering" goes to LOW. He's now able to manage backlogs with the correct priority.

How Gigacatalyst works under the hood:

1. Agentic API discovery: Our agents go through your app and parse your endpoints, query params, request/response shapes, and sample data to build the base layer.

2. Generation and Validation: When a user describes what they want our AI generates an app. We set up multiple validation steps, including static checks, runtime error analysis, and LLM-as-a-judge.

3. Sandboxing and Compilation: We wrote our own compilation and sandboxing framework to get the fastest speeds and lowest costs. This means that users can interact with the built app in seconds.

4. Proxy layer: We create a proxy layer for all APIs to handle auth, tenant isolation, and rate limiting. Everything the agent has access to is controlled, logged, observed, and version controlled.

After 2000+ daily users, 900+ apps built, and 70% 30-day retention, today we're opening a public demo.

Try it: https://app.gigacatalyst.com/ - enter your SaaS product's API URL (or just the homepage) and start prompting.

If you're serving a variety of use cases, you probably deal with a lot of custom requests and Gigacatalyst will save you time and increase your bottom line. Book a meeting at https://gigacatalyst.com/#contact and I'll help your team and customers build new functionality on top of your platform.

I've been reading Hacker News since I was 12 years old. I'm proud to launch for all of you and I want to hear your feedback on my product and comments!

As an experiment to answer this, I set out to create a neural window manager, training a neural network to predict what the screen would look like next.

Basically, the idea was to generate the next frame based on the last two frames and the mouse position. That's it: moving windows without programming an event system, just a simple convolutional neural network guessing pixels.

To implement the experiment, I used Pygame to simulate a turquoise desktop background, a gray window with a navy blue title bar, a white cursor, and four colors in total. Then, a bot randomly dragged the window, and I recorded everything, processing the frames as color index matrices (not RGB, to avoid complications) and the mouse delta (dx, dy, click) that caused each transition. 8000 frames, a few minutes in Colab.

The model is a unitary neural network (UNET). The encoder compresses the stacked frames, the decoder reconstructs the next one, and the mouse vector coordinates are projected with a linear layer to fit the spatial size of the bottleneck. There, they are concatenated before decoding, so that motion information feeds each jump connection.

And it works! Which still surprises me a little. You can drag, and the window follows you; when you release, it stops. There's no internal state, no (x, y) coordinates anywhere. The model infers the position from what it sees, which works until it doesn't. But after a couple of seconds of strange movement, the window starts to distort.

This will probably improve with more computing power for training and more examples, but to narrow the scope of the experiment and test it within a web browser, I decided to abandon the rendering aspect and have the model predict primitives instead of pixels, simply converting the motion engine into a neural network.

Basically, I trained a small MLP to receive (distance to the title bar, distance to the resize point, click) and generate (dx, dy, dw, dh), with two separate heads: one for moving and one for resizing. The trick is that they share nothing except the click signal, so the model can't confuse dragging with resizing. I then exported it to ONNX as well, and now everything runs in the browser, without a server, just a canvas element and two small neural networks communicating with each other.

With this new approach, the renderer remains deterministic, with rectangles drawn in JavaScript, but the window's behavior (where it moves, how it resizes) is learned from examples. It feels like a peculiar middle ground between traditional and neural, so you can feel the space the network has learned by interacting with it: dragging near the title bar moves it, but approaching the corner resizes the window. There are no conditionals or hitbox code; the network simply learned where those areas are from examples.

Sometimes it gets confused near the edges, which, frankly, is more interesting than if it worked perfectly; you can perceive how the probability changes. This makes sense when you think about it, because no (x, y) coordinates are stored in these models; the position is implied in the activations. It works well for short sequences, but fails when asked to maintain state over time.

Update: A few weeks later, Meta published the Neural Computers article (2604.06425, it's worth reading). The premise is the same, but they go much further: cli and uis, real programs. Their failure modes are practically identical to those I found with the pure pixel version: "challenges persist with routine reuse, controlled updates, and symbolic stability." which is a fancy way of saying that the window blurs after a few seconds (that was the reason for choosing deterministic rendering).

You can download it here: https://www.hypercubic.ai/hopper, and you can also request access and immediately get a mainframe user account to play with.

There's also a video runthrough at https://www.youtube.com/watch?v=q81L5DcfBvE.

Mainframes still run a surprising amount of critical infrastructure: banking, payments, insurance, airlines, government programs, logistics, and core operations at large institutions. Many of these systems are decades old, but they continue to process enormous transaction volumes because they are reliable, secure, and deeply embedded into business operations.

A lot of that software is written in COBOL and runs on IBM z/OS. The development environment looks very different from modern cloud or Unix-style development. Instead of GitHub, shell commands, package managers, and CI pipelines, developers often work through TN3270 terminal sessions, ISPF panels, partitioned datasets, JCL, JES queues, spool output, return codes, VSAM files, CICS transactions, and shop-specific conventions.

TN3270 is the terminal interface used to interact with many IBM mainframe systems. ISPF is the menu and panel system developers use inside that terminal to browse datasets, edit source, submit jobs, and inspect output. It is powerful and reliable, but it was designed for expert humans navigating screens, function keys, and fixed-width workflows, not AI agents.

A simple COBOL change might require finding the right source member, checking copybooks, locating compile JCL, submitting a job, reading JES/SYSPRINT output, interpreting condition codes, patching fixed-width source, and resubmitting.

Much of this work is so well-defined and repetitive that it's a good fit for agentic AI. To get that working, however, a chatbot next to a terminal is not enough. The agent needs to operate inside the mainframe environment.

Hopper combines three things: (1) A real TN3270 terminal, (2) Mainframe-aware panels for datasets, members, jobs, and spool output, and (3) An AI agent that can operate across those z/OS surfaces.

For example, here is a tiny version of the kind of thing Hopper can help debug:

  COBOL:

   IDENTIFICATION DIVISION.
   PROGRAM-ID. PAYCALC.

   DATA DIVISION.
   WORKING-STORAGE SECTION.
   01  CUSTOMER-BALANCE     PIC 9(7)V99.

   PROCEDURE DIVISION.
       ADD 100.00 TO CUSTOMER-BALNCE
       DISPLAY "UPDATED BALANCE: " CUSTOMER-BALANCE
       STOP RUN.


  JCL:

    //PAYCOMP  JOB (ACCT),'COMPILE',CLASS=A,MSGCLASS=X
    
    //COBOL    EXEC IGYWCL
    
    [//COBOL.SYSIN](https://cobol.sysin/) DD DSN=USER1.APP.COBOL(PAYCALC),DISP=SHR
    
    [//LKED.SYSLMOD](https://lked.syslmod/) DD DSN=USER1.APP.LOAD(PAYCALC),DISP=SHR

Hopper is not trying to hide the mainframe behind a generic abstraction, and it's not a chatbot. The design principle is simple: preserve the fidelity of the mainframe environment, but make it accessible to AI agents.

Sensitive operations require approval, and the terminal remains visible at all times.

Once agents can operate inside the mainframe environment, new workflows become possible: faster job debugging, automated documentation, safer code changes, test generation, migration planning, traffic replay, and modernization verification.

We’re curious to hear your thoughts! especially from anyone who has worked with mainframes, COBOL or has done legacy enterprise modernization.

I'm Ben Cochran, I spent 20+ years in the trenches with full-stack Engineering, DevOps, high performance computing & ML with stints at NVIDIA, AMD and various other organizations most recently as a Distinguished Engineer.

For agents to work reliably you either need massive parameter counts or massive context windows to keep the solution spaces workable. Most people are brute forcing reliability with bigger models and longer prompts.

What if I made the problem smaller instead of making the model bigger?

I took a different approach by using smaller models: models in the 13-20B parameter range and set them to task solving real SWE-bench problems. I constrained the tool and solution spaces using formal state machines. Each state in the machine defines which tools the model can access, how many iterations it gets and what transitions are valid. A planning state gets read-only tools. An implementation state gets edit tools (scoped to prevent mega edits) and write friendly bash tools. The testing state gets bash but only for testing commands. The model cannot physically skip steps or use the wrong tool at the wrong time. It is enforced via protocol, not via prompts.

The results were more promising than I would have expected. Across multiple model families irrespective of age (qwen-coder, gpt-oss, gemma4) and the improvements were consistent above the 13B parameter inflection point. Below that, models can navigate the state machine but can't retain enough context to produce accurate edits. More on the research bit: https://statewright.ai/research

Surprisingly this yielded improvements in frontier models as well. Haiku and Sonnet start to punch above their weight and Opus solves more reliably with fewer tokens and death spirals. Fine tuning did not yield these kinds of functional improvements for me. The takeaway it seems is that context window utilization matters more than raw context size - a tightly scoped working context at each step outperforms a model given carte blanche over everything. Constraining LLMs which are non-idempotent by using deterministic code is a pattern that nobody is currently talking about.

So, I built Statewright. Its core is a Rust engine that evaluates state machine definitions: states, transitions, guards and tool restrictions. Its orchestration doesn't use an LLM, just enforces the state machine. On top of that is a plugin layer that integrates with Claude Code (and soon Codex, Cursor and others) via MCP. When you activate a workflow, hooks enforce the guardrails per state automatically. The model sees 5 tools available instead of dozens, gets clear instructions for the current phase and transitions when conditions are met. Importantly it tells the model when it's attempting to do something that isn't in scope, incorrect or when it needs to try something else after getting stuck.

You can use your agent via MCP to build a state machine for you to solve a problem in your current context. The visual editor at statewright.ai lets you tweak these workflows in a graph view... You can clearly see the failure paths, the retry loops and the approval gates. State machines aren't DAGs; they loop and retry, which is what agentic work actually needs.

Statewright is currently live with a free tier, try it out in Claude Code by running the following:

/plugin marketplace add statewright/statewright

/plugin install statewright

/reload-plugins

Then "start the bugfix workflow" or /statewright start bugfix. You'll need to paste your API key when prompted. The latest versions of Claude may complain -- paste the API key again and say you really mean it, Claude is just being cautious here.

Feedback is welcome on the workflow editor, the plugin experience, and tell me what workflows you'd want to build first. Agents are suggestions, states are laws.

curl -o docker-compose.yml https://raw.githubusercontent.com/torrix-ai/install/main/doc... docker compose up

No external dependencies. All data stays in a local SQLite file on your machine.

It logs LLM calls through a HTTP proxy or a python/Node SDK : tokens, cost, latency, full prompt and response traces, reasoning token capture. Works with OpenAI, Anthropic, Gemini, Groq, Mistral, Azure Open AI and any Apen AI compatible end point.

Things I added as I actually used it on real agent pipelines: cost forecasting and hard budget caps, PII masking, model routing rules, evals with golden runs, AI judge, a prompt library with version history, run tags for filtering by environment, MCP server so AI Assistants can query your own logs and OTLP/HTTP ingestion for apps aöready using OpenTelemetry.

Community edition is free for one user with 7-day retention. Pro adds teams, RBAC, 30 day retention, API key management, full text search and audit logs.

SQLite doesn't scale to high write throughput. This is aimed at teams logging hundreds to low thousands of LLM calls per day, not millions. Happy to hear what people think and what is missing.

GitHub / install: https://github.com/torrix-ai/install Website: https://www.torrix.ai

The notion of story points was the first thing to go. Even Ron Jeffries, who invented them, regrets their usage. Mainline hard-codes a story size of 1 and tracks whether each story falls outside the team's normal distribution of time from start to release. After a few weeks the team has a real handle on their cadence, backed by data instead of planning-poker theatre. No estimation meetings required. Just do the work.

Unreleased work is made visible and tracked as inventory. There's a cottage industry of hosted feature-flag platforms selling a different idea to the original technique. Long-lived business-facing flags create waste in the form of unmanaged inventory left hanging around past its usefulness. Worst case, they become a giant configuration surface that "tech debt" doesn't do enough to capture as a term. Mainline tracks branch-by-abstraction, dark launches, feature flags, and old stories in flight through three phases: in progress, ageing, and stale.

The backlog is replaced with a Story Map. Work is shown as a user journey, and if it's not on the map (or has no user persona associated) it doesn't exist. This makes it harder for someone to dump tech tasks or random work onto the team for the purpose of "having a backlog."

The collaboration patterns high-performing teams use are first-class. Ensemble, pairing, and solo work are all visible and tracked, which makes de-siloing legible and promotes co-ownership.

I resisted adding AI features. It would be a weekend's work, and it would also undo the whole point. The longer argument is at mainline.dev/docs/ai.

I started building this with event sourcing and CQRS because I wanted the app built around an immutable event log. It wound up being too much boilerplate to change anything simple. So I went with an RDBMS and transactions to implement the immutable event log instead.

As I've learned after watching dozens of microservice teams utterly fail to safely ship anything, I took my own advice and started with a boring monolith and RDBMS. The stack itself is boring on purpose: Ruby with Roda and Sequel, Puma with YJIT, deployed via Kamal to Hetzner.

For teams who want to get better at CI, I built an integration with GitHub (GitLab coming) that reads the repo statuses and tracks how long a branch (if any are used) is open for. It's just a red/green dot on the repos as a heads-up.

The live demo is at mainline.dev/demo. No signup required, read-only because it's one shared team.

I'd be interested in feedback on how else I can help teams get better at CI and CD, and on any gripes you have with the parasitic management layer of non-practitioners who use other tools to implement Taylorist methods. Also, any other features that I haven't thought of (or thought of removing).

We saw larger tech companies like Ramp (Inspect) and Stripe (Minions) build this internally and thought an open source version should exist.

We made a few very intentional decisions when working on this:

1. Credentials are kept out of the sandbox. Authorized access goes through a proxy, so agents do not directly receive credentials.

2. The harness is not our problem. We're not going to tackle things like memory, self-learning.

3. No magic. Configurations are explicit. You can bring your own keys for models, sandboxes, and other providers. You can write your own instructions and agent.

Mistle can be run locally with a single command: https://github.com/mistlehq/mistle#run-mistle-locally

Questions, feedback and ideas are welcome!

I didn't want to learn Vim's window management, so I created a Vim file browser that can run in its own tmux pane.

The web app and remote boards are at: https://www.agentkanban.io

The VS Code extension is at VS Code Marketplace (https://marketplace.visualstudio.com/items?itemName=appsoftw...) or the Open VSX Registry (https://open-vsx.org/extension/appsoftwareltd/agent-kanban-v...).

The TLDR It's a collaborative Kanban board / task management app which supports hand off to Github CoPilot in VS Code, and captures the ongoing user / agent conversation context on the task for resumption in new chats (with context curation tools).

The context collection ignores tool use to prevent bloat in the captured context. AgentKanban also has features for improving agentic coding session quality such as an optional plan / todo / implement workflow and support for Git worktree creation and clean up for working on concurrent tasks.

The tool is an evolution of an earlier VS Code kanban extension (https://marketplace.visualstudio.com/items?itemName=AppSoftw...) I built which proved fairly popular but only catered for a local file based workflow.

The new version with the remote board improves the reliability of context capture, with lots of developer experience improvements. It's a tool that I use everyday in my own agentic coding workflows, and I can honestly say that it improves the quality of the code produced and reduces friction in organising working on concurrent features.

I hope you find it useful and would really appreciate your feedback on how you use it, what you think it does well, or any improvements you think could be added.

Many thanks for your time reading this

  Hashiverse (https://github.com/hashiverse/hashiverse) is an open-source decentralized social network protocol where Sybil
  resistance, rate limiting, peer reputation, and content moderation all fall out of one design choice: every action carries a
  proof-of-work cost calibrated to how much abuse it could cause. No central servers, no DNS dependency, no registration authority,
  no moderation team. Rust core, WASM browser client, volunteers on $5 VPS machines.

  Twitter-shaped (posts, follows, hashtags, timelines). The design problem that usually kills these projects on day one is Sybil
  resistance without a gatekeeper, so that is what I most want feedback on. Signatures and encryption are conventional (ed25519 +
  ML-DSA + FN-DSA, ChaCha20Poly1305, Blake3). The interesting surface is how every protocol action is priced in proof-of-work
  calibrated to its abuse potential.

  Shared primitive: a data-dependent chain over 17 hash algorithms. 5 rounds, each selecting one of 17 algorithms (Blake2s/b,
  SHA-2/3 at 256/384/512, Keccak-256/384/512, Groestl-256/512, Whirlpool, Skein-256/512, Blake3) and applying it 1 or 2 times. The
  algorithm index and repetition count for round N come from bytes of round N-1's output, so dispatch is data-dependent and only
  resolved at runtime.

  Honest prior art: Evan Duffield's X11 (Dash, 2014) chained 11 SHA-3 finalists with exactly this thesis. X11 ASICs (Baikal,
  iBeLink) shipped by 2016. Multi-hash chaining delays ASICs, it does not prevent them. What's different here is data-dependent
  dispatch (X11's pipeline is fixed) and variable repetition count. The honest question is not "is this ASIC-proof?" but "how much
  delay does data-dependent dispatch buy, and what software-update cadence should a protocol with no upgrade authority plan for?"

  Layer 1: Server-ID PoW (DHT membership). Generating a server identity means grinding a salt with the server's public keys through
   the chained hash until the derived 256-bit Kademlia ID has enough leading zero bits. Hours on commodity hardware per identity.
  Two compounding mitigations: bucket location IDs rotate on a monthly time epoch (the keyspace region around a user shifts
  deterministically), and prolific users fan across more buckets as the hierarchy subdivides under load. An attacker pays admission
   PoW against a moving target whose surface grows with the target's prolificness.

  Layer 2: RPC PoW. Every RPC carries a PoW over (timestamp, salt, payload, client ID, destination server ID). Under-threshold
  requests are rejected before payload parse. Timestamp pinning prevents replay; ID pinning prevents reuse across (client, server)
  pairs. Knock-on: because the destination server's ID is in the PoW, servers handling real load accumulate a routing-table
  reputation. A fresh Sybil has no traffic history; to affect the routing table they must either be useful or grind their own fake
  reputation by paying RPC PoW for every fabricated client request. Useful work becomes a Sybil deterrent.

  Post submission is a sub-case: two-phase Claim/Commit so one cheap PoW cannot deliver a huge payload. Submission difficulty
  scales with recent posting frequency.

  Layer 3: Per-feedback PoW. No central tally. Every signal (like, dislike, hate speech, spam, CSAM, etc.) is a PoW-stamped entry
  over (post_id, feedback_type), so a PoW cannot be reused across signals or posts. We use straightforward statistics to infer the
  total number of feedback submissions as the reciprocal of the unlikelihood of the globally-maximum PoW per (post_id,
  feedback_type) pair. That maximum is healed by clients noticing discrepancies, not by server-to-server gossip.

  If any of this resonates, or you spot something I've gotten wrong, I would love to hear it. PRs welcome.

  -- Jimme Jardine