techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

aws3 min readCurated summary

Introducing Anthropic’s Claude Opus 4.7 model in Amazon Bedrock | Amazon Web Services

Claude Opus 4.7 is now available in Amazon Bedrock as Anthropic’s most capable Opus model for coding, professional knowledge work, long-running agents, and visual tasks. It runs on Bedrock’s new inference engine, which dynamically schedules capacity, improves availability, queues requests during demand spikes, and provides zero operator access to prompts and responses. AWS positions the model as a production-ready upgrade to Opus 4.6, though teams may need to adjust prompts and agent harnesses. ## Model Improvements - **Agentic coding:** Stronger long-horizon autonomy, systems engineering, and complex code reasoning. - 64.3% on SWE-bench Pro - 87.6% on SWE-bench Verified - 69.4% on Terminal-Bench 2.0 - **Knowledge work:** Better document creation, financial analysis, and multi-step research. - Handles underspecified requests by making and explaining reasonable assumptions. - Self-verifies responses to improve first-pass quality. - 64.4% on Finance Agent v1.1. - **Long-running tasks:** Maintains coherence across its full 1-million-token context window while handling ambiguity and verifying results. - **Vision:** High-resolution image support improves analysis of charts, dense documents, and detailed screen interfaces. - **Adaptive thinking:** Dynamically allocates reasoning-token budgets based on request complexity. ## Bedrock Infrastructure and Scaling - The new inference engine uses updated scheduling and scaling logic to allocate capacity dynamically. - It prioritizes steady-state workloads while rapidly scaling capacity for changing demand. - During high demand, requests are queued instead of rejected. - Up to 10,000 requests per minute per account and Region are available immediately, with additional capacity available by request. - Zero operator access prevents AWS and Anthropic operators from viewing customer prompts and responses. ## Ways to Invoke the Model - Test Claude Opus 4.7 in the Amazon Bedrock console through **Playground**. - Use the Anthropic Messages API through: - Anthropic SDK integrations with Bedrock - `bedrock-mantle` endpoints - Use Bedrock-native APIs: - **Converse API** for multi-turn conversations and Guardrails integration - **Invoke API** for direct invocation and lower-level control - Invoke it with the AWS CLI using model ID `anthropic.claude-opus-4-7`. - The Anthropic Bedrock SDK can authenticate with AWS Signature Version 4 and submit Messages API requests programmatically. ## Availability - Initially available in: - US East (N. Virginia) - Asia Pacific (Tokyo) - Europe (Ireland) - Europe (Stockholm) - AWS directs users to the Bedrock model and pricing pages for regional availability updates. Teams seeking stronger coding agents, complex research workflows, or high-volume production inference can try Claude Opus 4.7 in Bedrock, while validating prompt and harness changes before migrating existing Opus 4.6 workloads.

Read original(opens in new tab)
PythonAmazon BedrockAPIAgentic Coding+4
cloudflare3 min readCurated summary

Cloudflare’s AI Platform: an inference layer designed for agents

Cloudflare is positioning AI Gateway as a unified inference layer for agentic applications. It provides one API for models from multiple providers, centralized cost and reliability controls, and low-latency access through Cloudflare’s global network. The platform is also expanding toward customer-hosted models and multimodal inference, reducing dependence on any single AI vendor. ### A Unified Model Catalog and Endpoint - Developers can call Cloudflare-hosted and third-party models through the same `env.AI.run()` interface. - Switching models, such as from Workers AI to Anthropic or OpenAI, requires only a one-line change. - Cloudflare plans to add REST API support for applications that do not run on Workers. - The catalog includes more than 70 models from over 12 providers, spanning: - Text and reasoning models - Image, video, and speech models - Open-source models hosted on Workers AI - Proprietary models from major providers - Users pay through one credit system rather than managing separate provider accounts. ### Centralized Cost and Usage Management - AI Gateway gives companies a consolidated view of spending across providers. - Request metadata can categorize costs by: - Team - User - Customer - Workflow - Free versus paid usage - This is particularly useful for agents, which may make many model calls for a single user request. ### Bringing Custom Models to Workers AI - Cloudflare is working on allowing customers to deploy fine-tuned or specialized models through Workers AI. - The deployment workflow uses Replicate’s Cog technology to package models and manage: - Python dependencies - CUDA requirements - Model weights - Runtime configuration - Developers define the environment in `cog.yaml` and implement model setup and inference in `predict.py`. - After building the Cog container, Cloudflare can deploy and serve it through existing Workers AI APIs. - Planned improvements include customer-facing APIs, Wrangler commands, and GPU snapshotting to reduce cold-start times. ### Optimizing Agent Responsiveness - For live agents, time to first token can matter more than total inference time. - A small reduction in startup latency can make an agent feel significantly more responsive, even if the full answer still takes several seconds. - Cloudflare’s presence in 330 cities places gateways close to users and inference endpoints, reducing network delay before streaming begins. - Workers AI is adding agent-focused open-source models, including Kimi K2.5 and real-time voice models. Cloudflare’s direction is to make model selection, deployment, monitoring, and failover easier through a single infrastructure layer. For teams building agents, the platform offers a way to mix providers and custom models while controlling cost, latency, and operational complexity.

