Google 推出 AI Ultra 订阅，提升 Gemini 与 Gmail 效率

Google 在 2026 年 I/O 会议上公布了 AI 订阅新方案。新增两档 Ultra 级别：
- $100/月：Gemini 与 Antigravity 使用量提升 5 倍，含 20TB 存储、YouTube Premium、优先 Antigravity 访问。
- $200/月：使用量提升 20 倍，包含同样福利，并可全球使用 Project Genie。

两档均支持 Gemini Spark（美国先行）和 Gemini Omni、Gemini 3.5 Flash 等模型。
新增功能：
- AI Inbox（Gmail）— 先在美国开放，后续将推至 Plus、Pro。
- Daily Brief（Gemini）— 生成基于 Gmail、Calendar 与 Gemini 对话的晨报，初期仅限美国。
- 语音功能即将加入 Gmail、Docs、Keep。

计费方式改为按 计算量 而非每日提示数，刷新周期为 5 小时；达到上限时自动降级至小模型。
Google 亦提供 按需 AI 信用 充值，支持 Antigravity 与 Flow，Gemini 版即将上线。

适用场景
- 需要高 Gemini/Antigravity 额度的开发者或创作者。
- 依赖 Gmail/Calendar 进行任务梳理的团队。
- 想通过 AI 自动化提升工作效率的企业。

详细功能与地区可用性请参阅 Google 官方 AI 订阅概览。

#开发者 #工具 #GoogleAI #Gemini #Gmail #AIInbox #DailyBrief #UltraTier
@DevToolboxHub

Cypress 与 Grafana Cloud 监控集成

Cypress 通过插件钩子可在每个 spec 完成后获取测试结果。将这些结果转为 Prometheus 格式后，推送到 Pushgateway；Alloy 定时抓取 Pushgateway 并远程写入 Grafana Cloud Metrics。这样即可在 Grafana 中查看每个 spec 的通过/失败计数、耗时、单个测试的稳定性，并可设置告警。

关键步骤

- 在 cypress.config.js 的 setupNodeEvents 中使用 before:run 记录一次 run_id，after:spec 生成并推送指标。
- 生成的指标包括 cypress_tests_total、cypress_spec_duration_seconds、cypress_test_success 等，统一使用 spec、run_id、ci_run_id 三个标签。
- 推送通过 PROMETHEUS_PUSHGATEWAY_URL 环境变量配置；若未设置则跳过。
- 在 CI（如 GitHub Actions）中同样设置 PROMETHEUS_PUSHGATEWAY_URL，Cypress 自动使用 GITHUB_RUN_ID 作为 ci_run_id。
- Alloy 配置文件 config.alloy 设定抓取 Pushgateway 并写入 Grafana Cloud，凭证通过 GRAFANA_CLOUD_RW_URL、GRAFANA_CLOUD_USER、GRAFANA_CLOUD_TOKEN 提供。

部署示例

```bash

# 1. Pushgateway
docker run -d -p 9091:9091 prom/pushgateway

# 2. Alloy
export GRAFANA_CLOUD_RW_URL=
export GRAFANA_CLOUD_USER=YOUR_USER_ID
export GRAFANA_CLOUD_TOKEN=YOUR_TOKEN
alloy run config.alloy

# 3. Cypress
PROMETHEUS_PUSHGATEWAY_URL= npm run test:prometheus
```

在 Grafana 中即可创建面板，监控测试通过率、耗时趋势，甚至设置告警触发。

资源链接

GitHub: GitHub

#开发者 #工具 #Cypress #GrafanaCloud #Prometheus #Alloy #CI_CD #Nodejs #WebTesting
@DevToolboxHub

Claude Code 设置文件作用域揭秘

在项目目录下的 .claude/settings.json 中添加 autoMode 等键时，发现无效。原因是 Claude Code 的配置键有作用域限制，只有在对应作用域文件中才生效。
- ~/.claude/settings.json：用户作用域
- settings.local.json：本地作用域
- ~/.claude.json：全局作用域

例如 autoMode 只能在用户或本地作用域中使用，放在 settings.json（共享文件）会被忽略。
同理，useAutoModeDuringPlan、syncClaudeAiSkills、skipDangerousModePermissionPrompt 等键也只在 settings.local.json 有效。

如何正确配置
1. 将需要的键放入对应作用域文件。
2. 若想团队共享，先在 settings.local.json 验证无误，再迁移到 ~/.claude/settings.json。
3. 使用 npx @quintetkit/ccheck 检查键是否在正确作用域。

