今日已更新 156 条资讯 | 累计 20626 条内容
关于我们

标签:#opensource

找到 1368 篇相关文章

AI 资讯

Tracking token usage across OpenAI, Anthropic, and Gemini: every streaming gotcha I hit

OpenAI, Anthropic, and Gemini each report token usage differently, and it stops being trivia the moment you track LLM cost. I build Spanlens, an open-source LLM observability tool that sits in front of all three as a proxy and records every call with its model, latency, tokens, and cost. To do the cost part I read the token usage back out of every response, including the streaming ones. I assumed the three providers would report usage in roughly the same way. They send the same kind of data, after all: input tokens, output tokens, maybe a cached count. How different could it be. Pretty different, it turns out. Here is the whole thing in one table, then each gotcha in detail with the real parser code from the repo. Provider Where usage lives (streaming) Cache accounting Field names OpenAI final chunk, needs stream_options: { include_usage: true } prompt_tokens includes cache prompt_tokens / completion_tokens Anthropic split across message_start + message_delta input_tokens excludes cache, so add it input_tokens / output_tokens Gemini usageMetadata , two stream formats not applicable promptTokenCount / candidatesTokenCount Gotcha 1: the usage numbers live in different places in the stream For a non-streaming call this is boring. Every provider hands you a usage object on the response body and you read it. Streaming is where it gets weird, because the token counts are not in the content chunks. They show up somewhere else, and "somewhere else" is different for each provider. OpenAI puts the usage in a final chunk, after all the content, right before [DONE] . You only get it if you ask for it with stream_options: { include_usage: true } . Miss that flag and you stream the whole response and end up with no usage at all. export function parseOpenAIStreamChunk ( line : string ): Partial < ParsedUsage > | null { if ( ! line . startsWith ( ' data: ' )) return null const data = line . slice ( 6 ). trim () if ( data === ' [DONE] ' ) return null const json = JSON . parse ( data

2026-06-20 原文 →
AI 资讯

Hermes Agent Skills — Self-Evolving, Persona-Aware Skill Collection for Hermes Agent

Body: Hey everyone 👋 I've been building hermes-agent-skills — a production-grade skill collection for Hermes Agent that does three things no other skill pack does: 1. Self-Evolving Skills Skills aren't static YAML. The built-in EvolutionEngine tracks 5 health dimensions (usage frequency, success rate, user corrections, freshness, command validity), assigns a health score, and tells you which skills are rotting. Think of it as npm audit for your AI assistant's capabilities. 2. SOUL.md Persona Awareness Drop a SOUL.md in your Hermes config — naming conventions, comment density, architecture preferences, commit style — and every skill that touches code output adapts to it. hermes-skill soul generate bootstraps one in one command. The persona-aware-coding skill reads it at runtime so your agent writes code that actually looks like you wrote it. 3. CLI Toolchain hermes-skill create my-workflow # scaffold a standards-compliant SKILL.md hermes-skill validate skills/ # validate against the Agent Skills Standard hermes-skill list skills/ -f json # enumerate with health metadata hermes-skill soul generate # bootstrap a persona file What's in the box (v1.1.0): | Skill | Phase | Hermes-only Feature | |---|---|---| | requirement-analyzer | Define | Persistent memory across sessions | | spec-driven-dev | Spec | /skills chain forming workflows | | test-driven-dev | Build | delegate_task parallel test execution | | debugger-coordinator | Verify | browser + terminal + vision tri-tool | | code-quality-guardian | Review | patch auto-fix + /curator tracking | | cicd-orchestrator | Ship | cronjob scheduling + webhook triggers | | skill-curator | Evolve | Direct /curator integration | | persona-aware-coding | Identity | Native SOUL.md persona system | Why this is different: Most agent skill collections are portable but shallow — they can't use any platform's unique superpowers. These skills go deep on Hermes specifically: slash commands, delegate_task, persistent memory, vision+browser+t

2026-06-20 原文 →
AI 资讯

I Built an AI That Turns 2 Hours of Compliance Paperwork Into 3 Minutes — Full Architecture Teardown

Financial advisors have a dirty secret: they spend almost half their working hours not advising anyone. The culprit? Compliance documentation. After every client meeting, advisors must document what was discussed, what was recommended, whether those recommendations were suitable, and whether they followed FINRA and SEC rules — all in a format their CRM can ingest. A 45-minute meeting routinely generates 2 hours of paperwork. I built an open-source tool that does it in about 3 minutes. Here's exactly how — every architectural decision, every trade-off, and every line of code that matters. The Problem Is More Specific Than You Think When I started talking to advisory firms, I expected "meetings take too long" or "we need better CRM software." Instead, every compliance officer said the same thing: "We're not worried about the notes. We're worried about what's NOT in the notes." The real pain isn't documentation speed — it's the compliance gap. If a client says "I can't afford to lose this money" and the advisor recommends an aggressive growth fund, that's a FINRA 2111 suitability violation. But if the note-taker (usually the advisor, writing from memory hours later) forgets that quote? No record of the red flag. This changed my entire system design. It's not a transcription tool with formatting. It's a compliance engine that listens for mismatches. Architecture Four-stage pipeline: Audio → Transcription → Structured Extraction → Compliance Check → CRM Note (Whisper) (Claude via (Rule engine) (Formatter) OpenRouter) Stack: Python/FastAPI + React frontend + Whisper (local) + Claude via OpenRouter Two key design choices: Whisper runs locally. Advisory meetings contain PII and legally privileged information. Sending audio to third-party APIs isn't optional for most firms — it's a regulatory non-starter. Compliance engine is NOT an LLM. You can't have a probabilistic system making deterministic compliance judgments. The compliance check uses hardcoded rules against structur

2026-06-20 原文 →
AI 资讯

Why I scrub AI prose with regex, not a second LLM

Written by Stephanie Dover, Software Engineer 10+ YOE, ex GitHub, Twitch, Microsoft. Creator of Klaussy. LinkedIn · GitHub · Klaussy Desktop · Klaussy Agents TL;DR klaussy-agents is a free, MIT-licensed CLI ( pip install klaussy-agents ) that makes the prose an AI coding agent writes, PR comments, review notes, commit messages, read like a person wrote them. It works in two layers: a humanization spec baked into the agent's skills so it writes clean prose up front, and a deterministic klaussy humanize pass that scrubs the output afterward. The scrubber is rule-based regex, not an LLM, and it never touches code. There's also a part I didn't expect going in: once the AI tells are gone, what's left can read curt and run long, so the spec also handles tone (don't be rude) and length (one sentence for a reply, one to five for a review comment). Repo: github.com/steph-dove/klaussy-agents. The problem You can spot AI-written text now. Everyone can. And the place it grates most is a code review comment or a commit message, where the prose sits next to your name in a thread your teammates read. The tells are consistent. The em-dash is the biggest one. Right behind it: filler openers like "It's worth noting that…" and "I wanted to point out that…", chatbot scaffolding like "Hope this helps!" and "Let me know if you have questions!", and stacked hedges like could potentially . An agent that leaves those in your PR reads like a bot, and people notice. The obvious fix is to tell the model not to do it. Add "don't sound like AI" to the prompt and move on. That helps, inconsistently, and it regresses silently the moment you change the model or the prompt drifts. Editing every comment by hand works too, but hand-editing every comment defeats the point of having an agent write them. I wanted something I could trust without rereading. Why "just tell the model" wasn't enough The honest answer to "why not just prompt for it" is: a prompt asks, it doesn't enforce. The model tries to com

2026-06-20 原文 →
AI 资讯

Stop Wasting Tokens: I Built a File-Mapping Standard for AI-Assisted Development

Every time I started a new AI chat session, it read my entire codebase. 50 files. Thousands of tokens. On every single message. Whether I was asking about authentication, database schema, or a single UI component — the AI read everything. I'm 16 and building AI-powered products. Token costs add up fast. Context windows fill up. The AI loses track of older files. Responses slow down. So I built something to fix it. The Problem When you work with AI on large projects, you face a choice: Give the AI too much context → burns tokens, hits context limits, slower responses Give it too little → AI misses important files, makes wrong assumptions There's no middle ground — or at least there wasn't. Introducing FolioDux FolioDux is a lightweight, open-source file-mapping standard for AI-assisted development. The idea is simple: instead of giving your AI every file, you give it a compact index that tells it where everything is and what it does . The AI reads the index first, identifies the relevant files, and reads only those. One file. Two rules. Any AI. It works with Claude, ChatGPT, Gemini, Cursor, Copilot — any tool that accepts a system prompt. How It Works You add one file — FOLIODUX.md — to your project root. # FOLIODUX · TaskFlow · v1.0 · 2026-06-18 · 17 files STACK: React19+TypeScript+Vite · Express+SQLite · JWT --- ## TASKS auth/login/register → AuthView.tsx, authService.ts, server.ts create/edit task → TaskForm.tsx, taskService.ts, server.ts, types.ts list/filter tasks → TaskList.tsx, taskService.ts database → db.ts, server.ts --- ## INDEX App.tsx | fe | root: routing, auth state, layout wrapper AuthView.tsx | fe | login + register forms, error display taskService.ts | svc | CRUD tasks, local cache, optimistic updates server.ts | be | Express: all routes — auth, tasks, projects, user db.ts | be | SQLite setup, schema creation, migrations on boot types.ts | typ | Task, Project, User, Status(todo|in-progress|done) --- ## GROUPS Frontend: App.tsx · AuthView.tsx · TaskLi

2026-06-20 原文 →
AI 资讯

YINI Config Format Specification RC 6 released - clearer strings, stricter parsing, and growing tooling ecosystem

YINI Specification RC 6 is now released The YINI configuration format has reached Specification Release Candidate 6 . YINI is a configuration format designed to feel familiar if you like INI-style files, but designed to bring more explicit structure, clarity, useful data types, and predictable parsing rules to real-world configuration needs.. The short version: @yini ^ App name = "Example" version = "1.0.0" debug = false ^^ Server host = "127.0.0.1" port = 8080 ^^ Features enabled = [ "auth", "logging", "metrics", ] YINI tries to sit somewhere between classic INI, JSON, TOML, and YAML: More structured than traditional INI. Less punctuation-heavy than JSON. Indentation-insensitive unlike YAML. Explicit about parsing rules and validation behavior. RC 6 is an important release because it tightens several parts of the language and moves the format closer to a stable 1.0 specification. What changed in RC 6? RC 6 includes a number of syntax and behavior updates. The main theme is the same as before: Make the format clear for humans, but deterministic for parsers. Here are some of the notable updates. Clearer section markers YINI uses section markers to define structure. ^ App name = "MyApp" ^^ Server host = "localhost" ^^^ TLS enabled = true The number of section markers defines the nesting level. This keeps hierarchy visible without relying on indentation. The primary section marker is: ^ YINI also supports alternative section markers, but ^ remains the recommended default for most files and examples. Strict and lenient mode behavior is more clearly defined YINI has two parsing modes: Lenient mode — practical, forgiving, and intended as the default. Strict mode — validation-focused and intended for stricter tooling, CI checks, and production-sensitive configuration. A file can declare its intended mode: @yini strict or: @yini lenient RC 6 clarifies how these declarations should behave when the file is parsed in a different mode. The goal is to avoid silent surprises. If

2026-06-20 原文 →
AI 资讯

Building SyncCanvas: An AI-Powered Real-Time Collaborative Whiteboard

Modern collaboration needs more than documents and chat messages. Teams need a shared visual space where ideas can be created, organized, and refined together in real time. That's why I built SyncCanvas — an AI-powered collaborative whiteboard that combines real-time multiplayer collaboration, infinite canvas drawing, and AI-assisted brainstorming into one modern workspace. The Problem Most collaboration tools focus on only one aspect of teamwork. Some are great for drawing. Others are excellent for documentation. AI tools often live in separate windows, disconnected from the creative workflow. I wanted a platform where teams could brainstorm visually while AI actively helped generate and organize ideas directly on the canvas. Introducing SyncCanvas SyncCanvas is an infinite multiplayer whiteboard designed for students, developers, teams, and creators. Key features include: Real-time collaboration with live synchronization Infinite canvas with pan and zoom Drawing tools, shapes, text, and sticky notes AI-powered content generation using Gemini Private room sharing Guest mode access PNG export support WiFi Rooms for local collaboration Real-Time Collaboration Collaboration is at the heart of SyncCanvas. Using Yjs and WebSockets, multiple users can work on the same board simultaneously while seeing updates instantly. Users can: View live cursors Track online participants Join private rooms using secure room codes Collaborate anonymously through guest mode This creates a seamless experience similar to working together in the same room. Infinite Canvas Experience The whiteboard is designed to be limitless. Users can: Draw freehand sketches Create rectangles and circles Add text elements Organize ideas with sticky notes Move freely across an infinite workspace Export workspaces as images The canvas is powered by Fabric.js, providing smooth rendering and flexibility for future enhancements. AI-Powered Brainstorming One of the most exciting features is the integration of G

2026-06-20 原文 →
AI 资讯

I built a Chrome extension that catches every dark pattern trick on shopping sites. Here's exactly how.

A few months ago I was about to buy a flight. The page showed "Only 2 seats left at this price" in red letters. I hesitated, then refreshed the page out of curiosity. The counter said "Only 2 seats left" again. Same number. It had been resetting on every page load the whole time. That's when I started cataloguing every trick I'd seen on shopping sites and built a Chrome extension that flags them automatically, in real time, on any page. This isn't just my opinion — it's documented research In 2019, Princeton and University of Chicago researchers scraped 11,000 shopping sites and found dark patterns on more than 1,250 of them. The FTC has since fined several companies specifically for fake countdown timers and pre-checked subscription boxes. This isn't a grey area anymore — it's a known, studied, and increasingly regulated practice. The extension targets four categories that account for most of what's out there. The four patterns Fake urgency. Countdown timers that reset, "X people are viewing this" badges that never change, "only N left in stock" that's been static for a week. Trap checkboxes. A checkbox for "Yes, sign me up for the newsletter" that's pre-checked and styled to blend into the page so you don't notice it. Confirmshaming. The decline button reads "No thanks, I don't want to save money" instead of just "No thanks." Psychological pricing. Prices ending in .99 or .95 designed to register as a lower price bracket than they are. Why no AI this time My phishing detector used Claude because language and intent are genuinely ambiguous — you need a model that understands context. Dark patterns are different. They're structural. A countdown timer either resets on reload or it doesn't. A checkbox is either pre-checked or it isn't. That's a DOM query, not a judgment call. So this one runs entirely on regex and DOM inspection. No API calls, no latency, no cost per scan, works offline. Sometimes the boring solution is the correct one. Detecting the urgency pattern T

2026-06-20 原文 →
AI 资讯

I built an open-source market maker for prediction markets (Polymarket/CLOB) — here's how it works

Hey everyone, I've been deep in prediction market infrastructure for a while and just open-sourced a market maker bot designed for CLOB-based prediction markets like Polymarket. What it does: Quotes both sides of a binary market automatically Adjusts spreads based on order book depth and volatility Manages inventory risk to avoid getting stuck on the wrong side of a resolved market Built on top of Polymarket's CLOB API with Gnosis Safe / EOA wallet support on Polygon The core challenge with prediction markets vs. regular markets: Normal market making is about capturing spread. Prediction markets add a brutal edge case — resolution risk. If you're holding YES at 0.6 and the market resolves NO, you're not just down on the spread, you're down the full position. So the bot has to: Track time-to-resolution and widen spreads as resolution approaches Reduce inventory exposure on markets with high directional momentum Use FAK orders to avoid resting limit orders too long near resolution Stack: Rust Polymarket CLOB API Polygon (USDC settlement) SQLite for order state tracking What's next: Dynamic spread model based on implied volatility Multi-market portfolio rebalancing Better signal integration (news feeds, oracle data) GitHub: https://github.com/HarrierOnChain/Prediction-Markets-Trading-Bot-Toolkits Happy to answer questions on the architecture, risk model, or anything CLOB-related. Always looking for feedback from others building in this space.

2026-06-19 原文 →