Read original(opens in new tab)
CloudflarePythonApi IntegrationAi Gateway+4
cloudflare3 min readCurated summary

Building the foundation for running extra-large language models

Cloudflare is building infrastructure for serving extra-large open-source language models efficiently, especially for agentic applications with long prompts and frequent tool calls. Its approach combines specialized hardware configurations, prefill/decode disaggregation, prompt caching, distributed KV-cache management, and speculative decoding. These optimizations substantially improve latency, throughput, and cost efficiency without requiring more GPUs. ## Hardware Configurations for Agent Workloads - Different applications stress models differently: - Content generation sends fewer input tokens but produces many output tokens. - Summarization sends very large inputs and generates relatively short outputs. - Agent workloads typically involve: - Large system prompts - Tool and MCP definitions - Accumulated conversation history - Generated code and previous interactions - Workers AI therefore prioritizes fast input processing and tool-calling performance. ## Prefill-Decode Disaggregation - LLM inference has two stages: - **Prefill:** Processes input tokens and populates the KV cache; generally compute-bound. - **Decode:** Generates output tokens; generally memory-bound. - Running both stages on one server can underutilize GPUs because they stress different resources. - Cloudflare separates them across dedicated inference servers: - A prefill server processes the request and stores its KV cache. - A decode server retrieves the cache and generates the response. - This enables independent tuning, scaling for input- or output-heavy traffic, and use of heterogeneous hardware. - The architecture requires a sophisticated load balancer that: - Transfers KV-cache metadata between stages. - Rewrites streaming SSE responses. - Handles different inference-server protocols. - Balances traffic based on estimated in-flight prefill and decode tokens. - After adopting this design, Cloudflare saw: - Lower p90 time to first token and reduced tail-latency variance. - Intertoken latency fall from roughly 100 ms to 20–30 ms. - About a threefold improvement while using the same number of GPUs. ## Prompt Caching and Session Affinity - Long agent conversations repeatedly reuse the same context, making prompt caching essential. - The `x-session-affinity` header routes requests toward regions containing previously computed input tensors. - Cloudflare added support for this header to agent harnesses such as OpenCode. - Cached prompts improve: - Overall throughput - Interactive response times - Pricing, with discounted cached tokens - GPU efficiency - Adoption by heavy internal users increased peak input-token cache hit rates from 60% to 80%. ## Distributed KV-Cache Optimization - Larger models span multiple GPUs, requiring KV caches to be shared across devices and nodes. - For Kimi, Cloudflare uses Moonshot AI’s: - **Mooncake Transfer Engine** for high-speed memory transfers using RDMA technologies such as NVLink and NVMe over Fabric. - **Mooncake Store** to extend cache storage beyond GPU VRAM onto NVMe. - Combined with LMCache or SGLang HiCache, the system can: - Reuse cached prompts from any node in a cluster. - Reduce reliance on session-aware routing. - Balance traffic more evenly. - Keep sessions cached longer. - Increase cache hit rates and supported throughput. ## Speculative Decoding - The post begins introducing speculative decoding as another optimization. - It describes the basic LLM process of predicting successive tokens, but the provided text ends before explaining the technique or its results. Cloudflare’s overall strategy is to match infrastructure to real usage patterns rather than rely on a single hardware configuration. Separating inference stages, maximizing cache reuse, and distributing KV caches are practical ways to make large-model hosting faster and more economical.

Read original(opens in new tab)
Large Language ModelsCloudflareGpu OptimizationPrompt Caching+4
cloudflare3 min readCurated summary

AI Search: the search primitive for your agents

AI Search is presented as a general-purpose search primitive for AI agents, handling retrieval across code, support documentation, customer history, and agent memory. It combines semantic and keyword search while providing built-in storage, indexing, and dynamically creatable search instances. The result is less infrastructure to build and the ability to maintain separate searchable contexts for agents, customers, languages, or other tenants. ## Why Agents Need Search - Agents often need access to information too large or dynamic to fit in a context window. - Common examples include: - Coding agents searching millions of repository files. - Support agents searching product documentation and ticket history. - Memory systems retrieving relevant past interactions. - Building this independently requires: - A vector index. - Document parsing and chunking. - An indexing pipeline that stays synchronized with changing data. - A separate keyword index and result-fusion layer if lexical search is also needed. ## Hybrid Search - AI Search runs vector search and BM25 keyword search in parallel. - Results are fused into a single ranking. - This supports both: - Semantic matches based on meaning. - Exact-term matches for names, identifiers, and technical terminology. - The blog’s own search is powered by AI Search. ## Built-In Storage and Dynamic Namespaces - New AI Search instances include managed storage and a vector index. - Files can be uploaded directly through an API and indexed automatically. - Developers do not need to configure R2 buckets or external data sources for every instance. - The `ai_search_namespaces` binding allows Workers to create and delete instances at runtime. - Instances can be created per: - Agent. - Customer. - Language. - Other isolated contexts. - Documents can include metadata used to boost rankings at query time. - A single query can search across multiple instances. ## Customer Support Agent Example - The example uses the Cloudflare Agents SDK and Workers AI. - A shared `product-knowledge` instance contains product documentation backed by an R2 bucket. - Each customer receives a separate instance such as `customer-abc123`. - After an issue is resolved, the agent stores a summary of the problem and its fix. - Over time, each customer’s instance becomes a searchable history of previous resolutions. ## Agent Tools and Retrieval Flow - The support agent extends `AIChatAgent` and uses Kimi K2.5 through Workers AI. - It defines tools for: - Searching shared product documentation and the current customer’s history in one call. - Saving a resolution after an issue is resolved. - The model decides when to invoke these tools based on the conversation. - Search results can prioritize recent documents using metadata, such as a descending `timestamp` boost. - The Agents SDK persists the conversation history across reconnects, while AI Search provides retrieval over larger knowledge collections. AI Search is recommended for teams that want agent-ready retrieval without separately assembling vector databases, keyword indexes, storage, and synchronization pipelines. Its dynamically isolated instances are particularly useful for multi-tenant agents and applications that need both shared knowledge and private, continuously growing context.