实用工具
- quartet：将 Claude Code 拆分为 Architect、Coder、Reviewer、Conflict Resolver 等角色，MIT 许可。
- mdlinkcheck：基于同一工作流构建的链接检查工具。

资源
GitHub
GitHub

#开发者 #工具 #ClaudeCode #设置作用域 #quartet #mdlinkcheck
@DevToolboxHub

Cloudflare Workers 搭配 Hono + Supabase 实现无服务器 API

Cloudflare Workers 让你在 24/7 运行的无服务器环境中，轻松托管 API。
使用 npm create cloudflare@latest 创建项目后，直接在 Typescript/JavaScript 中编写 Hono 路由，调用 supabase-js 访问数据库。
Wrangler CLI 支持手动部署（npx wrangler deploy）或 GitHub 自动化部署，日志与可观测性已内置，无需额外 Jaeger/Prometheus。
Workers 还支持自定义域、自动邮件、Zero Trust 集成，甚至可通过 Workers AI 与 Claude 等 LLM 监控状态。

代码示例
```ts
const app = new Hono<{ Bindings: Bindings }>();
function makeSupabaseClient(c: AppContext) {
return createClient(<<yoururlhere>>, <<yourkeyhere>>);
}
async function respond<T>(c: AppContext, query: PromiseLike<{ data: T | null; error: { message: string } | null }>) {
const { data, error } = await query;
c.header('cache-control', 'public, max-age=300');
if (error) return c.json({ error: error.message }, 500);
return c.json(data ?? []);
}
app.get('/example/:param', async (c) => {
const supabase = makeSupabaseClient(c);
const { param } = c.req.param();
return respond(c, paginate(c, supabase.from('somedatabase').select('mycolumns').eq('param', param)));
});
```

资源
GitHub

#开发者 #工具 #CloudflareWorkers #HonoJS #Supabase #Wrangler #无服务器API
@DevToolboxHub

OpenAI推出金融版ChatGPT

OpenAI宣布推出ChatGPT for Financial Services，这是ChatGPT Work的定制版本，面向金融服务团队，结合内置金融数据与GPT-6 Astra推理能力。

官方定位的三个核心用途：团队可用于开展研究、构建金融模型、制作定制化客户材料。三者可相互衔接，研究支撑建模，模型输出再转化为客户演示材料，减少起草、分析与沟通之间的交接。

公告未披露定价、数据源、部署选项、地区可用性及技术控制细节，也未说明是否支持导入专有数据、连接外部系统、生成电子表格或自动化审批。金融研究、模型与客户材料可能影响重要决策，团队需自行建立输出审查机制。

#开发者 #工具 #OpenAI #ChatGPT #金融科技 #GPT6Astra #AI
@DevToolboxHub

应用零改动迁EKS实测

作者把同一套 Node.js 应用从家庭 k3s 服务器迁到 Amazon EKS，应用代码、容器镜像、Helm chart 与 GitOps 交付模型全部原样保留，但平台层暴露了三个家庭环境不存在的假设：网络、工作节点规格与 AWS 访问。

测试用 Terraform 创建了最小环境：一个 EKS 1.36 集群、一个托管 AMD64 工作节点、两个跨可用区公共子网、AWS Load Balancer Controller 与 Argo CD Core。控制平面创建耗时 5 分 51 秒，CI 检查 13 秒完成，Argo CD 部署两个健康副本，并在 5 秒内纠正了一次手动扩缩容漂移（k3s 上同类测试为 42 秒）。

过程中踩了三个坑：工作节点因私有访问未开启无法加入集群；计划中的 t3.medium 被 AWS 拒绝，改用 c7i-flex.large（2 vCPU / 4 GiB）；交互式登录刷新不稳定，临时创建角色完成剩余操作后清理。预估环境成本约 0.24-0.27 美元/小时，清理脚本在测试后完整执行。

结论清晰：Kubernetes 让工作负载可移植，但网络、实例选择、身份与负载均衡集成仍需 AWS 特定工程。家庭 k3s 仍是日常学习环境，EKS 只作为短期验证目标。

#开发者 #工具 #Kubernetes #EKS #ArgoCD #Terraform #GitOps #k3s #AWS #Helm
@DevToolboxHub

PostgreSQL max_connections 详解：内存、连接数与性能的平衡

max_connections 不是决定查询并发数的参数，而是 PostgreSQL 为每个客户端后端预留共享内存的预算。默认 100，范围 1–262,143。它决定：