Read original(opens in new tab)
Database DesignCloudflareVector DbAgents Sdk+4
cloudflare2 min readCurated summary

Deploy Postgres and MySQL databases with PlanetScale + Workers

Cloudflare and PlanetScale are integrating more closely so developers can create and manage PlanetScale Postgres and MySQL databases from the Cloudflare dashboard and API. The integration connects these databases to Workers through Hyperdrive, providing connection pooling, query caching, and simplified configuration. Cloudflare billing for new PlanetScale databases is planned for next month, while existing setups remain billed through PlanetScale. ## Postgres and MySQL for Workers - Developers can use either PlanetScale Postgres or Vitess-based MySQL for Worker applications. - Postgres supports a broad ecosystem of tools and extensions such as `pgvector` for AI-oriented vector search. - After connecting a PlanetScale account, users can create databases from the Cloudflare dashboard. - A Hyperdrive binding in `wrangler.jsonc` connects a Worker to the database: ```json { "hyperdrive": [ { "binding": "DATABASE", "id": "<AUTO_CREATED_ID>" } ] } ``` - Workers can then use standard clients such as the Node.js `pg` package and access the connection string through `env.DATABASE`. ## PlanetScale’s Developer Experience - Cloudflare selected PlanetScale for its performance, reliability, and support for both Postgres and MySQL. - PlanetScale features include: - Query insights - Usage and cost breakdowns - Database branching for safer schema and code changes - Agent-assisted SQL performance improvements - Cloudflare users receive the standard PlanetScale experience and pricing, including all available features. - PlanetScale Postgres starts at $5 per month for a single node. ## Reducing Latency with Workers Placement - Workers normally execute close to the incoming user request, which can increase latency when accessing a centralized database. - Developers can configure explicit placement so the Worker runs near the database’s primary region: ```json { "placement": { "region": "aws:us-east-1" } } ``` - Cloudflare plans to automatically determine placement based on the PlanetScale database location, potentially reducing database access latency to single-digit milliseconds. ## Billing and Availability - PlanetScale databases can already be created or connected through the Cloudflare dashboard. - Until the billing integration launches, databases continue to be billed through PlanetScale. - Starting next month, new databases can be billed directly to a Cloudflare self-serve or enterprise account. - Cloudflare credits, startup-program benefits, and committed spend may also apply toward PlanetScale database costs. The integration is intended to give Workers developers a unified platform for globally deployed applications, with flexible SQL storage, optimized database connectivity, and eventually centralized Cloudflare billing.

Read original(opens in new tab)
Database DesignCloudflarePostgreSQLMysql+3
cloudflare3 min readCurated summary

Artifacts: versioned storage that speaks Git

Artifacts is a distributed, versioned filesystem designed for AI agents and other high-volume compute environments. It creates repositories programmatically while remaining compatible with standard Git clients, enabling isolated repositories for agent sessions, sandboxes, and large numbers of forks. Cloudflare argues that Git’s familiar data model—commits, history, diffs, and branching—can serve as a general-purpose state-management primitive beyond traditional source control. ## A Git-Compatible Filesystem for Agents - Artifacts repositories can be created through the Workers API or REST API. - Applications receive a Git remote and authentication token, allowing agents to clone and use repositories with ordinary Git commands. - Repositories can be created dynamically for: - Individual agent sessions - Sandbox instances - Large-scale forked environments - Non-Git clients such as Workers, Lambda functions, and Node.js applications can use the API directly or language-specific SDKs. - Existing repositories can be imported from sources such as GitHub, then independently forked for isolated or read-only work. ## Why Git Fits Agent Workflows - Most AI coding agents already understand Git, including common workflows and edge cases. - Git’s object and commit model works well for storing: - Source code and configuration - Session prompts and agent history - Other large collections of small, versioned data - Git provides built-in capabilities for: - Tracking state over time - Reverting changes - Comparing versions - Forking from historical points - Using Git avoids requiring agents to learn a new protocol, CLI, or specialized tool. ## Beyond Source Control - Artifacts can persist an entire agent session’s filesystem and history without requiring dedicated block storage. - Cloudflare uses per-session repositories to: - Restore sandbox state - Share sessions with other people - Time-travel through both prompts and filesystem changes - Fork a session from any point for collaboration or debugging - The same semantics can support non-code data, such as customer-specific configuration that needs rollback, cloning, or diffing. - Cloudflare expects non-Git use cases to be as important as conventional repository workflows. ## Implementation on Cloudflare - Artifacts are built on Durable Objects, which provide isolated, stateful compute capable of supporting millions of repository instances. - The system uses an in-house Git implementation written in Zig and compiled to WebAssembly for Cloudflare Workers. - The implementation was designed to be: - Small - Broadly Git-compatible - Extensible for features such as notes and Git LFS - Efficient in a Workers environment Artifacts is currently available in private beta for paid Workers customers, with a public beta planned for early May. It is intended as a practical way to give agents and applications disposable, persistent, and fully versioned environments without abandoning the Git ecosystem.

Read original(opens in new tab)
Database DesignTypeScriptCloudflare WorkersGit+4
grammarly3 min readCurated summary

The Trust Practice: What Building Credibility Requires

Trust in education is not universal; it depends on stakeholders’ responsibilities and the risks they carry. Research across K–12 and higher education shows that AI systems earn trust when they provide clarity about safety, accountability, autonomy, and professional judgment. Effective AI governance must therefore be context-aware rather than based solely on general principles such as transparency or user control. ## K–12: Trust as Stewardship - Educators and administrators prioritize student safety, parental expectations, and institutional duty of care. - Their central question is whether a system will protect students and the institution when problems arise. - Trust grows through clear guardrails, oversight, data protections, and shared responsibility. - Ambiguity around accountability or student information can quickly undermine confidence. ## Higher Education: Trust as Autonomy and Credibility - Faculty and administrators focus on academic integrity, authorship, intellectual ownership, and professional expertise. - They ask whether AI supports or undermines their role as scholars and educators. - Trust is connected to autonomy and the legitimacy of learning itself. - A tool that feels safe in K–12 may feel threatening in higher education because the stakes and responsibilities differ. ## Why Context Matters for AI Adoption - Transparency, explainability, and user control are necessary but do not automatically create trust. - Systems must align with the actual responsibilities educators manage. - Poor alignment can lead to hesitation, stricter governance, and stalled adoption. - The same AI behavior may build trust in one setting while eroding it in another. ## What Educators Need - Educators consistently ask for clarity rather than generic reassurance: - What is the system doing? - Who is accountable when it fails? - How will it affect students, professional judgment, and authorship? - Do educators retain decision-making authority? - Institutional governance, communication, and even silence signal what an institution values and whom it trusts. - Leaders need partners who can acknowledge uncertainty and complexity instead of oversimplifying them. ## Building Trust Over Time - Trust develops through consistent behavior, honest risk management, and meaningful responses when things go wrong. - AI platforms serving multiple education sectors should be context-aware, role-sensitive, and explicit about responsibility. - Design, governance, and messaging that work in one environment may create friction in another. - Treating trust as a universal feature risks overlooking the people accountable for using the technology. AI in education should be designed around the distinct responsibilities of educators and institutions. Trust is not something that can be built once and shipped; it must be earned through clear accountability, contextual design, and sustained partnership.

Read original(opens in new tab)
Data PrivacyAi GovernanceSystem DesignEducation Technology+3
cloudflare3 min readCurated summary

Cloudflare Email Service: now in public beta. Ready for your agents

Cloudflare Email Service is entering public beta as infrastructure for applications and AI agents that use email as a primary interface. It combines inbound Email Routing with outbound Email Sending, allowing agents to receive messages, perform asynchronous work, and reply without relying on separate email providers. Cloudflare argues this enables agents to move beyond instant chatbot responses and operate independently across support, billing, verification, and multi-agent workflows. ## Email as an Agent Interface - Email is universally available and requires no custom chat application or channel-specific SDK. - Developers already depend on email for: - Account signups - Notifications - Invoices - Customer support - Verification workflows - Agents increasingly need email to communicate with users and other systems. ## Cloudflare Email Service - **Email Routing** lets applications and agents receive email. - **Email Sending** enables replies and outbound notifications. - The service integrates with Workers and the Agents SDK. - The public-beta toolkit includes: - An Email Sending binding - An Email MCP server - Wrangler CLI email commands - Skills for coding agents - An open-source agentic inbox reference application ## Email Sending in Public Beta - Workers can send transactional email through a native `env.EMAIL` binding. - The binding requires no API keys or secret management inside the Worker. - Applications can also send email through a REST API or TypeScript, Python, and Go SDKs. - Cloudflare automatically configures SPF, DKIM, and DMARC when a domain is added, improving authentication and inbox delivery. - Since the service runs on Cloudflare’s global network, it is designed for low-latency delivery worldwide. - Combined with long-standing Email Routing, developers can receive, process, and send email within one platform. ## Email-Native Agents with the Agents SDK - The Agents SDK already provides an `onEmail` hook for processing inbound messages. - Previously, agents were limited to synchronous replies or messages sent to Cloudflare account members. - Email Sending removes those limitations, allowing agents to: - Process requests for extended periods - Query multiple systems - Schedule follow-ups - Escalate unusual cases - Reply asynchronously after completing work - This turns an agent from a simple chatbot into a system capable of acting independently. ## Support-Agent Workflow - The example `SupportAgent`: - Receives email through `routeAgentEmail` - Parses the raw message with `PostalMime` - Stores ticket details such as sender, subject, body, and message ID in agent state - Starts longer-running work or sends a task to a Queue - Replies using the Email Sending binding - Preserves the conversation with `inReplyTo` and a `Re:` subject - Address-based routing maps addresses such as `support@domain` or `sales@domain` to corresponding agent instances. Cloudflare’s recommendation is to use Email Service when an agent must communicate reliably with people over email, especially for workflows that require persistence, background processing, and delayed or follow-up responses.