- 允许的客户端后端数目；
- 预留的共享内存大小（每个后端占用 PGPROC、pg_stat_activity 行、锁表等）。
- 需要在主机重启后才能修改。

在 18.6 上，默认 shared_buffers 时，max_connections=100 时共享内存约 150 MB；1,000 时 197 MB；5,000 时 389 MB。锁表占用随连接数线性增长。热备机必须与主机使用相同或更大的 max_connections，否则启动失败或在 WAL 中警告。

连接成本
空闲后端仅占约 1 MB 私有内存；活跃后端会消耗 work_mem、hash join 内存等。超过核心数的活跃连接会导致上下文切换、锁竞争，吞吐量下降。

云服务默认值
- Heroku：500 → 5,000（Advanced tier）
- AWS RDS：公式 LEAST(DBInstanceClassMemory/9531392, 5000)
- Azure：MIN(memoryGib*0.1049164697034809, 5000)
- Google Cloud SQL：16 GB 仅 500。

默认值已从 100 提升至 17–50 倍，取决于内存。建议使用 RDS Proxy 等连接池器来避免“too many clients”错误。

实践建议
1. 先在备机调高 max_connections，再在主机调高；反之则会导致恢复暂停。
2. 监控 pg_stat_activity、wait_event_type、load average，及时发现锁竞争。
3. 对高并发应用使用连接池，避免直接打开数百连接。

#开发者 #工具 #PostgreSQL #max_connections #云数据库 #RDSProxy
@DevToolboxHub

Postgres逻辑复制磁盘暴涨之谜

逻辑复制从 Postgres 10 起就是内置功能，但很少有人注意到 CREATE SUBSCRIPTION 语法里那个不起眼的 WITH 子句。它展开后有十多个选项，其中几个直接决定逻辑复制如何消耗存储资源。默认情况下，不带任何参数的订阅完全能正常工作，所以大多数生产环境的订阅都从未调整过这些选项。

问题往往在不知不觉中出现：生产系统挂着多个下游逻辑副本，某天磁盘监控突然报警，pg_replslot 目录被成千上万个匿名文件塞满。这些文件是逻辑解码过程中产生的 spill 文件——当解码事务超出 logical_decoding_work_mem（默认 64MB）的内存预算时，剩余内容会被写入磁盘。每个复制槽对应一个 walsender 进程，各自维护独立的 reorderbuffer，N 个订阅就意味着 N 份解码、N 份 spill，互不共享。

根本原因在于 walsender 必须等待事务提交记录出现，才能把完整事务交给输出插件发送给订阅端。WAL 并非按提交顺序写入，并发事务的 WAL 记录交错排列，还可能中途回滚，所以解码出的变更只能先暂存在 reorderbuffer 里。内存放不下就溢出到 pg_replslot 目录，长事务或大事务会让 spill 文件迅速膨胀。Postgres 17 及更早版本中 streaming 参数默认 off，发布端必须先把整个事务解码并存储完毕才能传输。

实测中，一个 30 万行的单事务在三个订阅节点上各产生 114MB spill 文件，发布端 pg_replslot 目录总计占用 342MB。同一份 WAL 被解码三次、写盘三次。把 logical_decoding_work_mem 调低到 64kB 后，单事务 spill 次数高达 1775 次。更隐蔽的是，事务提交后目录立即清空，只剩累计计数器，现场证据几乎为零。

Postgres 18 已把 streaming 默认值从 off 改为 on，发布端解码后直接转发给订阅端，不再本地落盘。但 TOAST 大字段仍可能触发本地 spill，只是暴露面大幅缩小。Postgres 16 起还支持 parallel 模式，变更直接交给订阅端的并行 apply worker，连临时文件都不需要。pg_stat_subscription 视图里能看到 parallel apply worker 的行，其 leader_pid 为空。

Postgres 17 及更早版本的用户只需一条 ALTER SUBSCRIPTION ... SET (streaming = on) 即可启用流式传输，无需重启，apply worker 会自动重启生效。Postgres 13 及更早版本不支持 streaming 选项，建议尽快升级。文档对 reorderbuffer 和 spill 风险的描述相当简略，DBA 排查时很难联想到这个参数。检查一下自己的订阅配置，pg_subscription 表里 substream 列一眼就能看出当前设置。

#开发者 #工具 #Postgres #逻辑复制 #数据库 #DBA #流式复制
@DevToolboxHub