Read original(opens in new tab)
TypeScriptPythonGoRest Api+4
gitlab2 min readCurated summary

CI Expert and Data Analyst AI agents target development gaps

GitLab 18.11 introduces two Duo Agent Platform agents aimed at development gaps left by faster AI-generated coding. CI Expert Agent helps teams create working pipelines, while Data Analyst Agent answers software delivery questions using GitLab data. Both benefit from being embedded in GitLab, where they can use current repository, pipeline, issue, and merge request context. ## CI Expert Agent: Faster Pipeline Setup - Now available in beta. - Inspects a repository to identify its language, framework, and testing setup. - Generates runnable build and test configurations without requiring developers to write YAML manually. - Explains each pipeline step in plain language through Agentic Chat. - Uses native GitLab CI semantics. - Addresses the common problem of delaying CI because `.gitlab-ci.yml` is difficult to create or validate. - Helps reduce regressions, oversized changes, and dependence on undocumented team knowledge. - Available on GitLab.com, Self-Managed, and Dedicated across Free, Premium, and Ultimate editions with Duo Agent Platform enabled. ## Data Analyst Agent: Natural-Language SDLC Queries - Generally available in GitLab 18.11. - Lets users ask questions about development performance in plain language and receive visualizations in Agentic Chat. - Covers merge requests, issues, projects, pipelines, and jobs. - Supports questions about: - MR cycle time and review bottlenecks - Project throughput and contribution patterns - Flaky tests and pipeline performance - Runner utilization and deployment frequency - Cross-portfolio lead times and project health - Eliminates the need to learn GitLab Query Language, request custom dashboards, or rely on separate analytics tools. - Generated GLQL queries can be copied into GitLab Flavored Markdown. - Exporting results to work items and dashboards is planned. - Available across GitLab.com, Self-Managed, and Dedicated Free, Premium, and Ultimate editions with Duo Agent Platform enabled. ## The Advantage of Platform-Native Context - Both agents operate within GitLab and can access existing code, pipelines, issues, and merge requests. - Their recommendations and answers are based on current operational data rather than generic examples or disconnected tools. - The agents are designed to support the full lifecycle: understanding code, configuring CI, shipping changes, and evaluating delivery performance. Together, these agents make GitLab Duo more useful beyond code generation. Teams should consider trying CI Expert Agent for faster initial pipeline setup and Data Analyst Agent for immediate, self-service insight into delivery performance.

Read original(opens in new tab)
Machine LearningGitlabDevOpsYaml+4
discord2 min readCurated summary

Making Discord on Desktop Look Just Right: Display Settings to Ease the Eyes

Discord’s desktop app offers several display and accessibility settings to make conversations more comfortable and easier to read. Users can control when media and spoilers appear, reduce interface color intensity, simplify names and role colors, manage HDR brightness, and adjust UI density and text size. These options let people tailor Discord to their visual preferences without changing how content appears to others. ## Chat Options for Customizing Conversations - In **User Settings > Display > Messages**, users can control whether images and videos appear automatically. - Media can be shown or manually opened when: - Posted as direct links - Uploaded directly to Discord - **Show embeds and link previews** can be disabled to prevent automatic previews for web links. - Alt text can be displayed by default when image descriptions are provided. - Spoiler content can be configured to appear: - **On click** - **Always** - **On servers I moderate** - Links can always be underlined, improving visibility—especially when interface saturation is reduced. ## Toning Down Discord’s Colors - The **Saturation** setting reduces the intensity of interface colors, including buttons, status indicators, and links. - Saturation can also be applied to custom colors such as server role colors. - User-created media—including avatars, custom emoji, photos, and videos—is not affected. - Role colors can be displayed as a dot beside a user’s name instead of coloring the entire name. ## Reducing Brightness and Visual Distractions - HDR-capable displays may show extremely bright images and videos. - In **Accessibility > High Dynamic Range**, users can switch from **Full Dynamic Range** to **Standard Range** to reduce HDR intensity. - Nitro display-name styling can be disabled through **Accessibility > Text Readability > Display Name Styles**. - Disabling these styles restores standard fonts and colors without notifying other users. ## Adjusting UI Density and Text Size - Discord also provides settings to make the interface more or less dense, depending on whether users prefer more information on screen or greater spacing. - The article introduces additional controls for changing the size and spacing of interface content, though the provided text ends before describing them in detail. Overall, Discord’s display settings can be combined to reduce visual overload: hide media until needed, lower saturation, soften HDR content, simplify names, and adjust spacing or text size for a more comfortable setup.

Read original(opens in new tab)
DiscordUser InterfaceAccessibilityResponsive Design+2
toss5 min readCurated summary

Extending Real-time Ad Frequency Capping Aggregation to One Week with Apache Flink + RocksDB Tuning

The post describes Toss’s expansion of real-time advertising frequency-capping from short Flink windows to periods of up to seven days. The new system provides accurate sliding counts from one minute to seven days through a single Redis lookup, while treating Flink state as the authoritative source and Redis as its projection. The migration addressed architectural complexity, backfill consistency, and distinct RocksDB bottlenecks across three specialized Flink applications. ## Frequency Capping and Its Business Impact - Frequency capping controls how many times an individual user sees an advertisement. - Incorrect counts can: - Waste an advertiser’s budget through excessive exposure. - Prevent valid impressions when the system believes a limit has already been reached. - Different products require different windows, such as: - Three impressions per day. - One impression over the previous seven days. - The target system therefore needed accurate, real-time sliding counts from one minute through seven days. ## Limitations of the Previous Batch-Oriented System The original architecture combined three Airflow-managed layers: - **Head** - Stored current-day and previous-day events in Redis through a Spring Kafka consumer. - Updated counts immediately per event. - **Mid** - Used daily Spark jobs to pre-aggregate data from D-2 through D-7. - **Tail** - Added hourly correction data around the boundary between Head and Mid. - Airflow workflows ran approximately 75 times per day. At serving time, the API could perform up to four Redis lookups and combine the results. - This structure was difficult to maintain because of the dependencies and boundary conditions between Head, Mid, and Tail. - Time-based truncation made precise event-level sliding windows difficult. - The architecture remains useful for longer windows such as 30 days and fixed daily aggregates, especially when data exceeds Kafka retention and must be recovered from batch storage. - Extending the existing short-window Flink system was chosen to simplify serving and reduce DAG complexity. ## Three Flink Applications Rather than place all windows in one Flink job, the team split processing into three applications with shared code but independent RocksDB configurations: - **Minutes** - Handles one- to 30-minute windows. - Frequent event expiration creates heavy write traffic. - Its main concern is RocksDB Write Buffer Manager pressure and resulting Write Stalls. - **Hours** - Handles windows up to 12 hours. - Maintains many more advertisement IDs in state. - Filter Block Cache misses can saturate CPU. - Redis synchronization requires an O(N) scan over advertisement IDs in each window. - Filter Block tuning and additional managed memory are important. - **Days** - Handles the largest state volume. - A seven-day window can produce approximately 68 GB of live SST files and 220–230 GB savepoints. - Checkpoint I/O becomes the primary bottleneck, motivating a Flink Changelog design. Separating the applications allowed each workload’s RocksDB and runtime bottlenecks to be optimized independently without affecting the others. ## Backfill and Catch-up Architecture The most difficult migration problem was maintaining correctness at the transition point between historical data and live processing. - **Backfill** - Loads seven days of historical events. - Only increments counts. - Does not register expiration timers. - Synchronizes the initialized values to Redis once and then finishes. - **Catch-up** - Re-reads historical events from Kafka. - Rebuilds both counts and expiration timers. - Begins writing to Redis after reaching the historical scan end. - Enables each window only after sufficient lookback data has been reconstructed. The two phases cannot safely share one pipeline: - Backfill must only add historical counts. - Live or catch-up processing must both add new events and subtract events that leave the sliding window. - If expiration timers ran while backfill was incomplete, decrements could occur before all historical increments had been applied, producing incorrect results. - Flink batch mode was rejected because state is discarded when the job finishes. - A Spark and Hive-based approach was also rejected because it would introduce additional systems and complicate the single-source-of-truth model. Separate Kafka consumer groups were required so that backfill offsets would not cause catch-up events to be skipped. ## State as the Single Source of Truth - Flink state stores the authoritative aggregate. - Redis is treated only as a serving projection. - If Redis becomes inconsistent, it can be reconstructed from Flink state. - This design preserves correctness during failures, restarts, and Redis resynchronization. ## Maintaining Transition Consistency Three mechanisms were combined to make the backfill-to-catch-up boundary reliable: - **Redis write condition** - Writes are based on each event’s `eventTime` being after the backfill completion point. - Using the global watermark directly could block all writes because one slow or idle partition can hold back the watermark. - **`withIdleness` set to 60 seconds** - Excludes inactive Kafka partitions from watermark progression. - A longer timeout avoids falsely marking a partition idle just before a bounded source emits `MAX_WATERMARK`. - **Timer state TTL** - Must exceed the sliding-window expiration period. - If the timer fires after its associated state has expired, `timerState.get()` returns null and the decrement is skipped. - This would leave counts artificially high after delays or recovery. - The state is manually cleaned up after timer processing. ## RocksDB and Flink Runtime Tuning Once the system was serving real-time results, operational metrics exposed different bottlenecks in each application. - The minutes application initially experienced RocksDB Write Stalls caused by pressure on the shared Write Buffer Manager. - RocksDB first stores writes in MemTables and flushes them into SST files organized across levels L0–L6. - Flink maps managed state types such as `MapState` and `ValueState` to separate RocksDB Column Families. - Because multiple Column Families share the Write Buffer Manager’s memory budget, write-heavy workloads require careful tuning of RocksDB memory and write paths. - The hours and days applications require different optimizations focused on cache misses, CPU usage, checkpoint I/O, and level management. ## Practical Conclusion For real-time frequency capping, a unified Flink-based design can simplify serving and improve sliding-window accuracy, but long windows should not automatically be combined with short ones in a single job. Separate applications, state-as-SSOT, distinct backfill and catch-up pipelines, and workload-specific RocksDB tuning are essential for maintaining correctness and operability at scale.