Cohere发布218B参数稀疏翻译模型 North Small Translate

Cohere 推出了 218 B 参数的 Mixture‑of‑Experts（MoE）翻译模型 North Small Translate，专门为机器翻译设计。模型采用稀疏架构，128 个专家中每个 token 仅激活 8 个，实际活跃参数约 25 B。支持 50 种语言，WMT26 评测得分 83.60，使用多轮自我校正可提升至 84.36。

该模型的硬件需求相对可控：4‑bit 量化版可在单个 NVIDIA B200 或两块 H100 上运行；BF16 精度需四块 B200 或八块 H100。为生产环境提供商业许可与 Model Vault 部署。

对开发者而言，North Small Translate 让翻译任务从复杂提示转为直接函数调用，减少工程成本。可通过 API 或下载权重（CC BY‑NC 4.0）进行评估。

GitHub: GitHub

🔗 原文：点击查看

#开发者 #工具 #Cohere #MoE #翻译模型 #NVIDIA #HuggingFace #PythonSDK
@DevToolboxHub

Postgres角色限制可被会话自身绕过

给 AI 代理数据库角色设置 statement_timeout 和只读事务，是常见的加固手段。但实测表明，这些限制只约束会话的初始状态，代理在自己的会话里可以随时解除。

用 SET 命令即可当场关闭限制，且不会留下 ALTER 痕迹。更隐蔽的是通过连接串或 PGOPTIONS 环境变量传入 -c 参数，source 显示为 client，优先级高于角色级 user 设置，日志里连 SET 都看不到。

PostgreSQL 15 引入的 GRANT SET ON PARAMETER 也无法补救：USERSET 参数本就允许所有角色修改，REVOKE 不会写入 pg_parameter_acl，实际不生效。真正有效的约束是 CONNECTION LIMIT、对象权限和 pg_terminate_backend，这三者无法从会话内部绕过。

测试基于 PostgreSQL 18.6，事务超时对比在 17.11 和 16.15 上完成。给代理数据库授权时，别把超时和只读设置当作安全边界。

🔗 原文：postgr.es/p/9ul

#开发者 #工具 #PostgreSQL #数据库安全 #AI代理 #权限控制 #USERSET
@DevToolboxHub

K8s v1.37 原生直方图转正Beta

Kubernetes v1.37 将原生直方图（Native Histograms）支持升级为 Beta，并默认启用。该特性此前在 v1.36 以 Alpha 引入（KEP-5808），通过采用 Prometheus 原生直方图，Kubernetes 组件能以更高精度暴露延迟与耗时指标，同时显著降低遥测存储与抓取开销。

经典直方图要求指标作者预定义静态累积桶边界（le 标签），存在三大问题：桶边界靠猜，延迟分布变化后失去可见性；每个桶边界单独导出为一条时间序列，推高基数与 TSDB 存储成本；histogram_quantile() 依赖静态桶间线性插值，桶跨度大时分位数误差明显。

原生直方图以动态指数桶替代静态用户定义桶，单条时间序列内包含正负跨度、零阈值与指数缩放因子。优势包括：自动适配纳秒到小时级任意值域；时间序列数量最多减少 90%；默认设置下分位数计算最坏相对误差约 5%。

实现位于共享指标子系统 k8s.io/component-base/metrics，采用双暴露机制：经典桶与原生跨度同时输出，现有 Prometheus、仪表盘与告警规则无需改动。默认指数配置为 BucketFactor 1.1、MaxBucketNumber 160。kube-apiserver、kube-scheduler、kubelet、kube-controller-manager 与 kube-proxy 均自动继承支持。

抓取配置按 Prometheus 版本区分：3.0+ 推荐在 scrape_configs 中设置 scrape_native_histograms: true 与 always_scrape_classic_histograms: true；2.40–2.x 需以 --enable-feature=native-histograms 全局启用。迁移建议分四步：双格式采集、查询迁移至原生直方图语法、在预发/生产验证、确认无误后关闭经典格式抓取，时间序列数量可减少约 90%。回滚灵活，采集端设 scrape_native_histograms: false 即可，组件端可用 --feature-gates=NativeHistograms=false 关闭。

原生直方图正朝 GA 推进，SIG Instrumentation 将持续评估生态就绪度与性能表现，并规划经典静态桶的长期弃用路径。

🔗 原文：点击查看

#开发者 #工具 #Kubernetes #Prometheus #可观测性 #SIGInstrumentation #KEP5808 #监控 #云原生
@DevToolboxHub