Read original(opens in new tab)
Database DesignRedisApache FlinkAirflow+3
google3 min readCurated summary

AI-generated synthetic neurons speed up brain mapping

Google Research developed MoGen, an AI model that generates realistic synthetic neuron geometries to improve brain-mapping systems. Adding these synthetic examples to PATHFINDER reduced neuron reconstruction errors by 4.4%, primarily by preventing incorrect merges. At the scale of a complete mouse brain, the improvement could eliminate an estimated 157 person-years of manual proofreading. ## Connectomics and the Reconstruction Challenge - Connectomics creates brain wiring maps by imaging thin tissue slices, aligning them, and reconstructing 3D neurons. - AI assists with segmentation and reconstruction, but human experts must still correct errors. - Larger brains pose major scaling challenges: the fruit fly map contains about 166,000 neurons, while a mouse brain is roughly 1,000 times larger. ## Why Neuron Shape Matters - Neurons have complex structures, including long axons, branching dendrites, dendritic spines, and synapses. - PATHFINDER identifies neurite segments and combines them into complete neurons. - Poor or ambiguous microscopy data can cause: - **Split errors:** connected neurites are separated. - **Merge errors:** unrelated neurites are incorrectly joined. - Correcting these mistakes manually is one of the most time-consuming parts of brain mapping. ## MoGen’s Synthetic Neurons - MoGen uses point-cloud flow matching to transform random 3D point clouds into realistic neuronal shapes. - It was trained on surface samples from 1,795 human-verified mouse axons. - Experts could not reliably distinguish MoGen-generated neurite fragments from real ones. - The synthetic data reproduced features such as bending, twisting, thickening, and branching. ## Results with PATHFINDER - Training PATHFINDER with 10% MoGen-generated data reduced reconstruction errors by 4.4%. - The largest gains came from reducing merge errors. - Millions of synthetic neuron shapes were added to the training pipeline. - Although the percentage improvement is modest, it could save the equivalent of 157 years of expert proofreading for a full mouse-brain map. ## Future Applications - MoGen could be tuned to generate neuron types with specific lengths, branching patterns, or spatial ranges. - Future versions may focus on geometries that are particularly likely to cause reconstruction errors. - Google has also trained species-specific models for zebra finches and fruit flies. - The team is exploring synthetic electron-microscopy images to improve earlier stages of reconstruction. - MoGen and its species-specific models have been released as open source. Synthetic neuron generation is a practical way to expand training data without requiring additional manual annotation. Combined with targeted generation and synthetic microscopy, it could help make large-scale projects such as complete mouse-brain mapping more feasible.

Read original(opens in new tab)
AISynthetic DataNeural NetworksConnectomics+4
gitlab2 min readCurated summary

Automate remediation with ready-to-merge AI code fixes

GitLab 18.11 makes Agentic SAST Vulnerability Resolution generally available, using AI to analyze vulnerabilities, generate code fixes, test them, and open ready-to-merge merge requests. The release aims to reduce developer context switching and AppSec triage while addressing vulnerabilities before production. It also adds faster scanning, risk-based prioritization, and stronger security governance. ## Automated Remediation in the Developer Workflow - Confirmed SAST true positives automatically enter GitLab Duo Agent Platform’s remediation flow. - The agent: - Analyzes the vulnerability in context. - Generates a root-cause fix. - Validates the change with automated tests. - Developers receive a ready-to-merge MR with a confidence score. - Incremental scanning for Advanced SAST provides results before a complete scan finishes. - The approach addresses the growing remediation burden as AI-generated code increases vulnerability volume. ## Prioritizing Vulnerabilities by Business Risk - Vulnerability scoring now uses CVSS 4.0 for more detailed exploitability assessment. - Policy-based severity overrides can use: - CVE information. - CWE classifications. - File paths and directories. - Approval policies can block or warn on merges based on: - Known Exploited Vulnerabilities (KEV). - EPSS score thresholds. - The Top CWEs dashboard chart helps teams identify recurring vulnerability classes and address systemic causes. ## Security Controls and Scanner Coverage - The new Security Manager role gives security teams permissions to: - Enforce scanners. - Configure security policies. - Manage triage and remediation. - Maintain compliance frameworks and audit streams. - The role excludes code modification and deployment permissions, keeping access appropriately scoped. - SAST configuration profiles allow teams to define scanning centrally and apply it across group projects without maintaining project-level YAML or relying on developers for configuration. GitLab 18.11 combines agentic remediation, faster and more risk-aware scanning, and centralized governance. Organizations seeking to reduce vulnerability backlogs can use these capabilities to automate routine fixes while preserving developer oversight through merge requests and confidence scores.

Read original(opens in new tab)
Machine LearningDevSecOpsSastSecurity+3
google4 min readCurated summary

Designing synthetic datasets for the real world: Mechanism design and reasoning from first principles

Synthetic data generation should be treated as dataset-level mechanism design rather than one-sample-at-a-time prompting. Google’s Simula framework uses reasoning models to control coverage, diversity, complexity, and quality independently, enabling seedless, reproducible datasets for scarce or privacy-sensitive domains. Experiments across five domains show that thoughtfully designed data can outperform larger datasets, but the best configuration depends on the target task and model. ## Why Real-World Data Is Insufficient - Specialized AI applications often lack accessible data because domains are uncommon, expensive to label, or privacy-sensitive. - Manually creating datasets is costly, slow, and error-prone. - Real-world datasets are static, limiting rapid iteration and making it difficult to proactively generate safety edge cases. - Synthetic-first workflows can make data programmable, versioned, reproducible, and inspectable. ## Limitations of Existing Synthetic Data Methods - Many approaches depend on manual prompts, evolutionary algorithms, or large amounts of seed data. - These dependencies reduce scalability and explainability. - Generation parameters are often entangled, making it difficult to independently control diversity, difficulty, and correctness. - Most methods optimize individual samples instead of designing the dataset’s overall distribution. ## Simula’s Reasoning-First Design - Simula constructs datasets from first principles using reasoning models rather than opaque generation processes. - The framework is seedless and agentic, allowing improvements as the underlying models become better at reasoning. - It separates generation into independently controllable axes. ### Global Diversification - Reasoning models map a domain into deep, hierarchical taxonomies that serve as sampling scaffolds. - A recursive propose-and-refine process generates candidate categories, then evaluates, merges, and filters them with a critic model. - These taxonomies help datasets cover long-tail concepts instead of concentrating on common examples. - The approach was demonstrated with structures such as a Cyber Threat Intelligence taxonomy. ### Local Diversification - Taxonomy nodes are converted into “meta-prompts” representing scenarios. - Multiple distinct instantiations are generated for each scenario. - This reduces mode collapse—for example, representing SQL injection through varied contexts rather than repeating nearly identical questions. ### Complexification - A configurable portion of scenarios is made more elaborate or difficult. - Complexity can therefore be adjusted without changing the dataset’s semantic coverage. - The appropriate difficulty level depends on the capabilities of the model that will consume the data. ### Quality Checks - A dual-critic loop independently assesses whether outputs and answers are correct. - Independent verification helps reduce sycophancy and improves label reliability. - This enables quality control without requiring human review of every example. ## Reasoning-Based Evaluation - Conventional metrics such as embedding cosine distance offer only broad signals and limited practical guidance. - Simula introduces: - **Taxonomic Coverage**, which measures how thoroughly the conceptual space is represented. - **Calibrated Complexity Scoring**, which uses LLM-based batch comparisons and chess-style Elo ratings to estimate the difficulty of individual examples. - These metrics aim to evaluate diversity and difficulty in ways that better reflect downstream usefulness. ## Results Across Domains - Simula was evaluated using Gemini 2.5 Flash as a teacher and Gemma 3 4B as a student. - The experiments covered cybersecurity, legal reasoning, grade-school mathematics, and multilingual academic knowledge, with datasets reaching 512,000 examples per domain. - The full combination of global coverage, local diversity, and quality critique consistently outperformed simpler baselines. - High complexity improved math reasoning accuracy by 10% in GSM8k but harmed legal reasoning performance, where the teacher model was weaker. - Simula often achieved stronger downstream results with fewer examples, suggesting that data properties matter as much as volume. - The findings show that there is no universally optimal synthetic-data recipe; effective dataset design must be tailored to the domain and target model. Synthetic data is most effective when treated as an engineered system rather than a source of additional volume. Practitioners should separately tune coverage, variation, difficulty, and verification, then validate those choices against the downstream task.

Read original(opens in new tab)
PostgreSQLSynthetic DataData GenerationMechanism Design+4
gitlab2 min readCurated summary

Claude Opus 4.7 is now available in GitLab Duo Agent Platform

GitLab Duo Agent Platform now supports Anthropic’s Claude Opus 4.7 across Agentic Chat and agent-powered software delivery workflows. The model is designed to improve long-running, multistep tasks through stronger reasoning, instruction following, and self-verification. GitLab says this should make agents more reliable across development, security, CI/CD, and deployment. ## Improved Reasoning and Instruction Following - Internal evaluations reportedly show Opus 4.7 outperforming Sonnet 4.6 and Opus 4.6. - It handles complex, conditional instructions more precisely. - Agents can complete multistep tasks with fewer errors and more predictable, auditable results. - Self-verification helps agents check generated code and tests before presenting them. ## Support Across the Software Lifecycle - **Development:** Faster code generation and test creation with less developer back-and-forth. - **Security:** More reliable vulnerability remediation through complete, correctly scoped sequences. - **CI/CD:** Better continuity when investigating pipeline failures, analyzing logs, and proposing fixes. - **Cross-stage workflows:** The model supports coordination across planning, coding, security, and deployment. ## Availability and Pricing - Claude Opus 4.7 is available now through model selection in GitLab Duo Agent Platform. - Model credit consumption details are provided in GitLab’s documentation. - New users can start a free trial. - GitLab Premium and Ultimate subscribers can enable Duo Agent Platform and use included GitLab Credits. Teams using GitLab’s agent workflows can adopt Opus 4.7 to improve reliability on complex, multi-tool tasks spanning the full software delivery lifecycle.

Read original(opens in new tab)
Machine LearningCI/CDGitlabCode Review+3